Last November, for the first time in my life, I wrote two applications without writing a line of code myself. For more than thirty years before that, my fingers were on a keyboard, regardless of my title. Developer, dev manager, VP of Engineering, CTO, owner: I always wrote code, often to the chagrin of the developers who worked for me. Then Claude and I shipped two apps to the Google Play Store in fourteen hours of work, and I never touched the code.
There are people who would say I didn’t write them at all, that the work wasn’t mine.
Their position is simple. I described what I wanted, and an AI made it. Describing is what a customer does. The person who commissions a painting doesn’t sign it. If Claude wrote every line, then Claude wrote the apps, not me.
The Speech
If you’ve ever worked on one of my teams, you’ve heard some variation of this speech. It’s my new-hire speech. I’ve given it a hundred times, sometimes to a group and sometimes to one person. It goes something like this.
I walk around this planet feeling like a wizard, or the closest thing possible. People come to me with their problems. I think about the problem. I wrestle with it. I think about previous solutions. I think about what’s possible with current technologies. I construct a new machine in my head that solves the problem. Everything I have goes into it. Everything I’ve learned since I was six years old is raw material. And then I can feel the machine. I can feel the gears moving and how the parts fit together.
Then I put my fingers onto the keyboard and I express instructions for building the machine. I speak to a computer in a programming language the way I would speak to a person in English. I’m fluent in both. The keyboard is just a natural extension of me for a while, until the machine exists. And where there was nothing before, there is now something, something that other people can see and interact with and hold in their hands. I have conjured something into the world.
You are so lucky, I am so lucky, to have the best job in the whole world. Nothing is better. And I’ve had the good fortune to learn from some of the best practitioners in the world. I’m going to share those lessons with you.
What we strive to build, always, is a perfect machine. A perfect machine is a machine that you cannot add anything to or remove anything from to make it any better. That’s how you know you’ve made the perfect machine, and it’s a thing of beauty. A Rubik’s Cube is a perfect machine. You couldn’t add a button, a feature of any kind, to make it any better. You couldn’t remove any piece of it to make it better. It is a perfect machine.
We will not be measured by the number of lines of code we write. Our job is to build the perfect machine. Remember, our users don’t care at all about our code. It’s what our code delivers that they care about. And every line of code we write carries with it the possibility, the probability, no matter how slight, of a bug. So the fewer lines of code we write, the better. The best code is no code, as long as it still delivers something of value to our users.1 Your best days will have a negative line count.
The Line Count
For a long time, the software business tried to measure programmers the way a factory measures output: by counting. The unit was the line of code. A program is a text file, a programmer adds lines to it, and lines are easy to count. So managers counted them. More lines meant more work done. Projects were estimated by the thousand lines, and programmers were ranked by how many they produced.
The best-known story about this comes from Apple, in February 1982. Andy Hertzfeld, who worked alongside the people in it, wrote it down2.
The Lisa software team was in the big push to ship, and its managers wanted a way to see who was making progress. They settled on the obvious one. Every week, each engineer would fill out a form reporting how many lines of code they had written.
Bill Atkinson was the author of QuickDraw, the code that drew everything on the screen: every window, every menu, every letter. That week he had been working on the part of QuickDraw that keeps track of shapes on the screen, the machinery that knows which pieces of a window are showing when another window overlaps it. He rewrote it around a simpler, more general idea. The new version ran almost six times faster. It was also about two thousand lines shorter.
So when he reached the box on the form that asked how much code he had written that week, he put down −2000.
A couple of weeks later, the managers stopped asking Bill to fill out the form.
His best week had a negative line count.
The typing was never the work.
Make Me an App
I know what it looks like when typing is all there is, because that is how I started.
It’s bizarre that I learned to program at the age of six, in 1980, because the opportunity to do so was so rare. I was extremely fortunate. My dad taught at the colleges on Fort Leonard Wood. Where five colleges shared a building, he was the math department for two of them. When one got a computer lab of brand-new TRS-80s, I spent all of my time there, fascinated by the computers3. Some kind-hearted person gave me a programming book. But at six, all I cared about was flipping to the back and transcribing machine code from the book into the computer so I could play a game. I typed every character and understood none of it — at first.
It was the 1980 equivalent of typing “make me an app” into an AI and running whatever comes back. But it was the beginning of my journey. Over time, I started to learn what the symbols meant. I learned LD and JP and I started reading the other parts of the book to make the game mine.
So maybe we can give a little grace to the people who say “make me an app” because they’re just starting their own journeys.
The Language
In the new-hire speech I said that I express instructions for building the machine. Expressing takes a language, and the languages have been changing for as long as there have been computers.
A processor understands one thing, which is numbers. The first programmers wrote those numbers by hand. Here is a program that works out a week’s pay, forty hours at fifteen dollars an hour, the way the Zilog Z80, the processor inside that TRS-80, saw it:
06 28 11 0F 00 21 00 00 19 10 FDThat is very close to what I was typing into those computers at six4.
Then, in 1947, a mathematician in London named Kathleen Booth devised a way to write short words instead of numbers, with a program that turned the words into numbers for you. The program is called an assembler, and the words are assembly language5:
LD B, 40 ; forty hours
LD DE, 15 ; fifteen dollars an hour
LD HL, 0 ; the pay starts at zero
LOOP: ADD HL, DE ; add one hour's pay...
DJNZ LOOP ; ...and do it forty timesFrom the assembler on, almost nobody wrote the code a computer actually runs. A program wrote it for them. In 1957 came FORTRAN, which let you write something close to algebra6:
GROSS = HOURS * RATEFORTRAN came with a new kind of program called a compiler. A compiler is a translator. You write what you mean in a language made for people, and the compiler turns it into instructions like the ones above, the kind the processor needs. The programmer never has to see them.
Grace Hopper went further. She wanted programs written in English. “I was told very quickly that I couldn’t do this,” she said, “because computers didn’t understand English.” She did it anyway. Her work led to COBOL, in 19597:
MULTIPLY HOURS BY RATE GIVING GROSS-PAY.Python, the language most programmers learn first today, arrived in 19918. By then one line could total the payroll for the entire staff:
total = sum(worker.hours * worker.rate for worker in staff)Something else happened on the way up that ladder. Every one of these languages became somebody’s identity. There were assembly programmers and FORTRAN programmers and COBOL programmers, and we still do it: we hire “Python developers” and ask for five years of C#, as if fluency in a language were the same thing as programming.
That confusion is the whole reason I give the speech. The new hires in front of me had spent years getting good at C#, and many of them believed that was what made them programmers. It wasn’t. A good programmer picks up a new language in weeks. It takes years to learn what to say in it.
Speaking fluent English has never made anyone a novelist.
The confusion is still alive, and it is what sits underneath the objection I started with. If programming is fluency in Python, then whoever writes the Python is the programmer, and these days that is Claude.
I used to tell a room of new programmers that the language they knew was irrelevant, because every language expresses the same handful of patterns. What differs is the idiom, each language’s own way of saying them.
A pattern is a thing programmers do over and over, whatever language they are in. Here is one of the most common: go through a list, do something with each item, and keep a running total. Say the list is our staff, and the total is what the week’s payroll costs.
Here it is in BASIC, the language that was built into that TRS-80:
10 T = 0
20 FOR I = 1 TO N
30 T = T + H(I) * R(I)
40 NEXT IIn JavaScript:
let total = 0;
for (const worker of staff) {
total += worker.hours * worker.rate;
}And in Python, the line you have already seen:
total = sum(worker.hours * worker.rate for worker in staff)It is the same pattern three times, in three idioms. Anyone who can read one of these can learn to read the other two in an afternoon.
But look at what changes. In BASIC there is no such thing as a worker. The hours live in one list and the rates in another, and it is my job to remember which numbers belong to the same person. I also have to count. JavaScript knows what a worker is. I say for each worker, and the counting is gone. Python goes one further and drops the loop. I say what the total is: the sum of hours times rate, for every worker on staff.
Every language on that ladder is the same bargain. You describe the machine in your head in words a person can read, and another program writes the real code. Each language let the programmer say more, and each translator took over more of the writing.
Nobody says the compiler wrote Windows.
Claude is the next translator in that line, and English is the language:
Work out everyone's gross pay from their hours and their rate.
Flag anyone over sixty hours, because that is usually a timesheet mistake.English is the new programming language, no less of one than Python and much more expressive9. It is the one I prefer now. Andrej Karpathy said it in one line in 2023: “The hottest new programming language is English.”10 It sounded like a joke. It was the next step in the history above.
It is more expressive because for the first time I can say why. Read those two sentences again and you will find the old patterns in them. Everyone’s is the loop. Anyone over sixty is the choice. Only because is new. None of the languages above has a word for because. Python lets me tell a computer what to do. English lets me tell a computer why to do it.
It is also less forgiving than it looks. A compiler refuses a sentence it can’t understand. Claude will build from almost anything. Ask twice and you may get two different programs. Hand over a vague description and you get something back anyway, built confidently out of the most ordinary choices available. “Make me an app” is a valid program in this language. It is one line long, and you get what one line can specify. The exactness the old languages forced on you now has to come from you.
The Work
So what is the work, if it was never the typing and never the language? It is thinking about the problem and constructing the machine in your head, and most of it happens away from the keyboard. One of my most brilliant engineers used to tell me that he did most of his job when he was out taking a walk in the park. By the time he sat down, the hard part was over.
That was always the best part of the job. Thinking about a problem and coming up with the solution was the most fun I ever had at work. Getting the machine out of my head and onto the screen was translation. Now Claude does the translating, and I have something I never had at a keyboard: a collaborator.
I mean that word. A compiler does exactly what it is told. Claude asks questions, makes suggestions, and fills in details I never specified, the way a good engineer on my team would. That is the right way to think about it: Claude is an engineer I hire from Anthropic. Some of the thinking in those two apps is Claude’s, just as some of the thinking in everything I shipped as a CTO belonged to the engineers who worked for me. Every decision was still mine to make.
Painters worked this way for centuries. The person who commissions a painting doesn’t sign it, but the patron was never the right comparison. In 1618 Peter Paul Rubens described one of his canvases to a buyer as “made by my best disciple and entirely retouched by my hand.” He held that a picture he had designed, and retouched at the end, was his original, whoever’s brush had filled it in11.
I don’t start with instructions. I paint a picture. I tell Claude what I’m trying to build and, above all, why. One of those two apps, Vault, began with two things I would not give up: I can’t trust any app that isn’t open source, and I need some way of knowing that the app I’m running matches the source and hasn’t been tampered with. The other, Gems, began with my wife. I showed her Vault and she had no interest at all. She was busy playing a match-3 game. So I built one, to show off for her, the same way I did wheelies on my bicycle at eight for the kids across the street.
I connect what I’m describing to systems I’ve built before that had the same shape, and to mistakes I don’t want to make twice. I talk about my thinking far more than I talk about the code. And Claude talks back and asks questions. We go back and forth until we have a plan, and that takes five to fifteen minutes at the least, before a line of code is written. It is my engineer’s walk in the park, with company. Then we execute, I test what comes back, and we iterate. A lot. On those two apps I was the product manager and the QA, and the QA was about half the hours.
That conversation is the difference between a programmer and a customer, and I’ve drawn the line before. In The Asymmetry I called it the Director Test. A non-director walks into your office, describes what’s broken, and looks at you. The implicit request is: think about this for me. A director brings the problem, a proposed solution, the thinking that led to it, and a request for sign-off.
In that essay I called the hard part factoring: working a problem through yourself before you hand it to anyone else. I wrote that an expert who uses AI is doing more factoring, not less.
“Make me an app” is not what a programmer says. It is what a customer says, and what a beginner says before learning better, and it leaves all the factoring to the AI.
A programmer brings the outline, the requirements, and the connections to past work, then works with the AI to fill in the holes and make a plan. The programmer stays in the conversation until the machine exists.
And when it’s finished, my name goes on it. Those two apps are in the Play Store, and I am the one who put them there. If they break, they’re mine to answer for. In The Last Wide Rung I listed that as part of craft: the willingness to put your name on the outcome. That was always part of the work too.
The question of whose work it is has the same answer it had when I was six. That game wasn’t mine while I was copying it out of the book. It wasn’t mine when I cracked open the other chapters of the book and learned the language. It became mine the first time the game did something because I had decided it should, something the author of that book never wrote.
This essay took about seven hours to write, and that’s with the help of Claude.
“I have made this longer than usual because I have not had time to make it shorter.”
— Pascal, 165712
I am not the first to put it this way. The idea is common property among programmers, and its best-known statement is Jeff Atwood’s 2007 essay *The Best Code is No Code At All*.
Andy Hertzfeld, “-2000 Lines Of Code,” dated February 1982, at folklore.org. Hertzfeld’s account gives the details used here: the weekly form, the rewrite of QuickDraw’s region engine around “a simpler, more general algorithm,” the result running “almost six times faster,” and the roughly two thousand lines saved.
Radio Shack introduced the TRS-80 in August 1977. It was built around the Zilog Z80 processor and had BASIC in its ROM, which is why BASIC and Z80 assembly are the two languages I use for that machine later in this essay.
These eleven bytes are the five instructions in the listing that follows, translated by hand. The Z80 had no instruction for multiplying, so the program adds the hourly rate forty times. Load the bytes into a Z80 and run them, and the register called HL ends up holding 600, which is forty times fifteen.
Kathleen Booth, working at Birkbeck College on a machine called the ARC, is widely credited with the first assembly language and the first assembler. David Wheeler built a similar translator, the “initial orders,” for Cambridge’s EDSAC in 1949, and the IEEE has credited him with the invention, so the honor is disputed. Either way it was done by the end of the 1940s.
The first FORTRAN compiler was delivered in April 1957 for the IBM 704, by a team at IBM led by John Backus. The name is short for “formula translating system.”
Hopper’s English-language compiler was called FLOW-MATIC. COBOL’s design began in 1959 under a committee called CODASYL, was based in part on FLOW-MATIC, and had Hopper as a technical adviser. The line shown is valid COBOL.
Guido van Rossum published the first release, version 0.9.0, in February 1991.
The usual objections are that an English sentence has no fixed meaning, and that the same request can produce two different programs. I have three answers. (a) The variation is a setting and not a property of the language: fix the model and turn off the randomness and, in principle, the same sentence gives the same program every time. (b) Early FORTRAN had no formal definition either. Until it was standardized in 1966, the language meant whatever the compiler did with it, and nobody says it wasn’t a programming language. (c) No user has ever cared what the code looked like. They care about what it delivers.
Posted on January 24, 2023.
From Rubens’s 1618 correspondence with Sir Dudley Carleton, the English ambassador at The Hague, who was trading his collection of antiquities for paintings and wanted to know how much of each was by the master. “My best disciple” is generally taken to be Anthony van Dyck.
Blaise Pascal, Lettres Provinciales, 1657: Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. The line is often credited to Mark Twain, who according to Quote Investigator never used it.