⏱ 9 min ▸ 8 tags

Good developers learn to program. Most courses teach a language.

A few years back I was looking over a junior's pull request in a language I had never written professionally. I could not have told you the standard library off the top of my head. I had to look up the syntax for a lambda. And I knew, without running the code, that the function was wrong.

It was five lines that should have been one. The shape was wrong. The data went out, came back, got reshaped, came back again, and finally landed where it had started, lightly bruised. The variable names were fine. The syntax was fine. The function did what it claimed to do. It was still wrong, because the thing it was doing was not the thing that should have been done at that point in the program.

I could see that because I have been programming for a long time. The junior could not see it because they had been taught a language. Those are not the same skill, and the gap between them is the part of this job that almost nobody is teaching at the entry level.

Language is not the bottleneck

Almost every introductory course, video, and bootcamp on the market teaches the syntax of a particular language and calls that programming. It isn't. Programming is the part that is the same across languages: how a system goes together, where the seams are, what data flows where, which decisions are cheap to change next month and which decisions you are going to be stuck with for the life of the codebase.

I have written about the deeper version of this argument elsewhere. The book chapter on the decline of foundational understanding in modern programming education lays out what is actually being lost: mechanical empathy, an honest mental model of the machine underneath, the historical context that explains why systems are shaped the way they are. That essay is the structural argument. This post is the field guide that comes after it. If you have read the chapter and asked, "fine, so what should a learner do about it," this is that answer.

What I think happened in 1997

Sometime around the second year of the cmcweb era, I was working on a Visual Basic 6 line-of-business app for a client whose name I have honourably forgotten. I had a junior with me. He had already been on three projects with me, knew the VB syntax cold, and could write a For Each loop in his sleep. The code he produced was correct. It was also flat. Every form was a giant procedure that ran top to bottom and dispatched to other giant procedures. The language is event-driven; he was writing it like a 1970s mainframe batch program with extra steps.

One Tuesday in March, something clicked. I do not know what it was. He wrote a small bit of glue between two forms that used the events the way the runtime intended them to be used. The next thing he wrote was better. The thing after that was better still. By the end of the month his code had a different texture. It looked like VB instead of Pascal-with-a-window-attached.

Nothing about the language had changed. He had been writing VB6 for two years before that Tuesday. What had changed was that he had started understanding what kind of system he was inside. He had stopped translating his ideas into VB and started thinking in events directly. The same syntax, the same standard library, the same IDE. A different developer.

That is the part that does not fit in a six-week curriculum. You cannot put it on a slide. You cannot dispense it in a YouTube short. It happens or it does not, in its own time, usually after the learner has shipped enough code to be embarrassed by some of it.

What "learning a language" actually covers

Syntax. The standard library. Idiomatic style. The type system. The build tool. How the package manager works on a good day, and what to do when it does not. Useful things, all of them. Necessary, even. But a developer who has only this is a translator. They can take an instruction in human language and convert it into machine-readable text. They can convert it into different machine-readable texts in three or four target languages, given a reference. The translation is correct. Whether the instruction was the right instruction in the first place is somebody else's problem.

A programmer is the person who decides what the instruction should have been.

What "learning to program" covers

Most of what a senior developer actually does on a given day is not in any beginner curriculum. It is the unsexy stuff. Reading code, mostly. Tracing data through five layers of someone else's design choices. Forming a hypothesis about why the bug is happening, then testing the hypothesis, then narrowing. Recognising that the function in front of you is too big and asking what part of it has its own reason to exist. Recognising that the schema in front of you encodes a decision someone made in 2019 and that the decision is now load-bearing for things they did not anticipate. Knowing which of the five tempting cleanups in the file is going to bite you in production and which is safe.

None of that is in the language. It is in the head of the person typing. The language is the keyboard.

The honest list of what good developers actually have, that the bootcamp version of them lacks:

• A mental model for how a system decomposes. Why this thing wants to be a class and that thing wants to be a function and that other thing wants to be a separate process entirely
• A sense for where data lives, where it moves, and where it is transformed. Most bugs that look like logic bugs are data-flow bugs in disguise
• A feel for which decisions are cheap to change later and which decisions are not. The skill is recognising the second kind in advance, before you have built three months of code on top of one
• The habit of reading code before writing it. A senior developer reads ten times more code than they write, most of it written by other people, much of it written by past versions of themselves who are no longer reachable for comment
• Debugging as a discipline rather than an indignity. Print-statement debugging is a method, not a confession of inadequacy. Step-debuggers, profilers, network captures, log diving, all of it
• A working tolerance for ambiguity. The first version of any non-trivial piece of code is built before anyone, including the author, fully understands what it should do. That is normal. That is the job

The AI multiplier

I use Claude Code every day. I wrote a post about it two days ago. The tool is excellent. It is also, for a learner without judgement, a faster path to a worse codebase than they would have produced unaided.

This is not a complaint about AI. It is the same point I have been making for thirty years, with a new amplifier in front of it. The model writes plausible code. If the prompter cannot tell plausible code from correct code, plausible code ships. If the prompter can tell, the model is a force multiplier on a senior who already knew where the seams should go and now has a fast way to type the seams in.

The bottleneck has never been "how fast can you write the code." It has always been "do you know what code should be written, in what order, with which contracts between parts." The model does not change that. It changes the cost of producing the lines and leaves the cost of deciding the lines exactly where it always was.

A junior who learns programming as "describe what you want to a model and accept what comes back" is learning to be a translator at one further remove from the machine. They are not getting closer to programming. They are getting further from it, with prettier intermediate output.

What a learner should do instead

If you are early in this and you have read this far, here is the short version of what I would tell my twenty-five-year-old self.

Pick one language and go deep. The kind of deep where you have shipped a non-trivial thing in it, maintained it for a year, and fixed bugs in it that were caused by past-you being wrong about how the runtime worked. Tutorial-deep does not count. Then pick a second language that is structurally different from the first. C# and Python is a useful pair. C and JavaScript is a sharper one. The contrast is the point. What you are looking for is the part that is the same across both, because that is the part that is actually programming.

Read code. Real code, in a real codebase, including the ugly bits. Open source is full of it. Read the issues and the pull request discussions, not just the merged code. The interesting argument is rarely in the diff.

Build something end to end. A real thing, with a real user, even if the user is you. Anything other than another todo-list tutorial. Ship it. Then maintain it for at least a year. Notice what hurts. The list of what hurts is the curriculum that nobody else can write for you.

Find a senior developer who will let you watch them work. Pair-programming with someone fifteen years ahead of you is the highest-bandwidth learning available in this field, and almost nobody is putting it on YouTube because nobody is paying them to. Ask. Most seniors I know will say yes if you are not annoying about it.

Read the books that are not language-specific. The Pragmatic Programmer, Code Complete, A Philosophy of Software Design, Kernighan and Pike's The Practice of Programming. These age the way good books age. The fashionable book on the framework you are using right now will not.

When you do watch language tutorials, watch the ones aimed at experienced developers learning a new language. The signal-to-syntax ratio is much higher, because the writer is not stopping every two minutes to explain what a variable is.

Be suspicious of any course that promises you can be a developer in twelve weeks. You can be a junior employee whose first useful contribution is six months out, sure. That is a different claim, and it is not the claim being marketed.

The question to ask

The field does not need more people who can write a for loop in seven languages. It needs more people who can look at a blank editor and decide what should be built, in what order, with which seams. That part takes a decade. Almost nobody is teaching it at the entry level, because almost nobody can teach it on a fixed-length curriculum to a room of strangers.

If you are a learner, the question is not "which language should I learn first." It is "which teacher will show me how a system goes together." The first question has cheap answers everywhere. The second is rare and worth the time it takes to find.

For the deeper version of why this gap exists in the first place, and what foundational understanding actually means at the level of memory, abstraction, and computational reasoning, the chapter on the decline of foundational understanding in modern programming education is where I make that argument in full.

This post was the field guide. That is the textbook.

-EG