필사 모드: In the End, People Do the Work — What It Means to Respect People on a Software Team

Opening — The Real Cause of the Bug

In incident retrospectives, the most common surface-level cause cited is "a bug in some piece of code." But when you dig deep into a retro, the real cause is, surprisingly often, not the code but something between people.

Let me tell you about a case I lived through. A payment system produced a double-charge bug. The code itself could be fixed in two lines. Yet the retro revealed that a month earlier, a developer had already spotted the risk and mentioned it in code review. The review comment read: "If a retry happens here, couldn't this lead to a double charge?" The reply to that comment was a single line: "No time right now, will look later." And nobody ever looked later.

The real cause of the bug was not the code, but the fact that the comment wasn't taken seriously. The person who raised it felt ignored, and afterward grew quieter and quieter in reviews. This was not a technical problem; it was a problem of people and communication.

Software is executed by computers but built by people. People gather to decide, debate, and sometimes argue as they build it. So "respect people" is not a warm slogan but a practical condition for building good software. In this essay I'll try to express that respect not as abstract preaching but as concrete behavior.

The Nature of What Looks Like a Technical Problem

Conflicts on a software team often wear the clothing of technical debate. "REST or GraphQL," "monolith or microservices," "is this variable name right or that one." But look underneath and you frequently find these non-technical problems lying at the base.

| Surface (looks technical) | Substance (people / communication problem) |

| --- | --- |

| Endless architecture debate | A power struggle over whose opinion is respected more |

| Code review turns hostile | Failing to separate critique from character |

| The same mistake repeats | No safety to admit mistakes honestly |

| Information isn't shared | Absence of trust and cooperation |

| Meetings run long with no conclusion | Unclear decision authority |

Of course, purely technical debates exist too, and reducing every conflict to a people problem is just as dangerous. The point is this: when a technical debate becomes abnormally heated or recurs, suspect whether a people problem lies beneath. Technical problems usually yield to data and experiments; people problems do not.

Concrete Behaviors of Respect

"Let's respect each other" is something everyone agrees with and that changes nothing. Respect must be a verb, not a noun. It has to show up in small daily actions.

Listening — Hearing People Out Without Interrupting

The most basic and the least observed. Don't cut in while someone is speaking in a meeting; even if you disagree, hear them out and ask back, "Let me check that I understood you correctly." This alone changes the atmosphere.

[A conversation without listening]

A: I think if we introduce a cache—

B: No, that won't work. Cache invalidation is so hard.

A: (falls silent)

[A conversation with listening]

A: I think introducing a cache could improve response time.

B: Good direction. My one worry is cache invalidation —

how were you thinking of handling that?

A: Ah, by keeping a short TTL and—

The technical content of the two conversations is the same. The only difference is that one side treated the other as a person.

Credit — Attributing Contributions Accurately

If someone's idea solved the problem, name that person explicitly in the meeting, the document, the presentation. The single line "we solved it with the approach OO proposed last week" is a big form of recognition. Conversely, nothing destroys trust faster than quietly taking someone else's credit as your own.

Fairness — Treating People by Consistent Standards

If you're lenient with one person's mistake and harsh with another's, that is unfairness. If you wave through the PRs of people you like and nitpick the PRs of people you dislike, people will notice soon enough. Fairness comes from consistency of standards.

Respecting Time — Not Breaking Others' Focus Carelessly

Repeatedly breaking someone's deep work with "got a sec?" is also a lack of respect. Leave non-urgent questions asynchronously; keep meetings to only the people who need them, and keep them short. A colleague's time is a colleague's most precious resource.

Conduct in Code Review and Debate

Code review is where respect is most often tested. Code is the product of someone's time, and critiquing it is inherently sensitive.

Critique the Code, Not the Person

[A review that attacks the person]

"Why did you write it like this? Seems like your fundamentals are weak."

"I just can't understand this code at all."

[A review that focuses on the code]

"I think this part triggers an N+1 query. What about fetching in one go?"

"I'm having trouble following this flow — could you add a few more comments?"

The key principle is to "make the subject the code." Not "you are wrong," but "this code could cause a problem in this situation."

Borrow the Form of a Question

Questions are gentler than commands. "What about changing it like this?" gives the other person room to think, more than "change it like this." But avoid fake questions with a predetermined answer ("Do you really think this is the best you can do?") — those are even more aggressive.

Don't Try to Win the Debate; Try to Reach the Right Conclusion

The purpose of a technical debate is not to prove who's smarter but to make a better decision. The person who can say "I was wrong, your approach is better" is in fact the strongest. Disagreement is healthy, but once it's over you should follow the decision (disagree and commit) and leave no personal grudge.

Diversity and Inclusion — Different Perspectives Make Better Outcomes

Talking about diversity only as an ethical imperative easily rings hollow. There's a more practical view: a homogeneous team shares the same blind spots. When everyone has the same background, the same experience, the same way of thinking, everyone misses the same things.

People of different backgrounds ask different questions. One thinks of accessibility, another of users in a different language, another of a security threat. These varied questions add up to more robust software.

Inclusion goes one step beyond diversity. Beyond gathering varied people, it means actually enabling them to speak. If the same two or three people always talk in meetings, you have diversity but no inclusion.

Small practices that build inclusion

- In meetings, ask the quiet person directly for their view:

"OO, how do you see this part?"

- Run async channels (docs, chat) alongside

so people who find it hard to break in verbally can contribute

- Hear junior or minority opinions first, senior opinions later

(if an authoritative opinion lands first, others get buried)

Anti-Pattern — The Trap of the Genius Myth

The software industry stubbornly clings to the "lone genius" myth — the fantasy that one extraordinary developer creates everything. This myth is harmful in two ways.

First, it isn't true. Almost every great piece of software we know was built by a team. Even Linux was built by thousands of contributors together, and Linus Torvalds himself stresses this more than anyone.

Second, it does damage. The person hailed as a "genius" is often excused for rudeness. "He's prickly, but he's brilliant" erodes the psychological safety of the whole team. The value a single brilliant individual creates can be smaller than the value lost when that person makes ten people around them shrink.

Google's Project Aristotle, an analysis of its own teams, points in the same direction. The single most important factor in building the best teams was not the genius of individual members but the team's psychological safety — an atmosphere where anyone can ask a "dumb" question and admit a mistake.

A few more anti-patterns worth naming:

- **Rewarding heroics**: a culture that praises only the person who fights fires (rescues an incident at the last minute) over those who work calmly all along. In the end everyone learns to start fires.

- **Outsourcing silence**: the attitude of "that's the other team's job," shifting responsibility. Problems fester at the boundaries.

- **Contagious cynicism**: the person who answers every proposal with "we tried that before, it doesn't work." One cynic kills ten attempts.

A Case — The Rude Genius vs the Kind Helper

Let me compare two senior developers. Both were highly skilled.

S was the classic "rude genius." The code was excellent, but the reviews were harsh, and S frequently cut others off in meetings. Juniors were afraid to ask S questions and couldn't say they didn't know something. As a result, the same mistakes quietly recurred.

D was different. The code wasn't quite as good as S's, but D answered juniors' clumsy questions seriously and disclosed his own mistakes first. "I made this exact error last year," he'd say. Over time, the juniors around D grew fast, and the whole team's productivity rose.

A year later, comparing the teams' output, the team D belonged to produced more, and more reliably. A single line of S's code may have been better, but the team D built was stronger. This is the meaning of "in the end, people do the work."

A Practical Checklist

- [ ] In this week's code review, write comments with "this code" as the subject instead of "you."

- [ ] At least once in a meeting, ask a quiet colleague directly for their opinion.

- [ ] If you borrowed someone's idea, mention their name publicly.

- [ ] Try saying "I don't know" honestly about something you don't know.

- [ ] Before breaking a colleague's focus, ask first: "Do you have a moment right now?"

- [ ] In a debate, try admitting first at least once: "I might be wrong here."

- [ ] Leave opinions on an async channel to open a path for people who find it hard to break in verbally.

Closing

The quality of software ultimately reflects the quality of the relationships among the people who built it. Code built by a team that doesn't respect one another carries that distrust subtly engraved in it — in unshared information, unaddressed warnings, and the silence of people who closed their mouths.

Respecting people isn't a grand undertaking. Hearing people out, attributing credit accurately, critiquing the code without critiquing the person, and making it safe to say "I don't know." These small actions stack into a good team, and a good team builds good software.

Please remember: what we build is code, but who we work with is people. And in the end, software is the work of people.

References

- Google re:Work, "Project Aristotle" — https://rework.withgoogle.com/

- Amy Edmondson, *The Fearless Organization* (psychological safety) — https://hbr.org/2023/02/what-is-psychological-safety

- Brian Fitzpatrick & Ben Collins-Sussman, *Team Geek / Debugging Teams* (critique of the genius myth) — https://www.oreilly.com/library/view/debugging-teams/9781491932049/

- Google Engineering Practices, "Code Review Developer Guide" — https://google.github.io/eng-practices/review/

- Kim Scott, *Radical Candor* — https://www.radicalcandor.com/

- Harvard Business Review, "The Power of Saying I Was Wrong" — https://hbr.org/