Two Sets of Eyes

Anything that goes into the product must be reviewed by two sets of eyes. You never want a single person to be the only one who understands why a given file was changed, or why something was removed, or how something works. Prevent knowledge silos by including at least second person.

This practice is not a pass/fail gate or approval process. Instead, it’s a shared learning and teaching opportunity. Informal code reviews, pair programming, and mob programming can all be used effectively to implement this idea.

Pain Points

• Code can only be updated by the developer who wrote it.
• Code can only be updated by the last developer who edited it. You touched it? Its yours now.
• The thought of a developer leaving brings on cold sweats.
• The team has well-known knowledge silos. Only Jim can touch this area. Only Sue can work in that. This causes frequent schedule bottlenecks.
• A key developer pushed in a key fix (usually late at night), then went on vacation. The fix isn’t working quite right and no-one understands what it’s supposed to be doing.
• The product is plagued by quality issues that are often small things, and are easily fixed. But they shouldn’t have slipped into the product in the first place.
• Several developers on the team are known for introducing new toolkits and generally being quite clever. In fact, they’re so clever that they’ve solved the same problem multiple ways. All of which are in production.
• Huge gaps in expertise between team members… and it’s not getting any better.

Benefits

• Transparency leaves no place for bugs to hide. Explaining your code to a second person frequently exposes issues that are difficult to see on your own.¹

• Illuminate misunderstandings before they become wide-spread and entrenched. When someone is resolving a solved problem, the second person can point this out and help eliminate the redundant work.
• Explaining your motivations and thought process to a second person ensures others understand your work and lower the odds that the work will become a boat anchor around your neck.

Assessment

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:

What Does it Look like?

1. Pair programming
2. Mob programming
3. Peer code review

There are several common ways to get a second set of eyes on the code. You can use a peer code review, pair programming (two people), or mob programming (more than two people).

The peer code review is a lightweight, informal event. When something is complete, walk around and look for a team mate who’s not deep into a problem and ask if they’re available. Then sit with them, walk them through what you were trying to solve, then show them the code. The process is similar for graphics, automated tests, an so on. This is an interactive process with discussion as you move through the work.

When you’re done, ask what they think. If they don’t understand what you’ve done, or think the solution has fatal flaws, revisit your work and try again. Remember, as a reviewer, don’t reject work because it doesn’t suit your own preferences, but only if it’ll cause serious problems.

Pair programming is more involved. Two people sit together and work on the same problem. There may be two keyboards, or a single keyboard may be passed back and forth, but everyone is looking at the same screen. There are several styles, but there’s a lot of high bandwidth communication during the entire process. Perhaps one developer drives the coding more at first while the second person is thinking through the story to ensure you stay on course. Both people share a single proverbial brain, working towards a common goal.

Mob programming extends that idea to three or more people.²

These are excellent ways to share work habits, mentor junior developers, or hone your own skills by slowing down enough to explain your thought processes to another person.

Again, do not think of this practice as a pass/fail gate, but as a communication/shared learning practice.

Warning Signs

• Fearing the second set of eyes
• Always getting the same set of eyes
• Waiting weeks or months before sharing
• Rubber stamp code reviews
• Using an electronic tool to queue up reviews instead of talking to your teammates
• The fastest typist, or loudest mouth, wins all the discussions

Growth Path

• Aggressively rotate reviewers. If reviews aren’t random, put a grid on a white board and work your way through the team
• Put the reviewer on your check in message
• Switch pair programming partners daily. Then every half day.
• Switch roles with your pair programming partner every hour
• Do peer code reviews with people who don’t know the programming (or testing) language you’re using. Writing code or tests that others can understand makes for much better product.
• Review code before you change it. Spread the knowledge about existing code, brainstorm on new ideas before recoding.

Exercises to Get Better

• Review languages and projects you don’t know or aren’t familiar with
• Review partially completed work to help you find better ways to solve problems
• Pretend you have a certain person reviewing your work. What improvements would they suggest? Can you do a virtual review without that person present?
• The goal is not the review. The goal is the interaction and conversation. How can you learn more or draw more out of your next review?

How to Teach This Practice

Ben Franklin said to make a friend, ask a favor. When you complete a task, walk around and find someone who’s not deep in their own code and ask them if they have time to review your work. You’ll find that modeling this behavior will lead to adoption.

After the team has had time to acclimate to the idea, make it a required part of every code check in. Before the code is shared, get a second set of eyes on it. If the code is written while you’re pairing with another developer, you’re covered. Otherwise, get a peer code review first. Put the reviewer’s name in the first line of your check in message.

How To Fail Spectacularly

• Gathering your entire team for every code review. Don’t do that; instead, make these reviews fast and lightweight.
• Saving up weeks and weeks of development work for a single review. If it lasts longer than 15-30 minutes, you’ve probably waited too long.
• Refusing to include interested team members. Occasionally you’ll work on something so intriguing that multiple team members will ask to be included. Have a group review in that case so everyone who wants to learn can sit in.

  ←Prev (Continuous Feature Demos)(Team Sync) Next→

---

Find Out More...

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.