A while ago an interesting debate occurred between my coworkers regarding pair programming. We all follow this practice at LeanMind as much as possible, but some of us do so pretty much 24/7 while others have a more selective approach. This led to an interesting conversation that made each other more aware of the way others view this practice.
When is pairing not fit for purpose
Itâs only fair for me to point out some valid considerations regarding what can go wrong with pairing, before arguing why you should still do it.
Productivity
One might argue that, if the task is simple enough, having two developers tackling it is a bit wasteful. Sure, complicated o critical problems might require group collaboration but maybe if we could get more done on our own, we should.
This will probably resonate more with business people than with developers, weâll see why in a bit.
It aintâ easy
Some people are more social than others. Even the same person can be more social one day than the next, and thatâs okay. Thereâs an argument to be made for not feeling pressured to pair. It shouldnât be a mandatory thing, but rather a scenario to strive for.
Take a break from time to time, change partner, ease yourself into it. Computer people are not really known for their social skills, nobody expects an introvert to want to spend 8 hours straight with a co-worker.
It might be healthier to think of pair programming as an objective in some cases, rather than âa thing you just doâ.
Everybody is different
Just like with any other human interaction or relation, some work and some donât. This can be harsh and hard to deal with (for some more so than for others).
Some get distracted while being the ânavigatorâ and wander around not really helping a lot. Some want things done their way and canât seem to listen while being the âdriverâ. Some may not be willing to swap out the role at all.
Dealing with these situations is quite simply not developing software. And you can bet that your average developer has zero interest in resolving issues like these (although one could argue that they probably should).
Juniors might hamper Seniors
No matter how you define âJuniorsâ and âSeniorsâ (or if you just donât care much for the terms at all), people with less knowledge and/or experience in any particular subject will inevitably take longer to understand things and have a lot of questions.
Itâs easy to see yourself pairing with someone more or less at the same level you are, but it can be annoying to have someone stopping you at every step to ask you basic (although very valid) questions.
One could consider pairing partners based on experience, although there are very valid reasons to mix and match experience levels.
Pair as much as you can
Now for the good stuff.
Beware the bias
Iâve been very lucky in this regard: Iâve written some code on my own, but I have never worked alone.
I started a while back in a team that felt more like a bunch of friends than a work group. Not that we werenât getting things done (we were even helping other teams on a regular basis), we just worked in a very friendly and enjoyable environment.
We laughed a lot and were there for one another, it really felt like hanging out with some friends.
Just keep in mind that someone less fortunate might not feel the same as I do about pairing, which is totally fair!
Donât care much about productivity
It might be productive in the short term to have two developers doing two different tasks, but is it also in the long run?
When both codes need to be merged, but they seem like they come from two different worlds, is pairing still less productive? What about when one of them spends two days looking for a bug that could have been easily found in half an hour by just having double the eyes looking at the code? Donât you think you would benefit from a helping hand when you hit a dead end? Wouldnât you always prefer to know early if there is a better way? Do you really think that having some help or a different opinion makes you less productive?
Sure you could just ask for help when needed but that assumes everybody is mature enough to explicitly and openly admit they need help.
This is why I mentioned that business people might focus more on this than developers: The usually just donât see or understand the present and long term differences between clean code and spaghetti code. And thatâs not a criticism, it just isnât really their job to tell one apart from the other. They shouldnât be expected to. If anything itâs on developers for not knowing how to present these issues properly to the business.
Majority of us are noobs (and thatâs fine)
Uncle Bob has repeated this fact time and time again: Developers more or less double every five years or so. This means there are always a lot more inexperienced developers than experienced ones. There is an obvious need to take Juniors and their learning process into account when thinking about anything related to software development.
Itâs kind of strange that âshadowingâ isnât just standard practice in the industry, but if it were, it would benefit greatly from pairing. I canât think of a faster way for someone to get the hang of a particular language, framework, methodology or project than for him to pair with an experienced developer.
Sure you can do test projects on your own (and it actually helps a lot), but the level of insight and âknow howâ you get from watching a Senior hands on with the code, asking questions and receiving corrections and guidance in real time is just on a completely different league.
Of course, that will hamper his speed (quite a lot at the beginning), especially if the more experienced one actually cares about his pairing partner getting better on the job at hand. To this I would sayâŚ
Developer âflowâ is no good
It sure feels good: Being on you own, doing your thing at light speed. Just ripping through the code and solving tickets left and right. You look at your code after a week and have no clue what you wrote, why you wrote it that way or if there was a better way to do it. You overengineered half of it and didnât stop for a moment to see what the rest of the codebase looks like.
I would argue that being in this state of âFlowâ is only useful if you work on your own in a small and/or unimportant project. It seems much, much better in the long run (and for the rest of the team) to have someone stop and question you every once in a while. This will make you consider why you are doing what you are doing (and if you are making it unintelligible for the rest of us). If you can explain it simply you can be sure that you know what you are doing (and you will have taught something new to your peer, making both of you better off).
Nobody wants to be distracted while solving a problem, but when doing things out of inertia we can all benefit from an external voice of reason.
Good for the mind
Especially with remote work becoming the norm, itâs not really healthy to spend 8 hours a day solving problems under stress on your own. I know, it sounds strange, but we are supposed to be around each other. We are not built to be alone.
You might think you are better off on you own, but I can guarantee you will feel better with good company. Pairing can be fun, relaxing and morally helpful. Donât isolate yourself for no reason.
Enforces soft skills
Iâve been pleasantly surprised with how important soft skills are in software development and I can see a couple of clear benefits of pair programming in this regard:
Leave your ego at the door
If done well, pairing will force you to listen to others, overcome your ego and accept whatâs best for the team. You can never have too much of that.
Leave your personal problems at the door
Not only will this help you compartmentalize trouble (which is always good), you will have to decouple your mind from your personal issues. Thatâs just free counseling right there.
Forces professional behavior
A doctor doesnât just behave badly or work alone when he is ânot feeling itâ. He picks himself up and gives his best. Why should we not do the same?
Soft skills Hard truth
The reality of soft skills is that there is no method to it. You can watch what you say and how you say it. You can be more assertive and sensitive. But at the end of the day, you learn soft skills by throwing yourself into the fire.
You canât âthink your wayâ through human interactions. You deal with them as they come, in the context you struggle the most, screw up as many times as you need in order to get a feel for it and acquire that new skill (just like you would when learning to ride a bike). Working alone wonât help much with this.
When in doubt, program in pairs. Itâs good for everybody