Programming books don't teach programming

I saw a Twitter thread yesterday. Someone posted their stack of O’Reilly books, ‘Learning Python’, ‘Kubernetes: Up and Running’, ‘Designing Data-Intensive Applications’. Hundreds of comments congratulating them.

Nobody asked if they’d actually written any Python. Nobody asked if they’d deployed a pod. Just applause for buying books.

You can’t read your way to competence

Programming books sit on shelves. Code runs in production.

I’ve interviewed dozens of engineers who ‘read the Kubernetes book’. When I ask them to write a deployment, they freeze. They know the theory. They can’t write YAML.

You don’t learn programming by reading about it. You learn by breaking things, fixing them, and understanding why they broke.

The performance everyone performs

Posting your book collection is tech’s version of ‘I’m working on myself’. It looks productive. It signals expertise. But signal isn’t skill.

Real learning looks different:

• Half-finished projects in your GitHub
• Error messages you’ve memorized
• That one production incident you still think about
• Stack Overflow questions you’ve actually answered

Books don’t give you that. Breaking and fixing systems does.

Books teach the wrong things

Most programming books cover fundamentals that ChatGPT explains better in 10 seconds. The rest is theory you’ll never use.

What you need:

• How authentication actually works in your stack
• Why your container runs out of memory
• How to debug that networking issue

What books give you:

• Design patterns from 1995
• Toy examples that compile but solve nothing
• Comprehensive coverage of features you’ll never touch

Books optimize for completeness. Real projects need depth in narrow areas.

Practice beats passive consumption

Reading is passive. You think you understand until you try to implement it.

I thought I knew Docker after reading the docs. Then I spent a week debugging why my image was 2GB. The book mentioned multi-stage builds. It didn’t explain when your cache breaks or why layer order matters.

I learned Docker by:

• Building 50 broken images
• Reading error messages
• Checking what other projects actually did
• Fixing what broke in CI

Not by reading 400 pages about container theory.

Some books work

Reference docs work. ‘Here’s the API, here are examples’ works. That’s a tool, not a textbook.

Deep technical books work when you already know the basics. You can’t appreciate ‘Designing Data-Intensive Applications’ until you’ve built a few data-intensive applications.

Architecture books work if you’ve felt the pain they solve. Otherwise, it’s just patterns you cargo-cult into your code.

What actually works

Build something. Pick a project. Make it work. Make it better. Deploy it. Break it. Fix it.

Read code. Not books about code. Actual production code. See what patterns real engineers use. See what they avoid.

Watch people work. YouTube has thousands of hours of engineers building real systems. Watch them debug. Watch them refactor. See their thought process.

Fix real problems. Contributing to open source teaches more than any book. You deal with real constraints, real reviews, real users.

The book collector problem

I know engineers with shelves full of programming books. None of them are senior engineers.

The senior engineers I know:

• Have 3-4 reference books they’ve actually used
• Follow documentation, not textbooks
• Learn by building and breaking
• Read source code when confused

Books are comfort food. They make you feel like you’re learning. But learning happens in the terminal, not on the shelf.

Start now

Close this article. Open your editor. Pick something you don’t know. Build it badly. Make it work. Break it on purpose. Fix it.

That’s how you learn.

Books are for looking smart on Twitter. Code is for getting things done.