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.
These two guys met at the JavaScript mentorship program and decided to join forces. They dove deep into pair programming rules, completed an HTML Canvas Project, and summarized their effort. Now they also want to share their experience with you!
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!
Choosing the right project!
For your first pair programming project, it is reasonable to choose something straightforward or at least non-time-consuming. We suggest you choose from one of the Wes Bos JavaScript 30 Projects. These are tiny but still engaging mini-apps written only with Vanilla JavaScript (ES6+), some HTML, and CSS. We decided to code Project #8 - Fun with HTML Canvas.
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…
Planning the cooperation
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.
The golden rules of pair programming
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.
Driver
- 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.
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.
Both
- 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.
Settling the app functionalities and the file structure
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.
Creating a mind map
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!
Pair programming sessions
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.
It’s like a real rally – only without a car
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 are the champions” anyway
- 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.
Let’s sum it up!
-
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.
-
It’s challenging!
- 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:
Top comments (8)
That's a great and detailed checklist about how to start pair programming.
I've been doing pair programming for a long time now, and I can reassure you that it becomes less exhausting as you get used to it. Don't expect to do more than 6 hours of intense pairing per day though. That's the amount we managed to do in teams where we were pairing most of the time.
One other interesting thing you noted is how intolerant to wasteful work we become when we are 2. A team might very well accept to lose a lot of time in debugging when everyone is doing it on their own, but as soon as you start pairing, it becomes unbearable. Next time you try pairing, try TDD at the same time. Done well, it removes 99% of your debugging time, which lets the pair focus on productive work.
Thanks again for your post!
Thanks for the comment! It's really nice to hear you appreciate our work and that pair programming becomes less exhausting after some practice (comforting words! ;) ). Guess what - we wanted to try TDD the next time we do pair programming. Now we have the real reason to do it (and to write another article about it :D ).
Good luck! I wish you these practices bring you as many benefits as they did to me.
I personally cannot think of a worse way of programming
Why do you think so? Have you tried it yet? :)
For me, programming is an intimately personal, creative activity - akin to painting or poetry. What you produce is a distillation of your thought processes on how to solve a particular task. Having someone observe and critique how your mind works - as it is working - is about the best way to destroy your flow or train of thought.
And yes, I have tried it... Never again
Totally agree with your point of view! :)
But keep in mind that splitting roles to the Driver and Navigator doesn't restrict your intimate thought process. Moreover, it encourages you to maximize your focus on the task. Navigator is the brains of the whole operation at the time. He constantly thinks about the whole process and should not be distracted by typing the code or the Driver's objections.
One of the mandatory rules of pair programming says: "trust the Navigator" :)
Wrong. It completely changes and restricts your thought processes as you keep having to articulate those thoughts in a way the driver understands (which may not be easy)... and give directions to the driver, hoping they'll follow them correctly