Why We Killed Off Code Reviews — RealScout Engineering

Update: Some really good discussion happening over at Hacker News.

Like many devs these days, most of us at RealScout have worked in some variation of the popular feature branch git workflow for several years. Pick up a feature, create a branch, code, create a pull request, CI runs, someone reviews it, then it gets merged into master. Simple enough. And it worked well.

Three months ago that process stopped and we started committing directly to master.

100% Pairing

Last November, we decided to pack our bags and make the trip everyday from Mountain View to San Francisco to work with Pivotal Labs for three months. When we arrived, we were thrown directly into 100% pair programming and the new git workflow (or lack thereof).

We were a bit hesitant at first: We really liked that pull requests were a great place to hold a conversation about a nice dollop of work.

Without them, we thought that we’d have decreased visibility across the team. We also wondered if breaking the build on master would block the rest of the team too much.

It would take a few months for everything to really sink in, but we drank the kool-aid and went with it.

Unexpected Benefits

Although we had all paired before from time to time and were aware of its costs and benefits, the following things really hit home after working in this model for three months.

Shared Knowledge

The amount of knowledge sharing has been unbelievable. Shannon and Luis, javascript and CSS whizzes, respectively, can now stand on their own across the stack. We’ve also extracted a lot of domain knowledge from Michael, our CTO, who built most of the app from the ground up.

This knowledge sharing will continue to payoff as we onboard new hires.

Accountability

It holds us accountable to make sound decisions. When pairing, there is some good social pressure not to take shortcuts — tests are always written and we refactor/rework previous work to better fit our new model of the world as we learn new things. The readability and simplicity of our code has gone way up because of this — as has our test coverage.

Decreased Overhead

We now fully understand the overhead of branches and pull requests. It’s not just the act of checking out a branch, writing a great pull request or the 200 LOC/hour for the reviewer.

You push a pull request. Someone else has to stop what they’re doing to review it. Meanwhile, you’ve started the next feature. If the reviewer has questions, you’re pulled back into that conversation with possible changes to make after the fact.

That’s quite a bit of context switching for both you and the reviewer. With pairing, once you push and CI goes green, you’re done.

What about the downsides?

It’s not all peaches and cream of course — pairing all the time does have some downsides.

Tiring

Pairing can be exhausting. Not everybody thinks the same way and you’ve got to work through that with your pair. Sometimes it’s really fun to put on the headphones and just jam away on your own.

Short Term Gain

Short term gain is put aside for being able to move quicker in the future, which is hard to reconcile in the moment. With a small team of 4 engineers — that means we’re only making progress on two tracks on any given day.

Life happens

While we try to commit to 100% pairing, if someone is out sick or has to leave early, there’s always a chance of an odd-dev-out scenario. While these moments are few and far between, the occasions when it does happen can be jarring and break our flow.

Here to Stay?

So will we keep pairing? Heck yeah.

To my surprise, pair programming has worked exceptionally well for our team. The gains in shared knowledge and decreased context switching have helped us immensely.

Will we pair forever? Who knows — we’ll continue to adapt and change as our team changes, but for now, it’s how RealScout codes.

Originally published at eatcodeplay.com on February 24, 2015 by Chris Conley.