Programmers Were the Compiler - Minid.net -->August 10, 2026<br>Programmers Were the Compiler

Senko Rašić is right that coding was genuinely hard, and wrong to conclude much from it. Historical difficulty tells you what was scarce when humans had to do the translating, not what stays scarce once machines can do it. The evidence from Anthropic, METR, DORA and Thoughtworks points the same way: implementation is getting cheap, and specification, verification and ownership are what is left to be expensive.

Toledo, 1903. Michael has blown glass for twenty-six years and can hold a gather at the exact temperature where it stops fighting him, which is something you learn with your forearms and not with your head. The new machine in the corner makes four bottles a second and not one of them is beautiful. He tells the foreman, correctly, that no machine will ever learn what his hands know. The foreman agrees with him completely and sincerely, and then asks whether the neck on the medicine bottles should be wide enough for a cork or narrow enough for a dropper, because the machine will have made two hundred thousand of them by Friday and nobody in the building knows the answer.

Senko Rašić published a piece on August 8 titled Code was never the hard part is an insult to all programmers, and I want to start by giving him everything, because the post deserves it. He is right that the slogan is historical revisionism. Programmers were paid well and fought over because the skill was scarce. SICP and The Art of Computer Programming are not casual reads. Carmack and Bellard exist, and the gap between them and a competent ordinary developer is not a rounding error. And after fifty years of methodology, tooling and process, software is still riddled with bugs, which is a strange fact to explain if the work was always trivial. He is also not the strawman that the AI crowd likes to argue with. He says outright that we are in the middle of an industry wide tectonic change, tells engineers to learn the business and the users rather than hiding behind the keyboard, and closes with a line I would happily nail above a door: don’t outsource your understanding, judgement, empathy and taste to AI, and don’t be a meat proxy. I agree with all of it.

The problem is the inference, not the history. Senko takes the evidence that coding was hard and treats it as evidence about where the scarce work will be, and those are two different questions wearing the same coat. High salaries and low unemployment tell you that the profession was valuable and hard to staff. They do not tell you which activity inside the profession was doing the work of being scarce, because nobody was ever paid separately for the four things a programmer did at once: understand the problem, build a mental model of it, translate that model into executable detail, and then debug the model and the translation together without always knowing which of the two was wrong. That bundle was genuinely difficult. Michael’s forearms were genuinely skilled. Neither fact survives as an argument about what happens after part of the bundle becomes machine work.

There is an older version of this exact confusion, and it is worth remembering because nobody defends it anymore. For most of the nineteenth century and a good part of the twentieth, computer was a job title held by a person. Teams of human calculators produced navigation tables, ballistics tables and astronomical ephemerides, and the work was specialized, exhausting, error prone and genuinely hard to learn. Then the machines arrived and the occupation stopped existing, and not one sane person concluded from that that calculation had never been difficult. What the machines demonstrated is the far more interesting thing: an activity can be cognitively expensive for a human and nearly free for a machine, and the price of the human version tells you nothing about which of those two worlds you are about to live in.

The library argument has the same shape. Senko asks why, if coding were easy, we would have produced The Art of Computer Programming, SICP, Clean Code and The Pragmatic Programmer, plus degrees and bootcamps and an entire publishing subgenre, and he is right that a trivial activity does not generate that much literature. But look at what those books were actually for. The knowledge had to be written down, read by a human, internalized over years, and then applied by hand on every project, forever, because the only route from a principle to a codebase went through somebody’s fingers. That last step is the expensive one, and that is the step being automated. The knowledge did not become worthless. The cost of applying it repeatedly did, which is a very different event and a much more disruptive one.

The weakest argument in the post is the one about status. Senko asks why, if figuring out what to build were the hard part, product managers, business analysts, UX researchers and customer success people were not the ones...