1. 1

    We pair on 90%+ of production code - as a rule of thumb we try not to push anything live if it’s not been paired on.

    It’s not just about having “real-time code review” although that is a bonus - we use it as a tool for knowledge transfer. The ideal situation would be the entire team having a thorough understanding of the whole stack from front-to-back, and we find that pairing is a way to facilitate that.

    In addition, I feel it’s a good technique for simultaneously picking up better practices and having fresh eyes to ask questions - if you can’t explain why you’re doing something, you probably don’t have a good understanding of it? (As a generalisation).

    That’s not to say everyone is forced to pair all the time, that wouldn’t make sense. Pairing isn’t nearly as useful if you want to spike something dirty as a proof of concept, I wouldn’t even write tests in situations like this. I believe it is useful in writing production code.

    tl;dr - pairing’s benefits are increased code quality in addition to being a good learning tool, a way to spread domain/tech knowledge within a team, and it’s a social activity as a cherry on top.

    Some don’t like pairing. I do, and I think it’s effective for me.

    1. 2

      But why are code reviews not adequate for knowledge transfer? This was, in fact, one of the reasons I pushed for code reviews at work. The only issue I can see is with big self-contained pieces of code, which tend to reach the review in one chunk. It is an issue, and it’s not too easy to work around. (Design reveiews solve some of that, but seriously, who designs before coding?)

      Explanation is a valid point, but if the code doesn’t speak for itself, it should be followed by “and now you’ve explained it to me, write a comment / rewrite the code simpler”. And, again, it should (and does) work in code review context as well.

      …but but but, production code is proof of concept code merged in a hurry ;)

      1. 1

        I think there’s a difference in understanding by doing (pairing) and by reading (code review). The code being written does not consist the whole of the functionality being deployed - data changes, for example.

        How many people have to review code where you are? (Honestly curious)

        It strikes me that if there’s no constraint on it then you would probably end up developing points of failure, which we try and counter with active pair rotation. Each person should have worked on a single feature or have knowledge of how it works for supporting the code in production, which I don’t see how can be effectively achieved in a code-review situation.

        If anything, I think pairing is occasionally not effective enough for our constraints - I much prefer Mob Programming, which we do and has been getting a bit of attention recently. (tl;dr it’s pairing but with the entire team). The advantages are that it reduces the time for everyone to understand the code, which is absolutely critical in things like code that affects finance/security and moves things much closer to One-Piece Flow - which is the way we like to operate.

        1. 1

          In our scenario all the data we have is in repos and undergoes code review as well.

          Everybody on our team has to review code. (One reviewer per merge.)

          If the code reviewer understands the code (s)he reviews, then knowledge transfer is done (though, granted, not as effectively). And if people are given tasks to do in various areas of the code, they get familiar with the codebase at large. But there’s a balance between this and “code ownership”: there are arguments for a small number of people (one?) having more impact on architecture and overall direction of the project, and the right point is not easy to hit. We may err on the side of code ownership, but I believe that if any of us gets hit by a bus, the others will be able to pick up the pieces quite quickly, although of course there will be impact.

          A former workplace with many programmers tended to err on the side of knowledge transfer. There was some specialization, but by and large everyone worked of everything. And, although they had around three architects, the codebase did exhibit the too many cooks syndrome, and its quality varied.

          It’s late in my timezone, so I’ll look at the links tomorrow. I should, however, say that I’m somewhat wary of all these new shiny processes promising the world. In my opinion, nothing is better than careful engineering, which requires time and quiet.