Should You Still Learn to Code?

Let me address the elephant in the room.

It is large, it is grey, it is standing directly between you and chapter three, and it can write a working web application in about forty seconds. Everyone has noticed it. Pretending otherwise for twenty-five chapters would be silly, so let us deal with it now and get on with the book.

You are learning to program at the exact moment machines became rather good at programming. That is either terrible timing or the best possible timing, and which one depends entirely on what you think the job actually is.

To Code or Not to Code

Start by conceding the premise, because the honest version of this argument does not need to be defensive. Generated code is good and getting better. It writes boilerplate faster than you will. It remembers API details you would have looked up. It produces a working first draft of most things in seconds. Anyone telling you otherwise is protecting something.

So here is the actual question: what was ever the hard part?

It was not typing. Nobody’s data science project has ever failed because the team could not type quickly enough. Look at what this book spends its length on and you will notice that almost none of it is syntax.

flowchart TB
    subgraph GEN["What generation now does well"]
        direction TB
        G1["Boilerplate and setup"]
        G2["API details you would have looked up"]
        G3["A working first draft, in seconds"]
    end
    subgraph YOU["What still has to be yours"]
        direction TB
        Y1["Which question is worth asking"]
        Y2["Whether the data can answer it"]
        Y3["Whether the number means anything"]
        Y4["Answering for the decision afterwards"]
    end
    GEN -.->|"the transcription<br/>is solved"| YOU
    style GEN fill:#f0efe9,stroke:#5c6670
    style YOU fill:#eef1fc,stroke:#2141c8,stroke-width:2px

What Was Ever the Hard Part?

Three things follow from that split.

You cannot review what you cannot read. This matters more in data work than almost anywhere else, because the failures here are silent. A web page that breaks is obviously broken. A model trained on leaked data produces a beautiful validation score, a confident number, and a system that fails quietly in production three months later. A merge that duplicated rows gives you a revenue total that is eleven per cent too high and no error at all.

Ask a model for a training pipeline and you will get one. It will look professional. Whether it scaled the features before splitting the data, whether it used a random split on time-ordered rows, whether it computed group means using each row’s own target, are all questions somebody has to be able to answer by reading it. There is no error message for any of them.

Asking for the right thing requires the vocabulary. “Build me a churn model” is not a specification, and you will get back something plausible and generic. “Use group-aware cross-validation because rows repeat per customer, target-encode the high-cardinality columns out of fold, and report average precision rather than accuracy because the classes are imbalanced” is a specification. You can only write the second sentence if you already know that each of those things exists and why it matters.

The quality of what you get out is bounded by the quality of what you can ask for. That bound is your understanding, and it does not move because the typing got easier.

Somebody still has to build the thing. This one is worth stating plainly, because it is easy to forget that every clever system you use was assembled by people having exactly the arguments this book is about.

Ever wonder how Amazon decides which product to put in front of you, out of several hundred million? Or how Target and Walmart know to email you about garden furniture in the same week you started thinking about your garden? Or how Siri works out that “text my wife I’m running late” is one instruction and not four?

None of those arrived fully formed. Someone assembled the data, decided what the target actually was, worked out whether the training set resembled the world the system would meet, chose what counted as good, and decided when it was fit to ship. Someone also decided what to do when it was wrong, because all of them are, regularly.

That work is the subject of this book, and it is in more demand now than it was five years ago, not less. My own boss once floated the idea of replacing me with a very good autocomplete. He came round when it became clear that the valuable part of the job was never the typing, and that somebody still had to tell the autocomplete what a good answer looked like.

“Generation removed the transcription. It did not remove the judgement, and judgement was always the part that was scarce.” — Sameer Gupta

And in a World Where AI Does Everything?

Take the strongest version of the future. AI is embedded in everything, robots do the physical work, and daily life is easier than it has ever been.

For the record, my daughter is entirely in favour of this future, chiefly because she has calculated that it ends the argument about whose turn it is to load the dishwasher. I have not told her that someone has to program the robot. She will find out.

Because that is the point. You still use Python.

Not out of nostalgia. Because Python is what that world is made of and operated with. Every major model is trained through it. Every agent that does something useful calls tools written in it. Every pipeline that feeds a system its data is orchestrated in it. When a machine that acts in the world needs to be told what good looks like, someone specifies that, and they do it in this language.

There is a version of this future where most people never write code, and that is fine. There is no version where nobody does. The people who understand what is happening inside these systems, who can tell a real result from a flattering one, and who can be held to an answer when it matters, do not become less valuable as the systems spread. They become the small group everyone else depends on.

What changes is the shape of the skill. Less time producing code, more time reading it, specifying it, and judging it. That is a genuine shift and this book is written for it.

But you cannot judge work of a kind you have never done. Which is why the first thing to do is still to write some, badly, yourself.

What Carries Forward

Generation solved the transcription, not the judgement. Which question is worth asking, whether the data can answer it, and whether the number means anything are all still yours.

Data work fails silently. A leaked validation or a duplicating merge produces a confident number and no error, so somebody has to be able to read the code and catch it.

What you get out is bounded by what you can ask for, and that bound is your understanding.

Next, the technical argument: why a language this slow ended up dominating a field obsessed with speed. The answer explains almost everything about how the tools are shaped and how you are meant to use them.