Why Pair Programme?
As with all things ‘agile’, it’s a mindset. Pair programming is achieved with two developers programming on one workstation, solving one problem. It creates higher focus and code quality, fewer defects, faster problem solving, and facilitates continuous code review and continuous knowledge sharing between developers. Yeh I said ‘workstation’. I’m 42 years old, get on board.
The explanation to product
It’ll minimise risk through the eradication of silos and miscommunication.
The explanation to a muggle
It’ll increase the ‘intensity’ of development.
The explanation to a developer
It’s a way to learn, grow and design things better from the start.
Why do it?
Pair programming saves time. More time is spent coding but less time is spent on defects. Obviously, 9 out of 10 developers prefer to work alone — it’s in our DNA — but 9 out of 10 developers will also tell you that they are more confident in the code they create during pair programming. Small thing: you’ll have someone to tell you if your class names and structures are stupid before the code review.
How can it go wrong?
Oddly, pair programming can cause people who get good at it to lose confidence over time. They start to have trouble coding on their own because they like the warm blanket that continuous code review provides. But that’s a nice problem to have, not an insurmountable one. Many other things will go wrong before the nice confidence one crops up:
- You’ll pair on something that doesn’t warrant it. So, if the task doesn’t lend itself to pair programming, don’t force it.
- If one developer is slow or unfocused two developers can become slow. So take breaks, and don’t accept the drag of colleagues that slow you down.
- Don’t waste 10 minutes explaining something that you can code in 40 seconds. Code it.
- You’ll both lose if one of you is too insecure to begin an argument; positivity pays; please ask stupid questions and be natural. My advice if you think your partner’s not speaking up: give them the opportunity to argue by saying something stupid. If they’re not asking questions, ask them something stupid. If you can’t do that then never have kids; helping people grow by damaging your own ego is the definition of parenthood.
Ultimately, developers that don’t want it to work will not allow it to work. I pair programmed for several years, it goes wrong easily. Especially if either of you have a bad attitude. I hold my hands up as being the one for several years with the perfectionist, impatient attitude. Pair programming is teamwork. If you know you don’t play nicely with others or you know you’re a negative person then you’re going to struggle, but in this new agile world you’re probably used to struggling already; suck it up and grow!
Even Daryl, from the Walking Dead learned to be a team player.
How do you do it?
Be courageous. Start small. Pick a task that can be completed in a few minutes. The point is to get used to the style of working/thinking. One person types (the driver). One person watches (the navigator). If you have a bad attitude and you’re driving you’ll make the navigator feel like they’re distracting you, so be the navigator instead. Make this work for you. Think of a rally car race: the navigator thinks ahead, the driver handles the details; both are in 100% sync with each other. If at any moment you’re not in sync, say so. Ask questions, look stupid, help the other person grow.
Risk of death: low.
Risk of growth: high.
PS Don’t just talk for the sake of talking. If you need to take a minute / whiteboard / Google, do it.
Additional stuff which may not apply to you (yet)
(Agile) rules for pairing ‘remotely’
- Don’t take the mouse or keyboard by surprise because you’ll distract the other person while they’re thinking about something and distracting a developer, as you know — even during pairing — makes you the enemy
- Use video (you need to see the other person’s face). If you can, it makes a world of difference to have your partner’s face on a separate screen to the one you’re screen sharing on. FYI screen resolution matters when screen sharing — both of you should have big and equal sized monitors
- Be generous. Be patient. You will have problems, technology will go wrong. Lag happens. You don’t need to care about that, so try not to
- Whiteboards, whiteboards, whiteboards. You don’t have one, so use Miro instead
- Use a good microphone. Poor audio kills conversations
- Use speakers (if you can) because wearing headphones 24/7 isn’t comfortable
If you have any additional guidance on pair programming that you think I should have included, let me know.
