Pair programming a start guide for newbies

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 couldnt resist spending an extra 30 minutes adjusting the functionalities and patching what we've coded together.
Done! Now its time for summing up how we felt about pair programming.

Its like a real rally only without a car

Annas impression of being:

• a navigator as I like to plan and solve problems my way the role of navigator suits me better. Its 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.

Matts 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 Drivers 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 Navigators 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 didnt touch the code without the drivers 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.

Lets sum it up!

• Why does pair programming pay off?

  • No doubt its very beneficial, especially for a junior dev. Working in a pair is a great opportunity to see others 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 its 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.

• Its challenging!

  • Keeping ones mouth shut is not easy. Asides like What a nice keyboard shortcut, I didnt know it! or Yesterday I had the same problem are distracting and dont 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.log would 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:

.ltag__user__id__543402 .follow-action-button { background-color: #0074f0 !important; color: #ffffff !important; border-color: #0074f0 !important; }

AnnaBuller

I am a junior frontend developer and ex-physio. My mission is to refine communication in IT world.

.ltag__user__id__497133 .follow-action-button { background-color: #0074f0 !important; color: #ffffff !important; border-color: #0074f0 !important; }

Mateusz Sowa

Junior Front End Developer, Aviation and Cosmonautics MEng. In love with JavaScript, React and flying.