Running my study life like an engineering backlog

· method

I stopped keeping a to-do list for research and started keeping a backlog. The difference sounds like semantics; in practice it changed what got finished. A to-do list is a flat pile of good intentions. A backlog has structure: tickets, dependencies, and an order that falls out of those dependencies instead of out of mood.

Three ideas doing the work

The whole system is three borrowed engineering habits.

Tickets. Every unit of work — a paper to read, a repertoire line to fix, this very website — is a ticket with a single concrete deliverable and enough context that a cold-started version of me (or an assistant) can pick it up without re-deriving everything. If I can't name the deliverable, the ticket isn't ready; that's a feature.

Dependencies. Tickets declare what blocks them. A "write the literature table" ticket is blocked by "collect the PDFs". Once every ticket knows its blockers, the build order isn't a decision I agonize over each morning — it's just a topological sort of the graph. I do whatever is unblocked and highest-leverage. The anxiety of "what should I work on" mostly disappears.

Frozen contracts. This is the one that saves me. When ticket B depends on a file ticket A produces — a data schema, a brand spec, a set of design tokens — I freeze that file's format the moment B starts consuming it. After the freeze, changing A means deliberately touching everyone downstream, in the same sitting. It converts "I'll just tweak this real quick" from a silent time bomb into a visible, priced decision.

Waves, not sprints

I batch tickets into waves by dependency depth. Wave 1 is everything with no blockers — the foundations that unblock the most. Wave 2 consumes wave 1, and so on. It's deliberately not time-boxed like a sprint; a wave is done when its tickets are done, because a PhD does not respect two-week boxes. The point of the wave isn't a deadline, it's making sure I never start the roof before the walls.

The same instinct runs my chess: don't start the attack before the structure supports it. Backlog discipline is just positional play for time.

Where it breaks

Honesty clause, because this is a lab. The overhead is real: writing a good ticket takes ten minutes I could spend doing the thing, and for genuinely small tasks that's a bad trade — I don't ticket "reply to this email". The system also tempts you to groom the backlog instead of burning it down; rearranging tickets feels like progress and isn't. And frozen contracts only help if you actually freeze them — a contract you quietly renegotiate every session is just a comment.

What I'd check next

The measurable question: does this actually raise throughput, or just make me feel organized? Next time I'll track cycle time — ticket opened to closed — across a month and see whether the dependency structure shortens it or just decorates it.