31 Jan 2018
3 minute read
What is Pair Programming?
Pair programming is an agile development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.
Pair Programming What might make it hard?
- It’s new for some people
- People have different styles/ways of thinking
- There has to be more communication
- People have a different idea to what it is and how to do it
- Can be hard if both people in the pair lack domain knowledge on the task that they are in
- It’s intense
- It can be tiring
- It requires soft skills that most of the team might not have fully developed
Why we do it?
- Sharing knowledge
- Maintains momentum
- Bouncing ideas
- Better code quality
- More maintainable code
- Less bugs
- Easier to find edge cases
- Higher velocity
You can think through a problem faster when you think through it with someone. Having a partner keeps you focused on the problem. Your partner gets you through little sticking points where you aren’t sure what to do or where your domain knowledge is lacking. You pause less frequently to do research or look up code syntax, or just generally to be puzzled. Fewer defects means more time spent on creating new features and less time spent fixing bugs!
- Less stressful environment
- More job satisfaction
- Good for team building
- Greater team cohesion
- Positive discussions about possible issues
- Reduces “Bus factor”
“Bus factor” is a way of describing how well your team shares knowledge, expertise and code ownership among them. How many of us can substitute for others on the team if someone is missing (i.e., gets hit by a bus)
- Collective ownership
- Higher degree of learning and people development.
How we pair?
- Sit together or setup hangout
- Before starting on a task a pair should:
- Make sure the task is reasonably well-defined
- Read and understand the ticket before starting code.
- Come up with possible solutions
- Bring solutions to the team and come to an agreement, if needed
- Add checklist/tasks breakdown to the ticket
A good pair should:
- Ask a lot of questions
- Talk a lot
Say what you are about to do, ask for an implementation idea, ask for a better way to solve the problem at hand, bring up alternative ideas, point out possible inputs that the code doesn’t cover, suggest clearer names for variables and subroutines, suggest ways to implement the code in smaller steps, tell the driver that little bit of API knowledge that they need right at the moment they need it, etc. Listen a lot, too, of course. When people are pairing well, they are talking back and forth almost non-stop. Here are some common things to say while pairing: “Do you think this is a valid test?”, “Does that look correct to you?”, “What’s next?”, “Trust me” (when it’s easier to write a little code to make your point than to say it out loud)
- Care about the task
- Rely on your partner, support your partner
- Take frequent breaks
- Switch within an hour
- Be respectful
- Sync up frequently
- Celebrate the wins
- Not hit your partner :D
- Effective navigation in pair programming
- 10 ways improve your pairing experience
- Extreme programming
- How to pair program
- Introducing pair programming
- Pair Programming Illuminated by Laurie Williams & Robert Kessler
Return to Blogs.