Sustaining This While Working Full-Time

Thirty-four months at 11 hours a week is 130 active weeks. The plan does not fail because a project is too hard. It fails because week 61 is the week of a production incident, week 62 is the week you are too tired to start again, and week 63 never happens.

This page is about weeks 61 to 63.

Table of Contents

• The Actual Failure Mode
• The Resumption Problem
• Designing Your Week
• The Three Modes
• The Two-Week Stall Rule
• Planned Breaks
• When Work Takes a Quarter
• Motivation Is Not the Mechanism
• Using Your Job
• The Quarterly Honest Check
• References

The Actual Failure Mode

It is not difficulty. It is not time. It is the cost of restarting after a gap, which compounds:

week 60   normal
week 61   incident at work. 0 hours.
week 62   tired. 0 hours.
week 63   open the repo. No idea where you were. Read code for 40 minutes.
          Feel bad. Close the repo.
week 64   avoid it, because opening it now carries the feeling from week 63
week 65+  the project is over, and nobody decided that

Nothing in that sequence involves the work being too hard. The mechanism is:

1. A gap creates context loss — an hour of re-reading before any progress.
2. Context loss creates a bad session — an hour spent, nothing produced.
3. A bad session creates avoidance — the repo now predicts an unpleasant feeling.
4. Avoidance creates a longer gap, and the loop tightens.

Every mechanism below attacks one of those four steps. Note that step 1 is the only one that is about the work; steps 2–4 are about how the work feels, which is why "just be disciplined" does not fix it.

The Resumption Problem

The single highest-leverage habit in this entire program: never end a session without writing down where you are.

At the end of every session, five minutes, in notebook/RESUME.md (overwritten each time — it is a pointer, not a log):

# RESUME — last touched 2027-03-14

PROJECT   : P05, milestone 7 (log replication)
STATE     : matchIndex updates on AppendEntries success. Commit rule not done.
NEXT      : implement the commit rule in raft.go:214. Careful — §5.4.2, a leader
            may NOT commit a previous-term entry by counting replicas.
BLOCKED   : TestLeaderCompleteness fails when a node restarts mid-election.
            Suspect persistence ordering: I think we persist votedFor after
            replying. Check that first.
COMMAND   : go test -race -run TestLeaderComplete ./raft/
CONFIDENCE: medium. The failure is deterministic with seed 7734.

NEXT must be small enough to start in 60 seconds. "Implement the commit rule in raft.go:214" is startable. "Continue Raft" is not — it requires a decision, and a decision after a three-week gap costs more energy than the work does.

This turns a 40-minute re-orientation into a 3-minute one, which is the difference between a bad session and a good one, which is the difference between a gap and an ending.

Also, deliberately: stop mid-task, not at a clean boundary. A half-written function with a failing test is far easier to resume than a green build and an open question. This is uncomfortable and it works — the Zeigarnik effect is real, and an unfinished task stays partly loaded.

Designing Your Week

Three principles that matter more than the specific schedule.

1. Fixed slots beat available time. "I will work on it when I have time" produces zero hours in a bad month. Two fixed weekday evenings and one weekend block produce 11 hours in a bad month and a good one, because they are already spent.

2. Protect the weekend block above all. It is the only session long enough for deep work — debugging a distributed system, deriving a backward rule, writing a report. If something must be cut, cut a weekday session. Two 2-hour weekday sessions and one 3-hour weekend block survives a bad week far better than five 1-hour sessions with no long one.

3. Match the work to the energy, not to the plan. A weekday evening after a hard day is not when you design a consensus protocol. It is when you write tests, refactor, plot results, or write documentation. Save the hard thinking for whenever your good hours actually are — which, for most people, is not Thursday at 9pm.

A shape that works, from the operating model:

The Three Modes

Not every week is a normal week. Declare which mode you are in, in the weekly log, so that a reduced week is a decision rather than a failure.

Full mode — 11 h/week

The default. All six weekly outputs.

Maintenance mode — 3 h/week

For a bad week: an incident, travel, illness, a family obligation, a launch.

• One session. Small, concrete work only: a test, a plot, a paragraph of the report.
• RESUME.md updated every time. This is what maintenance mode is for.
• No new milestones. No design decisions.
• Declared in the log as maintenance, with the reason.

Maintenance mode is not failure. It is the designed worst-case path — the same idea as Lampson's "handle normal and worst case separately", applied to your own schedule. A week at 3 hours with the context preserved costs you 8 hours of progress. A week at 0 hours with the context lost costs you 8 hours plus a re-entry, plus the risk of the avoidance loop.

Cap: 4 consecutive weeks. Beyond that, see the two-week stall rule and when work takes a quarter.

Zero mode — 0 h/week, planned

For a genuine break. See planned breaks. The rule: write RESUME.md before you start it, not after.

The Two-Week Stall Rule

If a milestone has made no measurable progress in two consecutive full-mode weeks, it stops being a work problem and becomes a decision.

Not "try harder". Not "push through". A written decision, in the log, choosing one of four:

Two weeks, not four. Four weeks is a month, and a month of no progress on a Medium project is a third of it.

And the corollary, which is the important half: if you abandon a project, you write a postmortem. Not a paragraph of self-criticism — a technical document: what you were trying to do, how far you got, what specifically stopped you, what you would do differently, and what you learned anyway.

A project with a postmortem is a completed learning experience. A project abandoned in silence is a wound, and the wound is what makes the next project harder to start.

Planned Breaks

Unplanned breaks are dangerous. Planned breaks are restorative, and the difference is entirely whether RESUME.md was written first.

Build in:

• One week off between stages (after M7, M15, M22, M26, M31). Five breaks. This is already inside the 46-productive-weeks-per-year assumption in the duration derivation.
• Two weeks off per year for actual holiday.
• The week after a work crunch — deliberately, in maintenance mode, not full mode.

Before any break:

1. Get to a green build. Do not leave a break with a failing test; it becomes the thing you dread.
2. Write RESUME.md with a NEXT that is startable in 60 seconds.
3. Commit and push. Write the commit message for a stranger.
4. Write down the return date. A break with an end date is a break; one without is a drift.

The first session back is deliberately trivial. Re-read RESUME.md, run the tests, fix one small thing, update RESUME.md. Do not schedule a hard milestone for the returning session — the goal is to re-establish that opening the repo is a neutral act.

When Work Takes a Quarter

It will, at least twice in 34 months. A promotion, a re-org, a migration, an outage that becomes a project. Plan for it now, while it is hypothetical.

The protocol:

1. Declare it. Write in the log: "Q3 2027 is a work quarter. Maintenance mode until ⟨date⟩." A declared reduction is a plan; an undeclared one is a collapse.
2. Maintenance mode, not zero. 3 hours a week, one session, RESUME.md every time. Three hours preserves the thread; zero severs it.
3. Finish what you are in the middle of, at reduced scope, rather than pausing mid-milestone. A completed project at MVI scope is worth more than a standard-scope project frozen at 70%.
4. Do not restart the schedule when you return. Recompute it. Add the lost weeks to the calendar and move the end date. The plan is 34 months of work, not 34 months of calendar — and it already assumes six weeks lost per year, so one bad quarter is roughly one quarter of slip, not a catastrophe.
5. Do not compensate by working 20 hours a week afterwards. It does not work, and the crash that follows costs more than the deficit.

What a quarter actually costs: at 3 h/week for 13 weeks you complete 39 hours instead of 143 — a deficit of ~104 hours, or about 9.5 weeks of active work. Two such quarters across the journey adds roughly 5 months to the end date. That is already survivable and it is why the headline is 34 months and not 24.

Motivation Is Not the Mechanism

Motivation is a consequence of progress, not a cause of it. So the plan generates progress mechanically and lets motivation follow.

When motivation is absent anyway — and there will be months — fall back to the mechanism: open RESUME.md, do the NEXT item, update RESUME.md, stop. Twenty minutes. Do not attempt to feel enthusiastic first. Enthusiasm follows a completed small thing far more reliably than it precedes one.

Using Your Job

Thirty-four months of evenings is a lot. Some of it can overlap with work, honestly.

The line to hold: work code stays at work, and this journey's repositories are yours. Confusing them creates an IP problem that is entirely avoidable and extremely tedious to resolve. If in doubt, build the general version at home and never copy in either direction.

The Quarterly Honest Check

Every three months, ten minutes, written. Five questions.

1. Am I on schedule? Actual hours vs planned. If more than 15% behind, cut scope from the next stage using the cut table and record what you cut. Do not plan to catch up; nobody catches up.
2. Am I in maintenance mode more than full mode? If two of the last three months were maintenance, the weekly design is wrong. Change the slots, not your resolve.
3. Is RESUME.md current? If it has gone stale, that is the earliest detectable signal of the failure loop. Fix it today.
4. Am I still doing the loop, or just building? Check the last three notebook entries. Are sections 4, 5 and 6 filled in before the results? If not, the discipline has quietly drifted and the journey has become a build log.
5. Do I still want this? A real question, and it deserves a real answer. If the answer is no, the correct response is to stop deliberately and write the postmortem — not to continue joylessly for six more months and then stop by attrition. Fifteen projects is a plan, not a contract.

Question 4 is the one that catches the most dangerous drift, because building feels like progress and it is the half of the loop you already knew how to do.

References

• Zeigarnik, B. Über das Behalten von erledigten und unerledigten Handlungen. Psychologische Forschung 9, 1927. Unfinished tasks remain more accessible in memory — the basis for stopping mid-task.
• Mark, G., Gudith, D., Klocke, U. The Cost of Interrupted Work: More Speed and Stress. CHI 2008. The measured cost of context switching; why RESUME.md pays for itself.
• Parkinson, C. N. Parkinson's Law. The Economist, 1955. Work expands to fill the time available — the argument for fixed slots over available time.
• Lampson, B. W. Hints for Computer System Design. SOSP 1983. "Handle normal and worst case separately." Maintenance mode is the worst-case path, designed rather than improvised.
• Newport, C. Deep Work. Grand Central, 2016. On protecting the long block.
• Clear, J. Atomic Habits. Avery, 2018. Systems over goals; the two-minute rule, which is what "NEXT must be startable in 60 seconds" implements.
• Boice, R. Professors as Writers. New Forums Press, 1990. The empirical case that regular short sessions outperform binges — the same finding that shapes the writing allocation.
• Brooks, F. P. The Mythical Man-Month, anniversary ed. Addison-Wesley, 1995. How projects fall behind: one day at a time.