Coding Is When We’re Least Productive

One old dragon that’s reared its head again in this “age of AI” is the very wrongheaded notion that productivity == code. Managers aim to maximise the amount of code their dev teams produce, and so they maximise the time devs spend writing code.

Let me tell you a story about the value of code.

When I first started contracting, I worked on a Point Of Sale system upgrade for a major retailer. I was stuck on a feature, and just couldn’t wrap my head around the use case because I’d never actually seen their existing system in operation.

So I walked to a local branch on the high street, showed them my security pass, and asked if I could observe and – when the cashier wasn’t busy – ask questions.

They told me they could do better than that. Upstairs they had a room with a working till in it, which they used to train new staff. They also used it to test system updates, which was the first time I’d seen what we now call a “model office” for software testing.

We were able to run through the use case scenarios I was stuck on, with them showing me how to use the POS system to achieve specific goals. The mist cleared. It was like I’d been reading a book on how to ride a bicycle that had no pictures, and then someone gave me a bicycle.

Enlightened, I walked back to the office and changed about three lines of code. That was all the coding I did that day. Three lines, in 8 hours.

But if I hadn’t made that trip and seen for myself, and had a chance to talk to a department manager in that store, those three lines would have been applying special offers wrong. (If only the person who wrote the spec had done this in the first place…)

Now multiply that error by 250 branches nationwide. I potentially saved my client a bunch of money and embarrassment with that 3-line change.

Now, I consider that a productive day.

But had I been measured on my contribution by lines of code, or commits, or features finished, it would have been seen as a very unproductive day by my manager.

I may have felt pressured to stay at my workstation, bashing out more code, compounding the mistake and costing my client more money.

A very teachable moment for me early in my career. The lightbulb pinged: some code is worth more than others, and coding and productivity aren’t the same thing.

We could even argue that coding is the interruption. What’s the shortcut in IntelliJ that tells you if you’re writing the wrong code? Oh, that’s right. There isn’t one.

When I’m heads-down-coding, I’m not seeing, I’m not asking, and I’m not learning about the problem. To do that, I have to get up from my desk, go to where the problem is and/or the people I need to ask are, and have a conversation. Let the dog see the rabbit.

This takes time. And if we’re producing code faster than we can validate it – either by exploring the problem ourselves, or learning from user feedback if our release cycles are fast enough – then we’re piling assumptions on top of assumptions.

I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.

If productivity, in reality, is a measure of how much net value we create, then that learning feedback loop is where the real productivity happens, and not at our desks punching keys. Coding is when we’re least productive.