For quite some time, a lot of companies have been on the “yes, we do pair programming” bandwagon. Some of them even to the (ridiculous) extent that pair programming was mandatory. So something like “at least 2 days a week”.
I’ve been through that and those were certainly some bad times in my software development career.
I never liked pair programming to begin with.
First of all, it’s synchronous. You have to pay attention that very same time your partner pays attention. But people and their rythm are different and if you do this all day, this gets exhausting very quick.
Second, regardless of what technology you’re using, there will always be artefacts you have to generate and update. If you use languages like Java this might amount to a lot. But even with something concise like ruby this will steal a lot of your time.
And during that time one partner takes care of those artefacts the other drifts off – there’s just nothing you can do about it, this is how most humans work. And if one partner looses focus, he takes the other one down with him ususally.
So, in an nutshell, pair programming sucks hard.
So what are the alternatives?
They have all the benefits of pair programming but none of the disadvantages. They are asynchronous by design so you can dive into problems when you feel like. Your time, your speed. Very important.
There are a couple of exceptions though where pair programming makes not only a lot of sense, but offers significant benefits:
- Learning workflows from your partner. Sure you can read up on git and friends, but nothing makes it easier for you than to see those git workflows in action. Also, seeing how your partner executes those workflows takes the fear away to fuck up things on the remote end when you have to do it yourself: You have not only seen how it’s done, you have seen the result of it. To stick with the git example, a lot of git novices are afraid “cause damage on the remote git repository” – seeing how easy it is to juggle multiple branches and pushing to remote lowers their mental barrier.
- Learning how to use tools from your partner. That’s basically how I learned vim. Granted, this only makes sense if you use something obscure and poorly documented as vim.
- Onboarding. That probably needs no explanation.
I guess with pair programming it’s like with everything in life: Don’t make up rules just for the sake of having them and follow them without questioning them.
Use pair programming scarcely. In most cases you can achieve the same thing better with pull requests.