2.5 Technical Collaboration

← 2.4 Source Code Management | Home | Next: 2.6 DevOps Practices →

Code Review Best Practices

When Writing a Pull Request

Include the purpose of the PR (e.g., "This is a spike to explore…" / "This simplifies the display of…" / "This fixes handling of…").
Provide an overview of why the work is taking place; don't assume familiarity with the history.
Be explicit about what feedback you want, if any: a quick pair of eyes on the code, discussion on the technical approach, critique on design, a review of copy.
Be explicit about when you want feedback. If the PR is work in progress, say so. A prefix of "[WIP]" in the title is a common pattern.
@mention individuals and teams you specifically want to involve, and mention why.

When Offering Feedback

Familiarize yourself with the context of the issue and reasons why the PR exists.
If you disagree strongly, consider giving it a few minutes before responding; think before you react.
Ask, don't tell. ("What do you think about trying…?" rather than "Don't do…")
Explain your reasons why code should be changed. Is it not in line with the style guide? A personal preference?
Offer ways to simplify or improve code.
Avoid using derogatory terms when referring to the work someone has produced.
Be humble. ("I'm not sure, let's try…")
Avoid hyperbole. ("NEVER do…")
Use emoji to clarify tone. Compare "✨ ✨ Looks good 👍 ✨ ✨" to "Looks good."

When Responding to Feedback

Consider leading with an expression of appreciation, especially when feedback has been mixed.
Ask for clarification. ("I don't understand, can you clarify?")
Offer clarification—explain the decisions you made to reach a solution.
Try to respond to every comment.
Link to follow-up commits. ("Good call! Done in 1682851")
If there is growing confusion or debate, talk face-to-face, then mutually post a follow-up summarizing the offline discussion.

Pair Programming

"Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each others errors, and use the best ideas." — Jean Bartik, one of the ENIAC programmers

"Write all production programs with two people sitting at one machine." — Kent Beck

Three Main Styles

Style	How It Works	Best For
Driver & Navigator	Driver writes code (tactical thinking), Navigator observes the big picture (strategic thinking); switch roles regularly.	Daily development
Ping Pong	A writes a failing test → B writes the implementation to make it pass → B writes the next failing test → repeat.	TDD scenarios
Strong-Style	The experienced person stays in Navigator role and guides; the novice is the Driver. Rule: "For an idea to go from your head into the computer it MUST go through someone else's hands."	Knowledge transfer, onboarding

Key Benefits

Knowledge sharing, reflection, keeping focus, code review on-the-go, two modes of thinking combined (tactical + strategic), collective code ownership, keeping the team's WIP low, fast onboarding of new team members.

Common Challenges and Solutions

Challenge	Solution
Pairing can be exhausting	Use Pomodoro (25 min work + 5 min break); don't pair more than 6 hours per day; regularly switch roles.
Intense collaboration can be hard	Discuss how you want to work together upfront; do a mini-retro at the end of the day.
Interruptions by meetings	Establish core coding hours; attend meetings as a pair.
Different skill levels	Don't assume you know best; questions lead to better solutions. Apply the 5-second rule—wait before pointing out an error.
Power dynamics	The person on the upward side must acknowledge their position and actively work to neutralize the imbalance. Share keyboard time, encourage questions.

Sources

GitHub Blog — How to write the perfect pull request: https://github.blog/developer-skills/github/how-to-write-the-perfect-pull-request/
Martin Fowler / Birgitta Bockeler — On Pair Programming: https://martinfowler.com/articles/on-pair-programming.html

← 2.4 Source Code Management | Home | Next: 2.6 DevOps Practices →