All essays
Software Teams··2 min·Series: Software Teams

The kids are alright

I’m not that worried that junior programmers won’t learn the same way we did.

The kids are alright

I’m not that worried that junior programmers won’t learn the same way we did.

I learned PHP, which some "real" programmers treated as barely programming, just scripting.

My first startup was built on Drupal, and I still remember someone taking a little dig at it by calling it an interesting use case for an off-the-shelf CMS.

Which, sure. But the thing worked.

AI feels like the same argument all over again.

Yes, kids today won’t learn to program like we did, but it's because they don’t need to in the same way. And that’s a good thing.

I don't know assembly, but I can still build big things. Most engineers don't write manual memory management every day, and somehow the technology continues to flourish

Every generation inherits abstractions that make the previous generation’s hard parts less central.

The responsibility doesn't go away. The layer changes.

That's the important distinction:

Some skills become optional. Some skills stay load-bearing. New hard parts show up. In tech, when you make something cheap, the constraint relocates.

Compilers made assembly less central. Garbage collection made manual memory management less central. Frameworks made a lot of plumbing less central. Each time, the work didn’t disappear but the frontier moved.

It assumes the old entry-level tasks disappear and nothing replaces them. But if the new junior work is writing better specs, testing outputs, evaluating behavior, understanding integration points, and taking responsibility for the result, then the pipeline doesn’t collapse, it moves.

The real skill may not be "can you personally type every line of source code?"

The real skill becomes:

Do you know what should happen?

Do you know why this matters?

Do you know how to inspect the system?

Do you know how to prove it works?

Do you know when the answer is nonsense?

Are you confident enough to take responsibility for it?

Today, when you're shipping code, you still need code literacy, you read the source, debug the output, own what the machine produced. That's true today. It's already less true than it sounds. More than half of the code I write never leaves my machine. It's built to complete a task, i.e. rename files, transform a CSV, generate a batch of images. The output is the artifact. I verify that and move on.

You don’t need to read Stripe’s source code to build on Stripe. You understand webhooks, idempotency, error states, billing flows, failure modes, and the user experience around all of that.

Source code is one inspection surface. It is not the whole job.

Future programmers may not need code literacy anywhere near the way we mean it today. They will need systems literacy: knowing what matters, how to inspect it, how to verify it, and how to be accountable for the outcome.

The old hard parts won’t disappear entirely. Syntax, boilerplate, and translating obvious intent into code will still matter sometimes.

They just won’t be as differentiating.

New hard parts will emerge.

And the kids will get really good at those.

Keep reading