The fifth time code got cheap

This has happened four times before

The claim that writing code has become cheap is true. It is also the fifth time it has been true, and the previous four are worth knowing, because each one came with the same prediction and the prediction was wrong in the same way.

Assemblers, late 1940s and 1950s. Before them you wrote numeric opcodes. An assembler let you write ADD instead of an octal number and let the machine keep track of addresses. This was a genuine order-of-magnitude change in typing and errors. It was also resisted, on the grounds that real programmers knew the addresses.

FORTRAN, 1957. John Backus’s team at IBM spent about three years on the first compiler, and the pitch was explicit: programs would be written by the people who had the problem, not by programming specialists. The compiler produced code within striking distance of hand-written assembly, which was the technical achievement nobody expected. The social prediction (that programming as an occupation would shrink) did not happen.

COBOL, 1959. Designed so that the statements read like English and a manager could check them. SUBTRACT DISCOUNT FROM GROSS-PAY GIVING NET-PAY. Managers did not, in the event, read the programs. COBOL instead created a profession that is still being paid, more than sixty-five years later, to maintain systems written in it.

Fourth-generation languages and CASE tools, 1980s. Report generators, screen painters, diagram-to-code translators, and a promise summed up by the title of James Martin’s 1982 book, Application Development Without Programmers. This wave mostly failed, and it failed on a specific rock: the tools removed the typing and left the deciding, and the deciding was the expensive part.

Frameworks, package managers and public Q&A, 2000s onward. Rails claimed a blog in fifteen minutes and roughly delivered it. npm made installing more attractive than writing. Stack Overflow made the answer to the awkward question a search away. This was an enormous change, and it did what the earlier waves did: it changed the job rather than removing it. A large part of modern engineering is integrating and debugging other people’s code, and that is what this wave produced.

Brooks’s distinction is still the one that works

In 1986 Fred Brooks wrote No Silver Bullet, and its central split explains all five waves. He separated accidental complexity (the difficulty of expressing your intent in the available medium) from essential complexity: the difficulty of the thing itself: working out what should happen, in every case, consistently, for people who disagree with each other.

Every wave above attacked accidental complexity. None touched the essential kind. Brooks’s specific prediction was that no single development would within a decade give even one order-of-magnitude improvement in productivity, in reliability or in simplicity, and for the four decades since he has been broadly right.

Whether he is right about this wave is contested and you should treat it as open. The honest statement is that the current wave attacks accidental complexity harder and more broadly than any previous one, and that if it turns out to reduce essential complexity as well, it will be the first thing that ever has.

Three things that are different

Be fair to the present. Three differences are structural, not marketing.

1. There is no new notation to learn. Every previous wave asked you to adopt a language. This one accepts the description you would give a colleague. That removes a barrier that kept the earlier waves inside the profession.
2. It covers the long tail. A framework helps when your problem matches its shape. Outside that shape it is worse than nothing. A model will attempt anything, which is why it reaches work no framework ever did.
3. It fails differently. A compiler that could not do something said so, precisely, with a line number. This wave produces a confident, well-formatted answer whether or not it is right.

The third difference is not a detail. It is the reason the rest of this course exists, because it breaks the review habits that four decades of the previous waves taught everybody.

What to take from the history

The prediction programmers will not be needed has now been made and falsified five times. That is not proof it is wrong a sixth time (an argument from history is weak evidence about a new mechanism) but it does mean the burden of proof sits with the person making it.

The more useful pattern is this: each wave removed a layer of work, demand expanded to fill the new capacity, and the job moved up a level of abstraction. The people who had a bad decade were not the ones displaced by the tool. They were the ones who defined their skill as the layer that got automated. Assembly programmers who learned FORTRAN were fine. Assembly programmers who insisted that compilers produced sloppy code were fine for about eight years.

That is the risk worth planning around, and it is a career question rather than an existential one.