What is a programmer's job?

An anecdote about a bottleneck disaster

I knew I was in trouble when the product owner argued we should record story points because "they were standard agile practice." It was the first of many process changes that led to me hating my time there and, ultimately, leaving.

I was skeptical of story points, but that's not what worried me. I was more concerned that an argument could be won about an adaptive methodology by appealing to what everyone else was doing. I expected a deeper analysis of how it would help our situation.

But this isn't an essay about story points. (Hint: don't use them.) No, this is about a slippery slope that can occur when trying to relieve a bottleneck that can make the bottleneck worse.

Programmers are expensive, so it would make sense to maximize their time by giving them tasks only they can do and outsourcing the rest to cheaper labor. The company had a team of eight programmers, which was its most significant expense. You can understand the pressure they were under to use that resource to the maximum.

Of course, the programmers were the bottleneck on the product. We programmed all the features. What work were we doing that others could do instead?

The slippery slope began slowly but surely. The product owners started writing more detailed tickets. They put more thought into the tasks so we wouldn't have to ask them as many questions later. Then, the level of detail got so fine-grained that they were basically doing the design work, solving problems ahead of time. The tickets dictated the structure of every API message, the name of the database table to fetch things from, what microservice the change needed to go in, and what order to do the tickets in.

Eventually, they wrote the tickets so that 1) they were broken down small enough to get a small number of points and 2) they could be done by any programmer at random. The product owners weren't the bottleneck, so they had ample time to do all this preparatory work.

It reminds me a lot of the old distinction between programmer and coder. The programmer would draw flowcharts (all the design work) and pass them to the coder, who typed in the machine code (grunt work). It also reminds me of a river that flows down a series of cliffs, where the water has to fall at each stage. Shit flows downstream. I felt like a code monkey swimming in it.

Though they relieved us of some work, it gave us more to do. Each ticket contained so much detail that it was hard to separate signal from noise. Since different programmers could do the tickets, we wondered if someone else relied on the assumptions written into the ticket we were working on.

I remember the day I started planning my exit. The product owner, hoping we would go faster, asked us to review each ticket to see if it could be put off or if there was a better way to accomplish the same thing.

But it was too late. We had lost any sense of the big picture. We had no context beyond the single ticket, rich in detail as it was. We had no idea why we were doing what we were doing. We just hoped someone did. But the product owner's request clarified that nobody knew.

What is a programmer's job? Is it to type in code by converting an English description into Clojure and then debug it until it works? No. The real job of a programmer is to design how the software works. No matter how hard you try, you can't separate design decisions from programming. And the harder you try, the more work it takes for the programmer to decipher the signal from the noise. That's why the agile movement campaigned against handoffs. The company would toss around the term agile, but they couldn't see a waterfall when they stared at it.

They got the bottleneck wrong. The bottleneck is the amount of time the programmer has the context of the problem in their head. The company should have invited the eight programmers to the design meetings sooner, not later, counterintuitively giving us more work. That's when we could have made a difference by finding alternative solutions and tasks that weren't valuable. And it would have given us a head start on typing in the code. But because we were so expensive and the deadlines so tight, the managers couldn't resist. They made our jobs harder by introducing a handoff.

The most underrated book in software engineering management