This is my highly anticipated first blog post about some interesting software practices and techniques. The first topic: Pair Programming. Wikipedia defines it as two programmers working together at one machine, one “driving” (i.e. typing and mousing) and the other “navigating”. Others define it as a waste of time and money: two developers working on the same thing?!
Most software-related courses at university will try and expose students to this way of working but in the professional world there are still many software companies who shun the practice; in fact I remember even at university one of the lecturers complaining that his class had been stuck with it that year. I, with all respect, have an opposing view to my old lecturer and believe that it is a worthwhile practice that promotes learning and higher quality work.
In my experience I think there are two ideal scenarios for employing Pair Programming:
- Pairing someone who is new to a project with someone who is currently working on it
- Pairing less experienced developers with more experienced ones
An important thing to note is that Pair Programming doesn’t simply involve a handover-type discussion or advice about how to tackle the problem, but rather two developers working on a problem from start to end at the same machine. One of the best parts of working this way is how much more easily knowledge is transferred as I think most developers would admit they have gaps in their knowledge and have had that moment where they catch someone using a shortcut or another way of doing things that they never knew about. Things like auto-generation of SQL scripts, or small tips like ‘windows-key+L’ to lock your machine (depending who you work beside).
Another benefit of working this way is that the problem being worked on generally gets completed a lot quicker and with fewer bugs, I think there are a few studies out there that show this, though I will only talk about my experience with it.
In terms of actually pairing with someone, once you get over the initial oddness of working with someone over your shoulder, it’s more enjoyable to tackle a problem as you have someone to bounce ideas off, knowledge gaps are filled, and you both ensure you’re not going down the wrong road.
As a practical point I would recommend switching up who is “driving” fairly regularly. In the cases of graduate or even inexperienced developers it’s probably best to keep making sure that they understand what’s going on and why you’re making certain choices; this should help avoid them sitting simply watching a blazing blur of clicks in horror. An additional point in that case would be asking the inexperienced developer what the next step should be as opposed to just telling them what it is and working through the steps mindlessly.
Now I’m definitely not saying that Pair Programming should be used all the time and on all projects, a bit of common sense is needed. But for scenarios like the above or particularly complex problems, it seems fitting to use a collaborative approach like this in order to develop better software, and indeed better developers.
Just my two pence anyway…
Martin