The order of the work is the work

Reza Harirchian — Sat, 14 Nov 2026 09:48:42 +0000

Most weeks in software follow the same pattern. A new release lands, a new tool trends, and the work you were doing gets restarted in a new place. You re-learn the tool, re-brief the assistant, re-upload the files, and start the same task over again. By Friday, the week has produced motion and very little finished work.

There is a different way to run a week, and it is not a new tool. It is an order of operations. Diagnose before you fix. Write the spec before you code. Read the code before you touch it. Cite the source before you quote the answer. Do one concrete thing, start to finish, in one workspace. That is the whole method, and it is the subject of this article.

The fix that fits in one sitting

The best-performing work we published this month was not a big announcement. It was one small fix, done completely: a single concrete bug, fixed start to finish, in about two minutes, on the free tier. The formula is worth naming because it scales. Pick one thing small enough to finish. Finish it. Then pick the next one.

Big rewrites fail for a boring reason. They are too large to verify, so nobody verifies them, and the breakage surfaces weeks later in a place nobody is looking. A small fix can be checked. You know what changed, you know what it was supposed to do, and you can confirm it still does it. That is the difference between work that ships and work that lingers.

So the rule for the week is simple. One concrete fix at a time, finished before the next one starts. The rest of this article is the order that makes that rule work.

Step one: write it down before you build it

Code written without a spec is a guess with a keyboard. You build the wrong thing well, then rebuild it, and the second build costs more than the first. The spec is the work, written down before the code exists.

A useful spec is short. Four lines are enough for most tasks:

What it does:
What it does not do:
How I will check it:
What done looks like:

The second line matters as much as the first. "What it does not do" is where scope creep gets stopped before it starts. The third line is where the review begins, because a spec with no check is a wish, not a plan.

Review the spec the way you review code. A wrong spec ships a wrong build, only slower, because the code faithfully implements the mistake. When the spec is right, the build has something to match and the review has something to check against. When the spec lives next to the code it describes, in the same workspace, neither one drifts away from the other.

Step two: read before you touch

Code written in a hurry does not stay a hurry. It becomes dead branches, duplicated blocks, and names that lie about what the function does. Every time you open the file, you pay for it again.

The cleanup has an order, and the order is the point. Read the code before you touch it. Cut what does nothing. Name things for what they do. Then check that it still does exactly what it did before, only cleaner.

Notice what is not in that list: rewriting the file. Cleanup is not a rewrite. A rewrite is a new program that happens to share a filename, and it needs a spec of its own. Cleanup is surgery on the existing program, with the behavior unchanged. The check at the end is what makes it cleanup instead of damage. If you cannot confirm the behavior is unchanged, you did not clean the code. You changed it, and you do not yet know how.

This is the diagnosis-first habit applied to code. The same instinct that says "find the bug before fixing it" says "understand the file before editing it." In both cases the diagnosis is the work, and the fix is the easy part.

Step three: check it against something real

Research has the same disease, in a different form. You ask a question, you get an answer, and you have no idea whether any of it holds. So you check it yourself, or you quote it and hope nobody asks.

The order fixes it. Write the question down first. Read the sources, not the summary. Ask for the answer with its citations attached. What comes back is a document you can defend, every claim traceable to where it came from.

This is not a nicety. An answer you cannot check is not much use, because the moment someone asks "where did that come from," the work stops and the checking starts anyway. Citations move that checking to the beginning, where it is cheap, instead of the end, where it is expensive. The same logic applies to the spec in step one and the behavior check in step two. Every step in this method ends with evidence, not with a feeling.

The workspace question

None of this needs a new tool. It needs one place where the work stays put. Chat, research, code, and images together, so nothing gets re-explained and nothing gets lost between tools. The cleaned code stays where you cleaned it. The spec stays next to the code. The document carries its citations and, when it needs one, an image made in the same place.

That is also how to judge a tool, by the way. Not by what is newest, but by what gets finished. Every week brings a new release and a new reason to switch. Switching has a cost that never appears on the announcement page: the re-learning, the re-briefing, the re-uploading. Judge by the work that gets finished, and the answer is usually to stay put and finish the thing in front of you.

A first task for this week

Here is the whole method as one task, small enough to do today.

Pick the task you keep restarting. One task, not three.
Write the four-line spec before you touch the code.
Read the code, cut one dead branch, rename one lying name, and confirm the behavior is unchanged.
If the task needs research, write the question down first and ask for the answer with citations.
End with one document, or one commit, that shows the finished thing.

Try it on real work. SpyCore has a free tier, no card, and the whole workflow above runs in one workspace: chat, research, code, and images together. One subscription, one weekly credit pool, no overage, so a spec written first is not a guess burned on the wrong direction.

The order of the work is the work. Diagnose first, specify first, clean carefully, cite everything. Then finish one thing, and pick up the next.