Solving problems, learning and sharing knowledge - these are things I strive for as a developer. And while doing so, also produce high-quality code. Or at least I try to. Nice in theory, hard in practice.
Understandably, one can't be asked to always be on top of their game. In my case, sometimes I lack the experience, sometimes I'm just not given enough time. And to be honest, sometimes I just don't have the motivation. But there is one programming method I've found to be really helpful to achieve all of the aforementioned. Pair programming.
If this post is too long for you, feel free to check out the same content in my Youtube channel called developerHabits
What is pair programming?
In its essence, pair programming means that two people pair up to code together on one computer. The term was popularized by Kent Beck in his book "Extreme Programming Explained".
During pair programming, two developers constantly collaborate, share thoughts and review each other.
The collaboration can be done either by sitting behind one desk or via online tools.
How to pair program?
Smart people in the IT industry have come up with some nice arrangements you can use during pair-programming [1]. Below, I'm gonna list a few of them:
Driver and Navigator
As the name suggests, using this method, one of the developers is coding and the other one is live-reviewing and thinking about more general questions.
At the same time, the navigator can propose other solutions, live-review code, spot bugs and think about the possible obstacles.
Let's say that you must filter through a list of animals. In such a case, the navigator proposes the conditions for the filter and the driver(the one holding the keyboard) implements them. It's important that the driver constantly talks out loud about what she's doing. At the same time, the navigator can propose other solutions, live-review code, spot bugs and think about the possible obstacles.
Using this method, well-defined time limits (like 20-25 minutes) should be used, after which, the roles will be switched(rhyme, yay). Additionally, the members of the pair should have the same experience and knowledge.
Ping Pong
This method is making use of Test-Driven Development(TDD). The flow is something similar:
- Developer A writes a failing test
- Developer B writes the code to pass the test
- Developer B writes a failing test
- Developer A writes the code to pass the test
- ...
Fun, right?
Strong-Style Pairing
"This style is actually very close to an actual navigator/driver situation in a car or on a boat. With all the high-level commands coming from the navigator and the lower level implementation happening from the driver." [2]
A technique to be used when you need to transfer knowledge or one of the members has more knowledge on the topic.
Using this method, the navigator does all the thinking and basically just guide the driver. In order for the method to work, the driver must trust the navigator completely.
The main rule for the navigator is that in order for an idea to finish up in the code, it must go through the driver's hands.
Regarding the driver, one should ask questions only when they don't understand what to do. The "why" can be explained later when necessary.
It's the method I've made use of when mentoring.
Loose Pairing
The method I just made up.
For the past week, I've been remotely pair-programming with my colleague. Regarding development, we're quite like-minded and have similar skills.
When developing, we haven't applied any strict rules. We just share the screen and live-edit code together using Live Share. It's similar to what you can do in Google Docs.
During the sessions, we discuss and implement the ideas on the go. Usually, when one writes code, the other one watches in order to catch bugs and provide suggestions.
It's similar to "Driver and Navigator" method, but a bit looser. I believe it works only when you are developing with someone you know well and have very similar ideas.
Why pair programming?
Have you ever gone to your colleagues to ask for help but during describing the problem, the solution just pops up? Yes, me too.
There are many reasons why pair programming can benefit you. Below, I'm gonna list the ones I've experienced.
The quality of the product improves
By utilizing pair programming, the quality that you produce can be much higher than when working on things alone. The main reasons being pair pressure, ability to discuss ideas and live reviewing.
When working in a pair, I want to do things correctly and show myself from a positive angle, thus writing the best code I can. Additionally, as it's uncomfortable to check every Slack message I've received, it also helps to focus more. Similar findings have been brought out in Laurie Williams' research on Pair Programming [3, page 9].
Another aspect that contributes to better quality is the fact that you get to discuss your ideas and validate them with your partner. This way, there's always someone to validate and even improve the thoughts you've had.
Some people even say that pair programming's a higher form of code review
And finally - live reviewing. As you write the code, there's always someone there to spot the bugs and suggest improvements to code. It's hard to get someone to review your code that thoroughly during code-reviews. Some people even say that pair programming's a higher form of code review [4]
You get to learn and teach at the same time
One of the main reasons I like pair programming is that I'm able to learn and teach at the same time.
When working on projects I know nothing about, it's a great way to get myself up-to-speed by using someone else's knowledge. They can explain the why and how behind everything. To be honest, I've learned many coding patterns, UNIX commands, and editor tricks just by pair programming.
On the other side, while I'm learning new things, I also get to share my knowledge. As a navigator, it can be done by explaining the project and suggesting ideas for implementation. When being a driver, I can do the implementation and the navigator can learn from my way of coding. When there are questions about why something is done in a particular way, it also sparks new conversations.
Improving communication skills
Another important part of pair programming is communication. As a developer, one should be able to articulate their thoughts. I believe practicing pair programming is a great way to improve that skill.
When being in a situation where everything you do must make sense to the other party, it's important to constantly talk out loud and not keep ideas to yourself. By doing that, you become more comfortable using technical terms, explaining various programming concepts but also structuring your ideas.
I remember times when I was really insecure to speak my mind on technical topics. By now, I've gotten better, mainly thanks to pair programming.
Human interaction
During the times when we're forced to work from home, human interaction becomes quite important. By practicing pair programming, you've always got someone to communicate with.
Things to keep in mind
Pair programming isn't perfect. There are things one should keep in mind before utilizing it.
Use only if it aligns with your goals
Pair-programming is great for sharing knowledge and producing quality code. It also contributes to making people communicate.
That said, if you're doing a task that's very time-critical and quality isn't part of the top priorities, maybe pair-programming doesn't make sense.
Pair programming may not boost the quality of simpler tasks
In case the task at hand can easily be done by one person and quality is one of the goals, pair programming may not be the way to go. In her paper on pair programming, Laurie Williams mentions an experiment of 295 consultants demonstrating that the method only improves the quality of complex tasks [3, page 5].
Do not force people into it
There are people who work better alone or may feel really uncomfortable doing pair programming. Forcing people into pairs may cause more harm than good.
Also, the people in pairs should have good chemistry and similar work ethics. I've seen it during mentoring that some pairs just do not work well.
When tutoring isn't a goal, developers with similar skillset should be paired.
Plan the day
As pair programming requires lots of focus and constant collaboration, it's hard to do it for the whole day.
Before you start, take some time to agree on how often you take breaks and how long will you be pair-programming for. Based on my experience, having 5-minute breaks every 30 minutes is quite efficient (with some longer pauses after every hour). The duration of the whole collaboration can last for about 4 hours, after that it's hard to focus.
Also, let yourselves know if there are any meetings or other responsibilities you've got to attend to.
Try it out
As you can see, pair programming can be quite beneficial. It helps you to write better code, share ideas but also learn from others. When working remotely, it's also a nice way to involve human interaction into workflows.
That said, there are things to consider before implementing it. The pair should have good chemistry and the goals should be clear for both parties.
If you haven't done so yet, I recommend you to try this method out and share your experience in the comments.
What are your experiences with pair programming? Would you recommend it to others?
Sources
- [1] - On Pair Programming. Birgitta Böckeler, Nina Siessegger.
- [2] - Llewellyn’s strong-style pairing. Llewellyn Falco.
- [3] - Pair Programming. Laurie Williams.
- [4] - What is Pair Programming? Advantages, Challenges, Tutorials & More. Stackify.
Interested in topics related to growth mindset, developer lifestyle and webdev tutorials? Subscribe to my Youtube channel called developerHabits
Other channels
👉 Twitter: https://twitter.com/KethmarS
👉 IG: https://www.instagram.com/developerhabits
Top comments (0)