Happy Gilmore is a 1996 Adam Sandler movie about a guy who’s weirdly good at driving golf balls, and so becomes a golf celebrity even though the rest of his technique is terrible. I’m not into golf, but there’s a scene in the movie in which Happy’s coach advises him to treat the ball like it wants to go home. (Happy fails to sink the putt, loses it, and yells at the ball instead.) I think of this scene whenever I see teams who seem more focused reviewing code than on shipping it.

I have a pretty simple theory of code: code wants to be committed and deployed. It wants to go home.

The goal is to ship. Trapping workable code in a branch to debate things that are trivial to change later doesn’t help anyone, but it’s common on teams that make code review so onerous that each small decision feels irreversible. Merge it already, and fix it next. Continuous integration is a process, not a tool.

In general, if you raise the price of a thing, you get less of it. Having a clean build is important, as is aligning on good practice, but making code harder to ship also makes it harder to fix. One of the things I liked about how we wrote code on XP teams many years ago was that codebases weren’t kept clean by rigorous gated review; they were made clean through continual small-scale refactoring. Those teams built safety and trust by leaning into change, not avoiding it.

A good way to speed up development without compromising on safety is to supplement human review with automated review. Replace debates over style with formatters and linters. Use automated vulnerability checkers. Write tests that enable rapid feedback loops.

If you want to move fast, make change safer, not slower.

Photo by Thomas Park on Unsplash