Two Heads are Better than One
This past week, I reached the stage in my coding journey where I collaborated with others on a single web application: A kitchen helper known as Kitschy. Prior to this, all of my endeavors were solo projects and that approach has it’s benefits: I can work at my own pace, set my own schedule and I completely understand the code I’m working on.
Unfortunately, if you’ve had some coding experience, you’ve probably reached that point where you hit a wall and nothing you’re attempting seems to work. It’s by far the biggest obstacle to both the least and most experienced coders. And over the course of this project, the most consistent solution was implementing the agile development practice of Pair Programming
There are several reasons why this ended up saved some time:
First, exposure to other people’s code pays dividends down the lines, especially if you have less experience. My biggest weakness at the moment is my unfamiliarity with objects as a data structure. And the person I pair programmed with the most was much more familiar with them, so just looking at the way he codes and trying to navigate taught me a lot.
Second, just having to re-iterate the problem can sometimes reveal the missing link. During my teaching career, I always rejoiced when a student started to explain their problem, only to abruptly say “Oh, wait, neverminded I think I just figured it out”. As computer programmers, we’re constantly translating between computer logic and human language, and talking to another human about our code is an underrated tactic.
Third, and probably the most obvious benefits, sometimes a second pair of eyes can catch things that you missed. In any problem-solving situation, it can be very challenging to remove your own assumptions, and so a different person who never made those assumptions can bring about solutions much faster. Everyone has different methods of coding, different methods of debugging and sometimes a different skillset can yield different results. It’s not even strictly about experience; sometimes the solution was something we both were well aware of, such as event listeners not playing nicely with dynamically generated buttons in JavaScript.
Pair Programming seems counter-intuitive at first: How could two people working together on one screen outproduce two people working separately on different parts of the code? But when you know how much time gets lost to being ‘stuck’, The benefits are clear. The most consistent time-saver for our group was to either switching drivers (the person writing a section of code) or having someone navigate to catch issues. Even in situations where we both had to work on separate features, just having someone in the same room as you who you can easily ask a question proved immensely beneficial.
