Einstein was once asked how many feet are in a mile.

He said, “I don’t know. Why should I fill my head with facts I can look up in two minutes?”

I don’t know if that story’s 100% true, but I hope it is.

Because the point stands either way.

We’ve spent years treating memorization like a badge of honor.

As if knowing the exact syntax of a nested loop in Go makes you a better programmer.

It doesn’t.

The people who build good software — the kind that’s a joy to use and a joy to maintain — aren’t just code typists. They’re thinkers. Architects. People who can hold the bigger picture in their heads. And guess what? They’re the ones who look things up.

They don’t waste time recalling the method signature for some obscure framework call. They focus on the real work: what’s worth building, how it fits together, what should happen when things fail.

And now that we all have AI copilots, the tradeoff has shifted even more.

There’s even less value in stuffing your brain with boilerplate syntax.

Your edge isn’t in remembering what the fetch() call looks like — it’s in knowing why you’re calling it, and what should happen next.

The difference between “coding” and “programming” is becoming clearer by the day.

Coding is typing. Programming is thinking.

And thinking is what still belongs to you.

LLMs can help you code.

They can fill in blanks, fix your typos, even scaffold whole files.

But they’re not going to tell you what’s worth building.

They won’t question the premise.

They won’t push back on a bad idea, or notice that you’ve overengineered something simple.

That’s your job.

So if you’re feeling guilty because you keep having to look up the syntax for a reduce function, don’t. You’re in good company.

Einstein didn’t know how many feet are in a mile.

You don’t need to memorize the syntax.

You just need to know what matters.

PS: This blog was published via email using Simple Butler Service.