I could not read code. I shipped working software anyway. This is the method, the actual log, and the parts that would have stopped me if I had tried to study my way in first.
Can you learn to build without coding, or do you have to study first?
Yes, you can learn to build without coding by shipping first and writing down every failure the moment it happens. I left a 26-year career, could not read code, and still shipped working software. The log of what broke became my curriculum, and it taught faster than any course order could have.
The reason is unglamorous. A course teaches you the map of a territory. A failure log teaches you the three streets you actually walk every day. When you are building one real thing, those three streets are ninety percent of the job.
What is the failure log method, exactly?
A failure log is one line written at the moment something breaks: what I tried, what happened instead, and what fixed it. No theory, no cleanup, no waiting until the end of the day. After a few weeks the entries cluster into categories on their own, and the categories that keep coming back become the syllabus.
Three rules kept mine usable:
- Write it while it hurts. Fifteen minutes later I could already no longer reconstruct what I had actually tried.
- One entry, one failure. Bundled entries are never found again.
- Record the symptom, not the topic. This one took me longest to learn, and I cover it below. It is the difference between a knowledge system that compounds and a folder of notes nobody opens.
What did my failure log actually contain?
Mostly boring, repeatable breakage — not exotic programming problems. Almost nothing in it required reading code. It required noticing that the same shape of failure had happened before. Here is the categorized sample from my own log, with how often each category came back and what it eventually taught me. The frequencies are my ranking of my own entries, not a measurement of anything beyond my setup.
| Category | What the entries looked like | How often it returned | What it taught |
|---|---|---|---|
| Encoding and display | Korean text coming out of the terminal as garbage characters; output readable in one tool, unreadable in another | Most frequent | Text has a format, not just content. Always state the encoding explicitly instead of trusting a default. |
| Path and location assumptions | A script guessing where a project lived and writing to the wrong folder | Second most frequent | Never let a tool infer location. Keep one file that lists every project and its absolute path. |
| Duplicate sources of truth | The same automation script existing in four places, each quietly drifting from the others | Recurring | Copies are not backups, they are future bugs. One canonical location, everything else a link. |
| Wrong tool for the scale | A search tool walking an entire knowledge vault and stalling on large binary files | Recurring | Tools fail by size, not by logic. Diagnose by counting items before blaming the code. |
| Identity and account mix-ups | Work committed under the wrong account because two projects use different identities | Occasional | Attach identity to the project, never to the machine or the habit. |
| Data going somewhere unintended | A shared sync folder that turned out to reach a colleague’s laptop | Once, decisive | Check where a folder actually goes before it becomes a working channel. |
| Abandoned mid-flight work | A backup scan turning up 41 tasks started and silently dropped | Once, decisive | Starting is the scarce resource, not ideas. |
The two categories at the top repeated far more than the rest. That is the whole finding. Encoding and path assumptions are not advanced topics — no syllabus would have put them in week one — yet they were where my real hours went. A failure log surfaces that ranking automatically. Studying first cannot, because the ranking is specific to your machine, your tools, and your project.
Why does logging failures beat studying first for a non-coder?
Because errors are the content, not the interruption. Research on error management training points the same direction: the meta-analysis by Keith and Frese in the Journal of Applied Psychology (2008) reported that training which encourages learners to make and analyze errors outperformed error-avoidant training by a moderate margin, with the advantage largest on tasks learners had not encountered during training.
Two more findings line up with what the log did for me:
- Retrieval beats rereading. Roediger and Karpicke’s work in Psychological Science (2006) found that taking a test on material produced better long-term retention than restudying it, even though restudying looked better on an immediate test. Writing a failure entry is closer to retrieval than to rereading — you reconstruct what you did, from memory, under pressure. That connection is my own extension of the finding, not a claim the study makes.
- Even professionals spend much of their time on things not working. In the Stripe and Harris Poll Developer Coefficient survey (2018), developers self-reported spending roughly 17 hours a week on maintenance work such as debugging, refactoring, and dealing with bad code. Self-reported hours are rough numbers, but if maintenance is anywhere near that share of the job, then a log of what breaks is not a beginner’s crutch. It is the job’s real notebook.
Two more data points explain why the door is open at all. Stack Overflow’s annual Developer Survey has repeatedly found that most respondents pick up coding skills from online resources — documentation, videos, forums — alongside or instead of a formal sequence, though the survey is self-selected rather than representative. And in 2021 Gartner forecast that by 2025, 70% of new applications developed by organizations would use low-code or no-code technologies, up from less than 25% in 2020; that was a projection rather than a measured outcome, and I have not seen it independently confirmed after the fact. The tooling moved toward people like me. The learning method had to move too.
How does a failure log compare with a course-first approach?
| Course first | Failure log first | |
|---|---|---|
| Where the syllabus comes from | An instructor’s model of a general learner | Your own repeated breakage, ranked by frequency |
| First feedback | After a module, on an exercise | Within minutes, on the real thing |
| What you carry forward | Concepts you may not need this year | Fixes for the failures you are guaranteed to hit again |
| Typical failure mode | Finishing the course, shipping nothing | Shipping something with real gaps in theory |
| Best for | Building a career-length foundation | Getting one working thing into the world now |
This is not an argument against courses. It is an argument about order. Ship, log, then study the categories your log keeps naming. By then you know exactly which chapter you need, and you read it with a reason.
How do you stop the log from becoming another abandoned project?
By treating stalled work as data instead of shame. Four rules keep mine alive, and all four came from things that went wrong.
- One ledger for everything stalled. I keep a single open-items ledger as the source of truth, and every item is tagged by what it is blocked on: a decision, someone else, an external reply, or me. When the ledger and a project document disagree, the ledger wins.
- Clear the decision items first. An item blocked on one line of judgment is the cheapest progress available anywhere. It costs a sentence and unblocks days.
- Cap started work at two per project. After that backup scan found 41 tasks abandoned mid-flight, I stopped rationing ideas and started rationing starts. Ideas stay unlimited. Only beginning is limited.
- Treat abandonment as maintenance. Anything untouched for 30 days is surfaced weekly as a discard candidate, and most get discarded. Discarding is not failure; it is what keeps the list trustworthy enough to read.
One more thing decides whether any of this compounds: the index line. A note filed as “encoding” is never found again. A note filed as “Korean text turns into garbage characters in the terminal” is found instantly, because that is what you will be typing at the moment you need it. Index by symptom, not by topic. That single change turned my notes from an archive into a tool.
What is the smallest way to start this week?
Pick one thing you actually want to exist. Not a practice project — something you would use. Then open a plain text file and write one line every time it breaks, in the words you would use to describe the pain to a friend. After two weeks, read the file and count categories. Your top two are your curriculum.
I rebuilt everything after leaving one institution at 26 years in — the deadlines, the review, the person who noticed when something stalled. Nobody supplies that for you afterward. The ledger became the person who notices. The failure log became the teacher. That is the whole scaffolding, and it is buildable in an afternoon.
My formula has not changed through any of it: Belief × Thinking × Action. Belief that a non-coder can ship. Thinking clear enough to write down what actually broke. Action small enough to happen today. It is multiplication, so a zero anywhere collapses the result — and for most people the zero sits in Action, waiting for the studying to feel finished. It never feels finished.
If turning goals into daily habits is the part that keeps stalling for you, that is exactly what I built the VisionDream app to hold — goals broken down into something you do today rather than something you plan again. And if you want the longer story behind the comeback, the method, and why effort alone kept failing me, it is in my book Why Do I Fail While Others Succeed?
You do not need to read code to ship. You need to write down what broke, in the moment it broke, and be willing to read your own handwriting back.