Code Review as a Service

It's Rice's Theorem which tends to get me in trouble!

Oh, that is false. I guess it comes from a simplistic understanding of how people work (no, they are not robots). You may have two people engaged in the same task, but:

* People are more focused and work faster -- it is much easier to stop yourself from procrastinating when you have other person on the call.

* You get people exchanging tacit knowledge. With people changing pairs knowledge will tend to spread over entire team eventually very efficiently.

* You get flexibility of having any of the two people being able to continue the task (if one quits, is sick, has to take day off or step out for a meeting) -- the work is much more likely to progress uninterrupted.

* You get much less chance for the project to get stuck. When one person doesn't know how to do something the other person might know.

* You will tend to get better quality results (for example any bug needs to pass through two pairs of eyes, etc.) -- and that means less time wasted on other parts of the pipeline, less technical debt, etc.

* When you get a new dev on the team, the first assignments are much less likely to get screwed up because you have other seasoned dev in the pair.

* You get a natural mechanism to get a new dev onboarded and have knowledge transfer -- they get up to speed many, many times faster than if they are just dropped alone on a task.

* Good code review isn't free either, it would have to take a significant portion of the effort to write the code anyway.

* You get people socialising while doing useful work. Which is extra difficult while working remotely. Having tightly knit team is very valuable.

* People are overall more happy and engaged when the work goes faster. Have you noticed you feel better when you stand in one long queue that progresses fast than if you split it into multiple queues that progress slowly, even if overall wait time is the same?

* Having work done faster (by two people working on it at the same time) makes for faster cycle time and in consequence lower complexity (less things being worked on at the same time). Lowering complexity is very valuable.

* While we are at complexity -- normally doubling people in the project does not cause it to progress twice as fast or cause the throughput to be twice more. Being able to treat two developers as one, uber-developer doing work more efficiently is very valuable because it allows counteracting at least part of that diminishing returns trend (ie. you have have larger team with efficiency of a smaller team).

* As a tech lead this is fantastic way for me to get to know people, their strengths and weaknesses. I can then help them with weaknesses and maybe learn something from their strengths. Getting to know the complete picture of the team is extremely valuable.

And many other reasons.

When you take that into account you will find that, if done correctly, pair programming will be more efficient. Especially long term, because some of the effects take time to kick in.

**

Now, working in pairs isn't free:

* Working in pairs requires people to have high standards when it comes to their behaviour towards their peers. Working in pairs requires absolute adherence to the "no asshole" rule.

* As a manager, you need to react very quickly to people having trouble working together because in pair programming this is going to immediately destroy productivity for two people.

* Costs of disruption is magnified when working in pairs. For example, if you have to wait for approval for something -- now you have two discontent people waiting for the approval. If one person has to join a meeting -- the other person will not be as efficient and they will have additional cost of syncing afterwards.

* You probably want to hire people that are specifically mentally designed to be able to work in pairs. Some people just prefer to isolate themselves and work alone -- these will have trouble functioning in a team that uses pair programming. It doesn't mean these people are worse, they are just worse for that particular team.