Anna is an ex-physiotherapist. Matt is a former airline pilot. You may think they are part of distinct worlds and are used to communicate in a different way. It is reasonable to assume their first pair programming may be at least peculiar.
After reading this article you will have a wider view of:
- choosing the right project for your first pair programming experience,
- planning your work step-by-step,
- setting up realistic goals of the project,
- setting mandatory rules of your coding sessions,
- pros and cons of coding together!
We didn't know a thing about the canvas element. Although we considered it to be a good idea to start from scratch, give us a week to get familiar with Canvas, and start from a similar level when it comes to programming. We finally picked the project and it was a good time for…
It was very seductive just to call each other and start typing the first lines of code. However, we took a different approach. We decided to set up an organizational meeting. It was crucial and we appreciated it in the following phases of our pair programming journey.
We made use of the mandatory pair programming rules presented by Jourdan Poulton on Github. Simply speaking, the couple divides their task according to two roles: Driver and Navigator.
As the name suggests:
- the Driver is responsible for a keyboard,
- the Navigator manages the code to be written.
The most appealing rules are listed below. Our cooperation would be impossible without them.
- the only person responsible for typing,
- writes the code according to Navigator's directions,
- asks questions anytime the directions are unclear,
- offers an alternative solution when there is a disagreement,
- trusts the Navigator.
- clearly communicates the code to be written,
- checks for syntax errors and typos so the Driver doesn't have to bother,
- keeps track of console and browser output,
- makes sure that the Driver sticks to the small task,
- plans and notes down high-level tasks or issues that shall be solved later,
- waits until the Driver finishes the task to bring up design or refactoring ideas.
- communicate and are not quiet,
- know when to give up, ask for advice, or just swap roles,
- intervene when their partner is quiet,
- respect the break time.
We also took our time to discuss the core functionalities of our app. Our heads were full of crazy project implementations but, as it was our first pair programming project, we stuck to “the simpler, the better” principle.
Fun fact: it took us more than 2.5 hours to complete a 20-minutes long coding task.
After that, we arranged a simple file structure.
We made a mind map using MindMeister mapping software. There we placed the core structures and functionalities established at our meeting. The map turned up to be very helpful for us. The Navigator did some quick peeks to orientate in which phase we were during project development and what should be done next.
We noted down all our arrangements in Google Docs, so we had access to them from any device at any time.
We were all set up. Finally, it was a proper time to get our hands dirty!
We split the programming into two one-hour sessions with the help of Pomodoro-tracker:
- we coded for 25 minutes,
- took a 5-minutes break,
- swapped roles.
By the first two 25-minutes intervals we have coded the basic structure and features of the app and encountered the first bugs we had to deal with in the next step.
By the way: you can have a glimpse at what we've done by looking at the project's GitHub repo.
We spent the last two sessions fixing bugs. We have to confess that between the sessions each of us had a quick peek at the original Wes Bos project to understand the source of our bugs.
Coding time was over, we were past four 25-minutes Pomodoro intervals but still there was space to improve our Canvas Project. We couldn’t resist spending an extra 30 minutes adjusting the functionalities and patching what we've coded together.
Done! Now it’s time for summing up how we felt about pair programming.
Anna’s impression of being:
- a navigator – as I like to plan and solve problems my way the role of navigator suits me better. It’s nice to feel the flow… until the first bug occurs. Then the fun is over and you start to feel the burden of power – the increasing pressure to find the way out!
- a driver – this role is a kind of break from strenuous work but on the other hand, listening to the navigator still requires 100% of my attention. What I find difficult is keeping up with the thought process of the navigator and writing the code at the same time.
Matt’s impression of being:
- a navigator – more energy-consuming than being a driver. This role requires thinking in a wide perspective. You should predict next steps, potential bugs and pitfalls. I appreciated the Driver’s attention and suggestions when I was stuck with a line of code.
- a driver – as I am a man of action, the role of the driver suits me fine. I found myself focused while completing the strict Navigator’s instructions. It is appealing to me to stick to one task at a time and not to think in a big picture way.
- We respected the rule saying the navigator has priority over the driver to plan the code. When we wanted to break in we asked the navigator: “May I suggest something?”.
- There was no virtual wrestling over “possessing the keyboard” – the navigator didn’t touch the code without the driver’s permission. Anyway, this situation occurred mainly during debugging.
- We were completely focused on the task. It resulted in greater efficiency and faster problem-solving.
- We really did learn from each other.
- We were disciplined and stuck to the rules of pair programming most of the time.
Why does pair programming pay off?
- No doubt it’s very beneficial, especially for a junior dev. Working in a pair is a great opportunity to see other’s workflow and to learn new coding techniques.
- Pair programming is often a part of the recruitment process in many companies. A cooperation as ours makes you ready for this long-awaited interview day.
- You train communication skills – how to listen carefully, talk clearly, and not interrupt each other.
- Two heads are better than one – you hear it every time while the topic of pair programming comes up. Why? Because it’s absolutely true. There is no better way to quickly track a bug or stop it from even turning up than an extra pair of eyes.
- Keeping one’s mouth shut is not easy. Asides like “What a nice keyboard shortcut, I didn’t know it!” or “Yesterday I had the same problem” are distracting and don’t contribute to work progress.
- Sticking to the time restrictions. After the second session we were not able to resist the temptation to refactor our code.
- Pair programming is as beneficial as exhausting. Mental fatigue is a price to pay for high productivity. Thus it would be better not to plan any important or demanding tasks for the same day as pair programming. You may not be able to stay focused or be creative.
- It takes two to tango. Working in a pair requires effort and involvement from both sides – in terms of planning as well as programming. Better find a nice fellow then! ;)
What would we change in the future?
- Next time we practice pair programming, we will pick up a technology we are familiar with. We believe it will let us plan the project more freely and independently, coming up with solutions on our own.
- We would give Quokka a chance. The workflow slows down whenever it comes to debugging. No need to
console.logwould be time-saving.
Thanks for reading this article! We encourage you to comment and share your opinion on pair programming!
This article was pair-written by: