Steps Become Routines, Routines Become Systems
How a single repeated action turns into a capability you can point at a problem you have never seen before. This is the progression, with a worked example.
There are four stages, and most people stop at the second without realising there were two more.
1. A step
One action, done once. Write a note. Fix one broken link. Read one page of the documentation.
A step is small enough that doing it is easier than deciding whether to do it. That is the whole property that matters — if a step requires a decision, it is too big, because the decision costs more than the action and you will run out of decisions long before you run out of time.
The mistake at this stage is choosing a first step sized for how motivated you feel today.
2. A routine
The same step, at the same time, without deciding each time.
A routine is a step that has stopped costing a decision. That is its entire advantage, and it is a large one: the effort of starting drops to nearly nothing, so the work happens on ordinary days rather than only on good ones.
Two things make a step stick as a routine:
- Attach it to something that already happens. After the first coffee, before opening email, straight after work. An existing fixed point does the remembering for you.
- Keep it the same shape. Variation is a decision in disguise.
Most advice stops here, and this is where most efforts stall — because a routine still only produces one action's worth of value each time you do it. Nothing accumulates yet.
3. A system
A routine gets an output with a fixed shape, so that the results stack up instead of evaporating.
This is the step that changes what the work is worth. The difference between writing a note every day and having a system is whether the note has a form you can read back later. If every entry answers the same few questions — what did I do, what is next, what blocked me — then a month of entries is a searchable record of how long things take and where you get stuck. If every entry is freeform, a month of entries is a month of paragraphs nobody will ever reread.
A system is a routine plus a shape. Practically:
- Give the output a consistent structure, even a crude one.
- Keep it all in one place, so that finding it is not itself a task.
- Make the structure answer a question you actually ask later. This is the test: if you have never once gone looking for the information, the structure is wrong.
4. A framework
A system that is general enough to point at something new without redesigning it.
A framework is what you have when the shape stops being about the specific thing you built it for. The note format that worked for learning JavaScript works unchanged for learning a deployment pipeline. The checklist that caught mistakes in one project catches them in the next. You are no longer solving the problem; you are applying something you already own.
This is where the compounding actually happens, and it is why the progression is worth finishing. A step pays once. A routine pays repeatedly. A system pays repeatedly and keeps the results. A framework pays on work you had not thought of when you built it.
A worked example
The notebook you are reading is the progression. It did not happen in one move, and no stage of it was designed before the one before it was running.
- The step was writing down what was learned on a given day, once, so it would not be lost.
- The routine was doing that daily, first thing, at the same point in the day — which is what made it survive weeks where nothing else went to plan.
- The system was giving those notes a fixed shape and one home, so that the answer to "how did I do that last time" was somewhere specific rather than somewhere in general.
- The framework is what it is now: notes become drafts, drafts get reviewed and edited, and only reviewed drafts are published as articles. That pipeline does not know or care what the article is about. It was built while writing about web development and it works unchanged for anything else.
None of those stages was planned from the one before. Each was the obvious next move once the previous one had been running long enough to be annoying in a specific way — which is the actual signal to advance. Do not design the framework first. A framework built before there is a system to generalise is a guess about work you have not done yet.
Solve it once and keep it
The same principle applied to code is worth stating on its own: when you work something out, save it in a form you can use again. A working example kept in your own codebase is worth more than the same example on the internet, because you already know it works and you already know why you wanted it.
Do this and you stop starting from a blank screen — which is not really a motivation problem, it is a systems problem, and it goes away when you have something to start from.
What this is actually for
The reason to build the progression is not to become maximally productive. It is that skills built this way are the ones that are still there later, and they are what let you build whatever you decide you want to build.
The steps are small on purpose. That is not a compromise — it is the mechanism.