Try First or Read First Is a Decision, Not a Temperament

You open a subsystem you have not worked in before. Within a couple of seconds, without noticing a decision was made, you do one of two things. You go and read — the documentation, the header, somebody’s article, an assistant’s summary. Or you go and try — write something, build it, see what the target does.

Almost nobody examines that moment. It gets filed under temperament: some engineers are readers, some are tinkerers, and there is a long-running argument about it that neither side has ever settled.

It is not a temperament. It is a choice you make several times a week, and making it the same way every time is the reason some subjects stay difficult for years.

The tool you reach for is not the variable. Where it sits in the sequence is.

What the idea actually says

There is a way of picking up something new that runs deliberately backwards. Instead of reading the explanation and then trying it, you take a problem you have no idea how to solve and work at it first. You will not get there — you do not have the answer yet, which is the point. What you come away with is three or four attempts, all wrong in different ways. Only then do you go and read, and the reading is different, because now it is answering a question you have.

It has a name, productive failure, and the name misleads a little, because this is not floundering. The problem has to be one you can make real progress on. The time has to be bounded, or you are just stuck. And the explanation has to actually arrive at the end rather than never. The failure is scheduled.

Set against reading the explanation first, the people who worked at the problem first came out ahead on understanding the concept, and further ahead again on carrying it to problems they had not seen before.

And here is the part almost every retelling drops. On the procedural questions — can you actually carry out the operation — attempting first showed no reliable advantage. That limit comes from the people who built the method rather than from its critics, and their own advice is to spend it on a handful of ideas that matter, not on everything you meet.

Worth knowing where it comes from before leaning on it. The work is school and university concept learning, not production engineering. Treat it as a principle for designing how you learn something, not as a claim that every problem at work should begin with unguided trial and error.

That split is the whole of the useful finding. It is not that struggle is good. It is that struggle produces one specific thing.

Attempting first will not make you quicker at the procedure. It makes you better at knowing what the procedure is for.

Ask what a wrong attempt would look like

There is a second limit, and on a kernel it matters more than the first.

Most of the time a wrong attempt looks like a partial answer. You get some of it, you get stuck, and the place you got stuck is the useful part — an accurate record of what you did not know, produced by you, which is exactly why the explanation is worth something when it arrives.

Some material does not fail that way. You attempt it and you produce something that builds, runs and passes. It is wrong, and nothing in your setup will report it.

The question is not how hard the material is. It is whether you will find out that your attempt was wrong.

Anything that turns on ordering, cache coherency or object lifetime sits in that second category. Reason your way to a lock-free queue on the x86 box you develop on and it will pass there and corrupt data on the arm64 target it ships to. That is not a difficult problem you failed at. It is a wrong answer that your machine did not reject, and that is the damage.

Worth knowing that this is partly your own doing. The debug options exist and they would have reported it, and most of us build without them and then treat a clean run as evidence.

Now the other side. Your driver needs a GPIO that has not been registered yet when it probes, and you have to decide what to do about it. That is worth twenty minutes of your own thinking, because everything you try is visibly wrong: retry in a loop and you burn a CPU, sleep and hope and you have a race, give up and the device never comes back. When you eventually read how the kernel handles it, you will be reading an answer to a question you have already asked, which is a different experience from reading it before you had the question.

Attempt the problems where being wrong is obvious. Read first where being wrong looks exactly like being right.

And there is a third category worth naming, because engineers lose real time to it. The spelling of a Kconfig keyword, the exact name of a devicetree property, the argument order of a helper — somebody chose these. There is nothing to derive and no version of struggling with them that improves you. Look them up, every time, without guilt.

Why this matters more now, not less

An assistant is instruction: available instantly, at maximum help, at whatever moment you ask. Everything above is about which moment that should be, which makes this an old question about learning in a new form.

The most useful thing measured so far is what happens after the tool goes away. Around a thousand people were given an ordinary assistant, or one built to question rather than answer, or nothing. While the tool was in front of them, both assisted groups did far better than the group without one. Then it was taken away and they worked alone, and the ones who had used the ordinary assistant did worse than the people who had never had one at all.

The guarded version removed that penalty. It is worth being exact about the size of that, because it is routinely oversold: it brought them level with the people who had worked unaided throughout. It prevented a loss. It did not produce a gain.

That was a classroom, on a school subject, with one group of people. It is not a verdict on every assistant, every task or every engineer. But the limit it suggests is lower than what these tools are sold on, and it is still the only place anyone has looked at what is left once the tool is gone.

A tool can get you to an answer faster. It cannot do the forming, testing and revising that leaves you with a model, because that work only counts when you are the one doing it.

Your own workflow already contains the right order, if you look. git bisect has it built in: you form a view about which change broke things, the tool tells you which commit it actually was, and it is usually not the one you expected. You attempted, you were wrong, and being wrong is what taught you.

The rule

• Ask what a wrong attempt would look like. If it would be visibly wrong — the device never binds, the box locks up the first time the interrupt fires, the design collapses while you are sketching it — attempt first. If it would look exactly like a right one on the hardware in front of you, read first.
• Attempt design problems, not conventions. How to handle a dependency that is not ready yet is a design problem, and worth your fifteen minutes. The spelling of a property is a convention somebody chose. There is nothing in it to derive.
• Judge the attempt by what it produced, not whether it worked. Three wrong approaches is worth more than one correct one you were handed. The wrong approaches are the model being built, and they are what makes the real answer clear when you finally read it.
• Distrust an attempt your setup cannot fail. If you are reasoning about ordering, coherency or lifetime on a machine that will not fail on any of the three, a clean run is not evidence. Turn the debug options on, get it onto the target, or read first.
• Expect guardrails to prevent harm, not create gains. Asking an assistant to question you instead of answering you is worth doing, and it is not a substitute for the fifteen minutes.

It is why our sessions put the problem in front of people before the explanation, and not the other way round.

Go back to the two seconds. You will make that decision again this afternoon, without noticing, and it will decide whether the next hour leaves you with a model of the problem or with a working configuration you cannot defend.

The decision itself takes about five seconds to get right. Ask what would happen if you got it wrong, and whether anything in the room would tell you.

Attempt the things that will tell you when you are wrong. Read the things that will not. Everything else about this argument is temperament.

You will get this wrong sometimes, and it is worth knowing which way to be wrong. Read first when you could have attempted, and you lose an hour and some of what the attempt would have taught you. Attempt first when you should have read, and you produce something that works, ships, and is incorrect, and you may not find out for a year. Those two mistakes are not the same size. When you cannot tell which case you are in, read.

— Raghu Bharadwaj