Pair Programming, why do we do it?
Why Pair Programming? This is an age old question that many software developers silently wonder to themselves — especially those of you that are used to sitting in a dark lit room in front of a monitor with EDM blasting into your ears hammering out unit tests. I can’t tell you why Anytown USA Software Company LLC pairs, but I can tell you why we at Enfuse pair.
Pair programming can be frightening to those who have never practiced it. It’s only natural to be afraid since you’re skill set with be exposed to the world, or to your pair rather, every single day of your working life. So yea, definitely, at first the thought of it can be a bit daunting. At Enfuse our developers have created a culture of openness and sharing. When someone finds out something really really cool, you can be sure that you’ll hear all about it at the stand-up the next morning. And that essentially is what pairing is really about — sharing cool things and doing cool things with the person next to you.
I can’t count how many times I’ve been soloing and stuck on a particular problem for hours at a time, only to walk down the office and strike up a conversation with a colleague resulting in my problem being immediately resolved. With pairing, you don’t have to hunt anyone down. You don’t have to @here every slack channel you can think of asking for a solution. Typically difficult issues are resolved much quicker with two people working on the same bit of code. At Enfuse you’re encouraged to be as vocal as possible when you’re pairing, whether you’re driving or navigating. Blockers become puzzles to the pair, just another challenge, and eventually as they reach the summit an air of confidence and new skill nicely settles into their mental software development toolkit.
After a couple of week into pairing you’ll notice that your toolkit becomes much more robust and efficient. If you haven’t worked with a certain API, or you just haven’t quite gotten your gradle build to work nicely with Spring Boot and Apache Spark — there is a pretty good chance your pairing partner has. These sorts of obstacles are easily defeated by the pair.
At Enfuse we despise the “I’m an expert at this one thing, I’m the guy that does this one thing” attitude. If you’re a Java programmer, we don’t want you to become the JPA guy that handles all of the database connection issues for everyone. We don’t want you to become the only person that knows how to setup the Jenkins pipeline. We want you to become the JPA, Elasticsearch, Hadoop, Spark, and Microservices guy. This also happens naturally since you switch pairs and stories throughout the day. Context switching can be sometimes painful, but what you’ll find out is that in a few weeks you know just about every project that every Enfuse developer is working on at any point throughout the day. If it isn’t obvious by now, pairing results in context sharing. How many of you have been working on a sprint with a future prod deployment date lined up only to have Gary go on vacation the week before? “What the hell Gary? You knew the prod deployment was going to happen!” We don’t worry about this sort of thing at Enfuse because any of our developers can hop on any project at any point throughout the workday. This is a direct result of randomizing pairs and stories throughout the day.
Pairing isn’t a methodology that you should be afraid of, but a methodology that you should be yearning to embrace. Lets summarize: Solo programming can lead to dark lit rooms with EDM and tons of blockers. Pairing naturally builds your toolkit, removes blockers quickly, allows you to develop great working relationships, and ensures that you can go on vacation. Clearly we’ve found an obvious winner.