Do You Still Read Books?

A developer asked me that on a call in June. Not sarcastically. He asked it the way you would ask someone who still develops film.

I had mentioned I picked up the second edition of Designing Data-Intensive Applications. Kleppmann and Riccomini shipped it this spring, nine years after the first one. Six hundred and fifty pages. His question was fair. Why sit with that for three weeks when a model summarizes the whole thing in four seconds and then answers follow up questions inside your own codebase?

Because the summary was never the point.

I keep coming back to this, because it is the same question sitting underneath every argument about learning to code in the AI era. Do the exercises still matter. Does typing it out yourself still matter. Or is all of that just ritual we defend because we suffered through it and want the next people to suffer too.

The exercises were never about the answers

Nobody ever learned anything from the answer to an exercise. The answer is worthless. You always knew the answer existed somewhere.

What you did not have, before you sat down, was twenty minutes of being stuck.

The stuck part is the product. Everything else is packaging.

There is hard evidence for this now and it is not comfortable. Bastani and colleagues ran a controlled experiment with roughly a thousand high school students in Turkey. Three groups. One worked with a plain GPT-4 chat interface. One worked with a tutor version built with guardrails that refused to hand over answers. One worked with nothing but books and notes.

During practice, the plain chat group scored 48 percent higher than the control group. The tutor group scored 127 percent higher. Then the researchers took the AI away and ran an exam.

The plain chat group scored 17 percent worse than the students who never had access at all.

The tutor group landed exactly where the control group landed. Not better. Not worse. All that assisted brilliance during practice converted to nothing you could carry out of the room. The work was published in PNAS in 2025 and the title is not subtle. Generative AI without guardrails can harm learning.

Then there is the MIT Media Lab study. Fifty four people, EEG caps, essay writing across four months. The group writing with ChatGPT showed the weakest neural connectivity of the three conditions. They reported the lowest sense of ownership over their own work. Many of them could not quote a sentence they had submitted minutes earlier.

The researchers called it cognitive debt. That is a generous name for it.

And then the finding I cannot stop thinking about. Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers about 936 real tasks. The more confidence people had in the AI, the less critical thinking they did. The more confidence people had in their own ability, the more.

Your own competence is what keeps you skeptical. Which means the loop closes on itself. Skip the hard part, lose the competence, lose the skepticism, and then stop noticing that you skipped the hard part.

So is there still a purpose in learning to write code

Yes. For a different reason than the one you were given.

You do not learn to write code so you can write code. You learn to write code so you can read it. Reading is the job now. For a lot of senior people I know it has quietly become the entire job.

Veracode tested more than a hundred models across eighty coding tasks. Forty five percent of the generated code introduced an OWASP Top 10 vulnerability. Java was worst at 72 percent. Larger models did not fix it. That is not a defect waiting for a patch. That is what you get when you train on the public internet.

Someone has to catch that. The someone is you.

You cannot review what you cannot read. You cannot smell a bad abstraction you have never built by hand. You cannot look at a query and feel the table scan coming if you have never watched a plan flip under load. That feeling is not knowledge you retrieve. It is knowledge you sedimented.

Stack Overflow’s 2025 survey says 44 percent of developers now learn to code using AI tools, up from 37 percent the year before. Documentation still leads at 68 percent. Books do not make the headline at all.

I am not going to pretend that is a tragedy. Most programming books were bad. Most were syntax manuals with a print run, and syntax manuals deserved to die. Nobody should memorize an API in 2026.

But the good books were never syntax manuals. That is the confusion at the center of this.

The shelf

Here is what I would actually put in front of someone, and I am being deliberately short about it.

For architecture, the second edition of Designing Data-Intensive Applications, because it explains why systems fail rather than which library to install. Next to it, Fundamentals of Software Architecture by Richards and Ford, which also got a second edition in 2025, and A Philosophy of Software Design by Ousterhout, which is short enough that there is no excuse. If you run anything in production, Release It! by Nygard is the book that saves you at 3am. Bulkheads, timeouts, circuit breakers. Written before anyone called it resilience engineering.

For the craft of the code itself, The Pragmatic Programmer, Fowler’s Refactoring, and Working Effectively with Legacy Code by Feathers. That last one is more relevant now, not less, because AI produces legacy code faster than any team in history. Kent Beck’s Tidy First? takes ninety minutes and changes how you open a pull request.

For infrastructure and operations, the Google SRE book and the SRE Workbook, both free on the web. Accelerate by Forsgren, Humble and Kim for the measurement side. Team Topologies for the shape of the organization, which becomes the shape of your system whether you agree with that or not.

For security, Ross Anderson’s Security Engineering. Chapters are free on his Cambridge page and it is still the most honest book about the fact that most breaches are not clever. Google’s Building Secure and Reliable Systems is also free, and it is the only book I know that treats security and reliability as one discipline instead of two departments.

For performance and scaling, Brendan Gregg’s Systems Performance. It is dense, you will not read it front to back, and that is fine. Read the methodology chapters, then use the rest when something is burning. Alex Petrov’s Database Internals for storage. Roberto Vitillo’s Understanding Distributed Systems if DDIA feels too heavy for a first pass.

That is the shelf. Not fifty books. Twelve or so, spread across three years.

Can you learn infra, security and scaling without going deep into code

Partly. And the part you can learn without code has a ceiling that arrives sooner than people expect.

You can become genuinely useful in devops without writing application code. Plenty of excellent platform engineers came out of operations. Learn Terraform, Kubernetes, pipelines, alerting, cost control, and you can be very good at all of it. Learn the OWASP Top 10, run the scanners, file the tickets.

Then an incident happens.

The service is timing out. The dashboard says the database is healthy. Pods are fine. CPU is flat. At that moment the only person who helps is the one who can open the code, find the connection pool configuration, work out why the pool is exhausted while the database sits idle, and notice that the retry logic three layers up is making everything worse.

That person is not reading Terraform. They are reading code.

Infrastructure, security, scaling, performance. Every one of those is the same question asked from a different angle. What happens when code meets reality. You cannot answer it from outside the code.

Here is the part that genuinely got easier. Going deep into code no longer means writing all of it. It means reading it, tracing it, instrumenting it, breaking it on purpose in staging and watching what falls over. Ask the model to explain a subsystem, then verify the explanation against the source. Ask it for three implementations of the same thing and force yourself to argue why one wins.

Use the model as the tutor arm of that experiment. Not the answer arm. The gap between those two groups was 17 percent of everything.

What I actually do

I read the book slowly. I keep a file of things I disagreed with. I run the examples, then run them wrong on purpose, because the failure mode teaches more than the happy path ever did.

Then I use AI constantly. Every day. Scaffolding, review, the fifth alternative I would not have reached on my own, the shell incantation I refuse to memorize.

Those two things are not in tension. They are the same practice separated by a few years of compounding.

The book is slow.

That is the feature.

Final Words.

If you think I am romanticizing paper, tell me. I would rather be argued with than agreed with, and the people who disagree with me on this usually have the more interesting version of the argument. Maybe your experience is that the books were always overrated and the only real teacher was production. That is a defensible position and I have seen it work for people.

I write about this every week. You can follow along on LinkedIn (linkedin.com/in/ivanturkovic), on X (x.com/ithora), or on Threads (threads.com/@ithora), and I answer most replies.

If you want to talk about something specific rather than in public, the contact page is at ivanturkovic.com/contact.

And if you are hiring, or you need a fractional CTO who can tell you where AI helps your engineering team and where it quietly hurts it, book thirty minutes at cal.eu/ivan-turkovic/30min.

So what is the last technical book you actually finished, and did it change how you write code or just how you talk about it?