On Pair Programming, Birgitta Böckeler & Nina Siessegger

This resource first appeared in issue #4 on 31 Jan 2020 and has tags Technical Leadership: Software Development, Managing A Team: Knowledge Sharing

A great description on the hows and whys of pair programming, a technique I don’t see very often in research software development (though giving how subtle some pieces of what we work on are, it might be useful).

There’s two big advantages of pair programming - knowledge transfer/collective code ownership (at least two people know how some piece of code works), and code quality (two people’s input is better than on). (It can have advantages for helping the team learn to work together, but that can cut the other way too).

Of the two I think knowledge transfer is probably more important - a piece of code that only on person understands is going to get quite brittle over time.

Even if pair programming doesn’t seem like a good match for your team, the material pairs really nicely with some of Chelsea Troy’s posts on pull requests and commit messages as a way of doing distributed, asynchronous collaboration - pair (or more) programming. It’s not enough to simply justify the change being made; the goal in Chelsea’s model is to get some of the advantages of pair programming without requiring synchronous and possibly in-person collaboration.

(And it turns out you can easily give (some) credit for peer programming in git, which I didn’t know).