Having members who think differently isn't just nice—it's productive.
Different perspectives catch different blind spots. A security-focused engineer notices vulnerabilities a feature-focused one misses.
Constructive disagreement improves decisions. When everyone thinks alike, bad ideas go unchallenged.
Creativity emerges from intersection. New ideas often come from combining insights across domains.
The discomfort of having your assumptions challenged is the feeling of blind spots being revealed.
📘 Lab 2 in action: When you discussed "Why is Light abstract?" with a neighbor, you probably discovered different approaches. That reflection prompt—"What did you learn from someone who thought differently?"—was cognitive diversity in action.
Brooks' Law: Communication Overhead Grows Quadratically
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Translation: Your software's architecture will mirror your team's structure—whether you plan for it or not.
Example: Three teams working on one app → three separate services that need integration
Inverse Conway: Design the team structure you want to match the architecture you need
📘 CookYourBooks in action: We structured your team around the architecture—one person owns each GUI component (Library, Recipe, Import, Search). Remember the responsibility heuristics from L18? Each feature is a cohesive responsibility with a defined interface. Team boundaries = module boundaries.
Introducing A5: Designing Services for Your Team (Individual Assignment)
A4's RecipeService bundled everything into one interface—scaling, conversion, import, search. That was intentionally problematic. A5 asks you to fix it by designing services aligned with actors:
Actor
A5 Service Responsibility
Group Project GUI Component
Librarian
Collections, import, search
Library View, Import Interface, Search
Cook
Step-by-step navigation
Recipe Details/Editor
Planner
Shopping lists, scaling, export
(Feature Buffet options)
Same architecture, CLI → GUI: Your A5 services become the foundation for the group project. Each teammate's GUI component consumes specific services—clean boundaries = parallel work without conflicts.
You are not the center of the universe (nor is your code!). You're neither omniscient nor infallible. You're open to self-improvement.
Without Humility:
"I'm never wrong about code."
"I don't need to ask—I'll figure it out myself."
Refusing to acknowledge bugs you introduced
Taking criticism of code as personal attacks
With Humility:
"My mistake—let me fix it."
"I don't know, but I'll learn."
Accepting that your code can be improved
Being willing to change your mind
Humility isn't self-deprecation—it's honest self-assessment and openness to growth.
📘 Labs 4 & 6 in action: In Lab 4, you practiced "I think X because Y"—sharing reasoning, not declaring the One True Answer. In Lab 6, you learned to reject AI suggestions you don't understand: "Rejecting a suggestion is not failure—it's critical thinking." Both require humility to question yourself.
You genuinely care about others you work with. You treat them kindly and appreciate their abilities and accomplishments.
Without Respect:
Ignoring teammates when they speak
Taking credit for others' ideas
Dismissing suggestions without consideration
"Whatever..." or "That's a dumb idea."
With Respect:
Listening to understand, not just to respond
"Great idea, Sarah!" — giving credit
Assuming competence and good intentions
Valuing contributions different from yours
Respect isn't just politeness—it's genuine care for your teammates as people and professionals.
📘 Lab 5 in action: You practiced "listen to understand, not to argue"—treating your partner's interpretation as worth understanding, even when different from yours. That's respect.
You believe others are competent and will do the right thing. You're OK with letting them drive when appropriate.
Without Trust:
Hovering over teammates, checking every keystroke
Rewriting others' code without discussing it
Requiring approval for every small decision
"Let me just do it myself—it'll be faster."
With Trust:
Delegating without micromanaging
Giving space to make (and learn from) mistakes
Discussing before rewriting someone's work
Trusting teammates to ask for help when needed
Trust isn't blind faith—it's giving people the benefit of the doubt and room to grow.
📘 Labs 4 & 8 in action: Lab 4's "be willing to be persuaded" meant trusting your partner's reasoning might reveal something you missed. In Lab 8, you reviewed another pair's interfaces without rewriting them—discussing before suggesting changes. That's trust.
"Have you considered using a HashMap here? It would give us O(1) lookups instead of O(n)."
"I'm curious about this approach—what led you to this design?"
"I'm having trouble following the logic in this function. Could we pair on simplifying it?"
Same technical goals. The HRT version treats the author as a capable colleague, not a subordinate to be corrected.
📘 Lab 8 in action: When defending your design choices in code review, use the format you practiced: "I chose X because Y. I considered Z, but X is better here because..." When asking questions, use "Why did you prioritize that?"—drawing out reasoning, not challenging.
I am trying to [goal] so that I can [context/motivation].
I am running into [specific problem—error message, unexpected behavior].
I have looked at [resources consulted] and tried [approaches attempted].
My tech stack is: [relevant versions and configuration].
I think the problem could be [your hypothesis, if you have one].
Before asking, search first:
Stack Overflow, team Slack/Discord history, project docs, closed GitHub issues
After solving, document the solution:
Update the original thread, add to wiki, write a blog post
📘 Labs 3 & 6 in action: When you posted on the forum (Lab 3), you included context, expected behavior, and what you tried. In Lab 6, you learned the "3-Question Test" before using AI code: Can I explain this? Can I modify this? Can I debug this? Both are about respecting others' time—including your future self.
Explicitly discuss and document expectations before conflicts arise:
When are we available to work together?
How do we prefer to communicate?
How do we handle deadlines?
What does "done" mean for our work?
How will we divide work and make decisions?
What do we do when someone is blocked?
Example conflict prevented: A team member who starts work early and one who works best under deadline pressure can negotiate expectations upfront—rather than discovering the mismatch mid-project.
For this class: Your team charter is live now—it's your first team deliverable. We'll cover the details at the end of this lecture.
A teammate committed directly to main, breaking the build right before a deadline.
Counterproductive response:
"You broke the build! Why didn't you use a branch? Now we're all going to miss the deadline because of you."
Using the six steps:
"The build failed at 11 PM after this commit."
"I was stressed because I couldn't test my changes."
(Maybe they didn't know about the branch policy?)
(Take a breath before responding)
"Let's revert and get the build green. Then we can talk about branch protection."
(If it keeps happening, bring it to the team lead)
The goal isn't to win—it's to fix the problem and prevent it from happening again.
📘 Lab 4 in action: When you and your partner disagreed, you didn't just "agree to disagree"—you had to reach a joint decision. Phrases like "What's driving your preference?" and "I hadn't considered that" helped bridge differences. That's conflict resolution.
Accountability: Being Someone Your Team Can Rely On
Own your commitments: If you say you'll do something, do it—or communicate early if you can't. Don't wait until the deadline.
Take responsibility for outcomes, not just effort: "I worked hard on it" isn't the same as "it's done and working."
Support team outcomes: If a teammate is struggling, offer help before being asked. The team succeeds or fails together.
Accountability builds trust. When teammates can count on you, the whole team moves faster.
Your instinct may be to explain, defend, or minimize. Resist.
Say "thank you" before responding — it creates space between reaction and response
Ask clarifying questions — "Can you give me an example?"
Reflect before reacting — you don't have to agree immediately, but don't dismiss
Follow up — tell them what you changed. It encourages future feedback.
The discomfort is the point. If all feedback feels good, you're only hearing from people who tell you what you want to hear.
📘 Lab 6 in action: In the Partner Check, you explained a bug without notes. Your partner's job was to ask one clarifying question, then share what was clear vs. confusing. That's how feedback should work—specific, constructive, and focused on improving understanding.
The Answer to Brooks' Law: Scalable Communication
Brooks' Law says communication overhead grows as n(n-1)/2. The answer isn't fewer teammates—it's communication that scales sub-linearly.
Written communication persists: Gets searched, gets reused, doesn't require everyone in the same room
HRT applies extra here: Written words lack tone—extra care needed to show respect and assume good intent
Conway's Law reminder: How you communicate shapes your software—written artifacts are the connective tissue
Rule of thumb: If you've explained something to more than two people, write it down.
Rule of thumb: If you've explained something to more than two people, write it down.
Research shows developers see ~50% productivity boost when documentation is up-to-date, detailed, and available in multiple formats.
📘 Labs 3 & 6 in action: Forum posts (Lab 3) are one-to-many, persistent knowledge sharing—everyone benefits. Lab 6 emphasized "after solving, document the solution." Both turn one-time help into scalable knowledge.
Don't just divide up sections and merge—discuss together
Step 2: Have the awkward conversations
"What hours do you actually work?" (not what sounds good)
"What happens if someone misses a deadline?"
"How do we decide when we disagree?"
Step 3: Be specific, not aspirational
❌ "We'll communicate regularly"
✓ "We'll post daily updates in Discord by 9 PM"
HRT in action: Approach this with humility ("my preferences aren't the only valid ones"), respect ("everyone's constraints matter"), and trust ("we'll all follow what we agree to").
