Coding Is When We’re Least Productive

I disagree with any kind of generalization about whether coding is the "most important" or "least important" part of the job. It depends!

I recently had to redesign a bunch of our telemetry pipeline at $work. Everyone was in agreement about what needed to be done, it was just a question of doing it in a maintainable, efficient way. And all my "plan it out in advance" time was ultimately far less productive than "write the code, decide I don't like it, rewrite this other bit, and so on" (because it was a roughly ~1kloc change overall, I'm a fast typist, and I would reuse parts from other attempts).

A coworker also recently singlehandedly made writing tests for another part of our codebase a hundred times less painful by writing a bunch of clean builder APIs. We've been going through a massive rewrite motivated entirely by design deficiencies in the current codebase that's also enabled us to ship dozens of features that were impossible in the old approach. And so on.

I remember a lore about the pointlessness of using lines of code as a mesure of productivity: where a programmer reported the deletion of a few hundred or thousand lines (I don't remember the exact amount) instead of addition like others. (edit: thanks ~mullr and ~fanf for pointing out.)

There's also Naur's Programming as Theory Building, quite worth reading in this context.

This is true iff your most efficient way of learning doesn't involve writing code.

Quant finance can be a counterexample. Depending on the domain, you'll usually want to backtest a large number of algorithms to learn what works. Coding is often the most productive move, and we often push people towards less theory and more experiments – just run every idea that comes to mind (and develop infrastructure that makes this easy.)