Write code like you're slinging hash

A couple of years ago, I went to this tiny diner bore witness to a thrilling display efficiency. The grill was set up in the dining area, and as I sat at the bar, I watched a cook and a couple of manic waitresses weave chaos into order. Tickets flew, orders crackled and sizzled, and the staff's movements and chatter were a symphony. The food being served was chosen because it's delicious and quick to make. My coffee cup stayed full, and despite this being their busiest day ever, we were probably in and out in 45 minutes.

In software, we say, "development is unpredictable and impossible to reliably estimate." I'm here to say that, after twenty years of programming, I think that's mostly horseshit. I still believe strongly that a programmer's job is to think, but thinking doesn't need to be unreliable or unpredictable.

Setting aside some well-deserved vanity, most development follows fairly standard idioms that can be predictable for an experienced human to navigate. Talk to Haskellers and many will tell you that, after some initial exertions, Haskell almost writes itself. So, where is all of this unpredictability and complexity coming from, and how can we get closer to diner workflows?

Most teams are not honing workflows because they simply don't think it's a thing. Instead, we have big lists of "best practices," and ownership of workflow efficiency is placed squarely on the shoulders of hero developers. Those best practices are usually so horribly defined that they're almost meaningless. Like the philosophical equivalent of an inside joke, they make those who already understand them feel wise, but yield almost no value to those who don't (but that's another post).

Coordinating as a team to steer code towards simplicity and predictability is far more effective than reciting vacuous best practices, obsessing over test coverage, or noisy and overly opinionated linter rules. In particular, resolving tech debt and writing brief yet clear documentation both deliver ridiculous value over time, but that value is easy to miss if you've never seen the end result.

The up-front cost of honing workflows can feel like wasting time on nitpicky stuff that doesn't actually matter and that we don't make any money on. But over time, our development workflows gradually stop feeling like amateur cooking hour in our messy home kitchen and more like slinging hash in a professional kitchen: Simple, rapid, and predictable (I wrote Sapling to make starting right easy).

One final note: Deciding what's on the menu is at least as important as honing workflows. Engineers can and should push back against requirements that are unnecessarily complicated to deliver when there are suitable alternatives. That doesn't mean "be rigid", but it does mean that pushback is an important dial to play with.