“Nobody here is qualified enough to review my code!”

It was my first day on the job. This was a wee bit back, and the company I had just joined was having … issues … getting stuff out the door. “Any day now” had turned into “It’ll ship in two weeks”, and that was a cool 3 months in the past, and eventually, I got called in to help get stuff unstuck.

So anyhow, it was my first day on the job, and I was poking around the repos, trying to figure out what was what. After a couple of baffled hours, I figured out that the development process seemed to be eventual-consistency-git — everybody developed against their own branch, and cherry picked from each other to get updates. A “release” involved nominating one developer (and their branch!) as the primary, and having everybody else stop work. The primary would then painstakingly merge in all the other branches, maybe resulting in something that worked.

And yes, this was utterly bat-s**t crazy, but whatever. I put a little bit of order in place, just to get people working on the same page. Feature branches, commit-merge separation, code reviews before merge, oh, you get the point. It was all really basic stuff, and everybody bought in, right up to the point when a couple fo them realized that “code reviews before merge” applied not just to the others but to them too! The arguments were all over the place, but eventually settled down to “Nobody here is qualified enough to review my code”.

Yes, this could have been accurate. After all, they could be the only Kotlin devs in the house, or maybe they were doing some deep statistical analysis that nobody else has the background for. But then again, even then, a code review would be a good thing. You could sit down with the reviewer, and walk them through what you’re doing, why, and how. I guarantee you that in the process not only would you find something that you missed (Rubber Duck FTW!), you would be bringing someone else up to speed on your stuff, and thus helping delay the “hit by a bus” sweepstakes.

That said, they were not the only Kotlin devs in the house, and they were most certainly not doing any deep statistical analysis —if anything, it was fairly run-of-the-mill stuff. The issue was their desire for control — by letting somebody else review their work, they were ceding control over their work, and to them this was an attack on the very core of their being.

I spent the next few weeks defending the values of teachability, humility, and a desire for excellence in them, but hey, these were #CowboyDevelopers and particularly ornery ones. I eventually gave up and implemented the rules by fiat, and things worked out (and we shipped a few months later!).

Could I have just implemented the rules by fiat right up front? Well, yes, but it turns out that the effort was worth it — it turned out that only two of them were actually #TechBros, with the rest basically following their lead. And once they saw the light, they actually ended up being some of the most productive members of the team…