Yes that’s right, we’re scared of it, all of us, and for different reasons. Lets explore those reasons and shed some light on how we can get over it and embrace what should be a truly rewarding experience for both business and developers…
Lets start at the top shall we? You’re the owner of a startup, or the CTO, or the manager of some… no wait, actually I’ve changed my mind, you’re not that important when it comes to this topic, because you’re smart enough to have hired people smarter than you. Right?! And if they tell you that the best way to solve something is X, then you’ll let them use X right? OK good, glad we got that out of the way.
So where was I? Oh yes, the most important people in a development team — the juniors. Why? Well I thought it was obvious! They have sponges for brains, the eagerness of a six month old puppy, and are as malleable as playdough on a hot summer’s day! They won’t stay that way for long though, so it’s really important that you don’t project any of your own personal baggage on them, and that includes your fears about pair programming. They need to learn from their seniors that this is not something scary they’re going into, but rather, likely the single most productive learning experience of their lives!
But first, let’s deal with the excuses and the fears…
The things we are afraid of
When it comes to coders, be they juniors, mid level or senior, there are quite a few things that scare us. Deadlines scare us. Especially those tasty unmovable ones with a fixed scope of work attached to them. Talking to people, that scares us too, we’re much happier punching away at a keyboard thanks, well, many of us are anyway.
What about exposure? Yes, that’s a big one. Every good programmer I know suffers from a healthy bout of impostor syndrome and are desperately afraid of being called out as a fraud. Let that one just simmer for a while if you don’t get it just yet…
And speed? Yes, we worry about that too — fear of being judged too slow in solving a particular problem, even though the people expecting the solution, couldn't or haven’t solve it themselves.
Sometimes we’re also afraid that bringing someone else into the problem space will slow us down — that somehow, we’re all Einstein or Tesla pacing around the room solving life’s mysteries at the speed of thought, and bringing anything into that sacred space will scupper our perfect process.
The things we love
We love distractions! We’re like magpies to a fistful of silver. Every new piece of tech, every new meme or YouTube funny will draw our eyeballs away, pulling us further from the work we set out to do that morning.
We hit a wall at solving a particularly sticky problem, and all that stuff is there waiting for us to procrastinate ourselves into oblivion. Ooh, an email just came in, better respond to that real quick. Woohoo! I just got a retweet! What do you mean 3 people just looked at my LinkedIn profile?
We love slacking it up (yes I’m pretty sure I just invented that term) with our colleagues around the proverbial (or literal) water cooler, or taking a power nap, or playing table foosball to build camaraderie.
The problem with pair programming
Herein lies the crux of the issue — pair programming brings the things we fear toward us, and pushes the things we love further away. And we hate that!
It puts a razor sharp spotlight on your coding and problem solving ability because now there’s someone there to judge you … real-time! And that person is freaking out about exactly same thing!
Does it worry you that you can’t pull a binary tree search algorithm from under your hat on demand? Do you feel embarrassed that your pair partner will watch you dig up an answer on StackOverflow to something that should be trivial, but you just could not recall at that moment?
This is normal, and it’s also OK
It puts someone in your ear, and they’re going to ask you all sorts of questions. And you’re going to have to have good answers if you want to write that next piece of code you were about to. They’re going to poke and prod, and force you to think about the best solution, not the quickest to code, about what’s right for the team (or the customer), not what’s easiest for you to tick a box.
It prevents distraction from creeping in too easily, because now both of you have to agree to get distracted. You both have to take a break, get a cup of coffee, read your email or play foosball. You both have to agree to switch context. And if you’ve only just done that 15 minutes ago, then it’s going to be a weird conversation, because now both of you will have to buy into it, and that’s a lot harder than doing it when you’re alone, hoping no one will notice.
Who the hell would volunteer and actually ask for those kinds of working conditions?! They must be nuts!
The elephant in the room is this: Most of us are lazy. Unless we are incredibly motivated by a particular goal, we’d just like to collect our salary each month for as little work as possible by (only just) hitting that required bar set by our employers. This is the natural rest position. It takes a lot to move that needle, be it the prospect of more money or success, a truly great manager or leader, internal or external kudos or sheer desperation caused by some outside influence. Either way, we are very good at giving excuses in our own heads, but for some reason, we don’t or can’t do that when we’re working in pairs.
What you need to realise is this: these are bad habits formed over many years and it’s an incredibly hard cycle to break, almost impossible to do alone, but definitely doable when two people agree to work on it together. Habit-forming has long been touted as an incredibly powerful productivity tool, and it’s no different with pair programming — it needs to be habitual, otherwise it just gets forgotten and ignored.
Acceptance is the first step
As is the case with so many things, admitting that you suffer from one or many of these things is the first step in overcoming your fear of pair programming. Saying that you just don’t like it or it doesn’t work is a knee jerk reaction I’ve seen so many times when one or more of the underlying symptoms above is the cause of the disdain.
There really is a whole new world of productivity nestled away over that hump and if you value your work, your output, your creativity and your legacy as much as I hope you do, you’ll try and get past your fears, your reservations and your laziness, and decided to give it a real shot!
Some things work well in isolation- art, meditation, reflection … and going to the bathroom! But some things are best tackled with two minds focused on the same goal, and I can, hand on heart say, that programming is one of them!
One of the biggest reasons for not trying is that we’re afraid that it just won’t work, for my team, for my scenario or in my environment. How do you know, unless everyone in that team, scenario or environment have confronted their fears about it? How can you possibly know?
Conclusion
In my next post, I’ll be going through how to get the most out of pair programming both for you as a developer and the business you’re creating or working for. But there’s no point even going there unless you’ve been able to at least acknowledge your fears about it, even if it takes some time to get over them.
Topics I’d like to cover include:
- Pairing for junior and senior developers
- What to do when I don’t have a pair partner
- Pair programming benefits for managers and company owners
- Is it worth pairing up on more than just programming?
- Better estimation and delivery in pairs
- How pair programming can be the death of context switching
Let me know if any of these mean more to you than another or if you have some other pain points you’d like me to address here. And best of luck confronting your fears!
