How do you stay productive when learning a new skill from zero?
Pick one thing you can ship, then work in public failure. Instead of studying the whole subject first, start the smallest real project and write down every point where it breaks — the symptom, what you did last, and what you were waiting on. The log becomes your curriculum, built from your own gaps.
I did not arrive at this by choice. After leaving a 26-year career inside one institution, I had to rebuild from nothing the structure that the institution used to supply for free: deadlines, review, and someone who noticed when a task stalled. Nobody was going to notice for me anymore. The failure log was the cheapest replacement I could build.
My working formula is Belief × Thinking × Action. A failure log is what keeps the Thinking term from collapsing to zero when the Action term keeps producing errors you don’t understand yet.
Why does shipping beat studying when you can’t read the material yet?
Because a beginner can’t tell which parts of a subject matter yet. Shipping forces the subject to tell you. Every error is a ranked signal — it names the exact gap blocking real output, in the order it blocks you. Reading gives you an author’s priority list; shipping gives you yours.
This is the angle I can speak to first-hand: I built and shipped working software without being able to read code. Not by pretending the gap wasn’t there, and not by faking competence — by writing down every single point of failure as it happened, and treating that written record as the thing I was actually building.
There is also a memory argument, with a caveat worth stating. When Murre and Dros replicated Ebbinghaus’s forgetting-curve experiments in PLOS ONE (2015), they largely reproduced the steep early drop-off he described — though the material was nonsense syllables, not real-world skills, so don’t read it as a precise decay rate for what you’re learning. The modest takeaway still holds: passively absorbed material fades fastest right after you meet it. A failure you hit personally and wrote down at the moment of impact is easier to get back, because you can retrieve it by symptom.
What failure log format actually works?
One entry per failure, written while it’s still happening — not afterward. Six fields: date, symptom in plain language, the last thing you changed, what you expected versus what happened, what you’re blocked on, and the fix that worked. The symptom line matters most; it’s how you find the entry again months later.
The six fields
- Date — so repeats become visible as a pattern, not a mood.
- Symptom — written the way it looked to you, in plain language, with no diagnosis attached.
- Last change — the single most recent thing you touched before it broke.
- Expected vs. happened — two short clauses. In my experience a good share of entries resolve right here, before you go any further.
- Blocked on — one of four tags: a decision, someone else, an external reply, or me.
- Fix that worked — or, if unresolved, a pointer to the open item you filed instead.
A real-shaped entry
- Symptom: “Works when I run it here, blank screen after publishing.”
- Last change: renamed a settings value.
- Expected / happened: expected the published version to pick up the new name; it kept using the old one.
- Blocked on: me.
- Fix: the published environment holds its own copy of settings — changing it in one place changes nothing in the other.
One rule carries most of the value: the index line describes the symptom, not the topic. A note filed as “environment variables” is never found again, because at the moment you need it you are not thinking “environment variables” — you are thinking “blank screen after publishing.” I learned this the expensive way, by building a knowledge system that only started compounding after I rewrote every index line as a symptom.
Which failures repeat most for a total beginner?
In my own log, four categories covered most of the entries, and few of them were about the skill itself. Environment mismatches, wiring mistakes, unstated assumptions in my own requests, and work that had simply stalled while I waited on something. Only a remainder were genuine knowledge gaps — the thing I had assumed was the whole problem.
| Category | What it looks like | Checklist question it became |
|---|---|---|
| Environment mismatch | Works in one place, not another; wrong version, wrong folder, wrong copy of a setting | Is the thing I changed the same copy the broken version is reading? |
| Wiring, not logic | Every piece is correct but nothing is connected; old version still being served | Did my change actually reach the thing I’m looking at? |
| Unstated assumption | I asked for one thing while silently expecting another, then blamed the output | Did I write down what “working” means before I asked? |
| Stalled, not broken | Nothing failed — I was waiting on a decision or a reply and hadn’t noticed | What is this blocked on, and is it a one-line decision I can make now? |
| Real knowledge gap | I genuinely don’t know the concept | What is the narrowest thing I can read to unblock this one item? |
The lopsidedness is the finding. As a beginner I assumed my problem was ignorance of the subject. My log said otherwise: most of my lost hours were logistics, mismatched copies, and my own vague requests. That reframe is what made progress possible without being able to read the material.
How does a failure log become a checklist that shortens the next build?
Sort the log by symptom, and repeats surface on their own. Any failure you logged three times becomes a checklist question you run before asking for help. The checklist is short, phrased as questions, and lives next to the project. Later builds get faster because the same four categories stop reaching you.
Two details keep it useful. First, the checklist is written as questions, not instructions — questions force you to look, instructions get skimmed. Second, it stays under roughly a dozen lines; anything longer gets abandoned. When a question stops catching anything for a few builds, it gets deleted.
The mechanism has research behind it. Di Stefano, Gino, Pisano and Staats (Harvard Business School working paper 14-093, “Learning by Thinking”) ran a field experiment in which call-center trainees who spent 15 minutes at the end of the day writing reflections on what they’d learned scored roughly 23% higher on a final training assessment than peers who spent that time working. The log is that 15 minutes, made concrete.
Tutorial-first or ship-and-log: which is more productive?
Tutorial-first is more comfortable and more complete; ship-and-log is more productive per hour because it only teaches what’s blocking you. The honest answer is sequence, not either/or: ship first, let the failures name your gaps, then read narrowly to close them. Reading chosen by your own log sticks.
| Dimension | Tutorial-first | Ship-and-log |
|---|---|---|
| What sets the agenda | The author’s outline | Your own blocking failures |
| Time to first real output | Late — after the curriculum | Immediate, and broken on purpose |
| Retention | Decays fast without retrieval | Anchored to a symptom you personally hit |
| Emotional cost | Low, but easy to mistake for progress | High early, drops once the checklist forms |
| Coverage | Broad and even | Uneven — deep where you were blocked, blank elsewhere |
| Best used for | Closing a named gap the log identified | Finding out which gaps are real |
How do you keep from starting more than you finish?
Cap started work at two items per project. Ideas stay unlimited; only starting is rationed. A backup scan of my own machine turned up 41 tasks abandoned mid-flight — none had failed, they had all simply been left. Anything untouched for 30 days gets surfaced as a discard candidate, and most get discarded.
That scan changed how I read my own productivity. The bottleneck was never the number of ideas; it was that ideas arrived faster than anything could be finished, and each new start silently orphaned an old one. Rationing starts — not ideas — fixed it.
The other half is the open-items ledger: every stalled task written down with a tag for what it’s blocked on. Items blocked on a single decision are the cheapest progress available, so they get cleared first — one line from me and the task is moving again. Treating abandonment as maintenance rather than failure is what keeps the ledger honest enough to trust.
What does the research say about learning productivity?
The evidence suggests reflection and pre-commitment do more than simply adding hours. In the Harvard Business School field experiment described above, call-center trainees who spent 15 minutes a day writing reflections scored about 23% higher on the final training assessment than peers who kept working. Written if-then plans — implementation intentions — showed a medium-to-large average effect across 94 independent studies in Gollwitzer and Sheeran’s 2006 meta-analysis.
- Habits take longer than you think. Lally and colleagues (European Journal of Social Psychology, 2010) found a median of 66 days for a new behaviour to become automatic, with individuals ranging from 18 to 254 days. Plan for months, not a two-week sprint.
- Beginners are no longer alone at the tool level. Stack Overflow’s 2024 Developer Survey reported that about 76% of respondents were using or planning to use AI tools in their development process — which is precisely why the scarce skill has shifted from typing the answer to diagnosing why the answer didn’t work.
- “20 hours to competence” is a claim, not a study. Josh Kaufman’s popular figure is a useful motivator; deliberate-practice research in the Ericsson tradition describes a much longer road to expertise. Use the 20 hours to get something shipped, not to declare yourself done.
What is the smallest system you can start today?
Three files and one rule. A failure log with six fields, an open-items ledger tagged by what each item is blocked on, and a checklist that grows from repeats. The rule: never more than two started items. Set it up in twenty minutes, then start the build you’ve been postponing.
None of this requires understanding the skill first. It requires being willing to write down, honestly and immediately, the moment you got stuck — including the embarrassing ones, which are usually the ones that repeat.
If you want the same loop for goals outside a build — where the failures are missed days rather than error messages — the VisionDream app turns a goal into daily habits and shows you where it stalls. And if the harder question underneath this is why effort keeps failing to convert into results, that’s the subject of my book, Why Do I Fail While Others Succeed?
Start the log before you start the build. The log is the part that survives.