What my dog taught me about building consistently

The hard part is returning to the work

I used to think consistency meant producing the same amount every day. That is impossible when one day is product strategy, the next is debugging, and the next disappears into customer calls.

The useful definition is simpler: can I return to the work without spending half the day reconstructing what I was doing?

That changes what a routine is for. It does not have to guarantee a perfect output. It only has to make starting familiar and leave enough context that tomorrow’s version of me can enter the work without a long negotiation.

I keep the anchor stable and let the effort vary. The same desk, the same short planning note, and roughly the same stopping boundary can support a long build session or twenty careful minutes. The repeatable part is the return, not the volume.

A good routine protects the return, not the streak.

The walk creates a clean break

My husky does not care whether the deployment worked. At roughly the same time, we go outside. 🐕 That boundary stops me from dragging one frustrating task through the rest of the day.

Walking also changes the kind of thinking available. I stop staring at the implementation and start noticing the decision underneath it. Quite often, the problem is not the code I was fighting. It is a product choice I had not made clearly.

The walk works because it is ordinary. I do not need to earn it by finishing the task, and I do not treat it as another optimization technique. It is simply a reliable change of context. That is often enough for the noise of the last hour to settle.

A small loop keeps the day honest

Before I begin, I choose an outcome small enough to recognise when it is complete. “Work on onboarding” invites endless motion. “A new user can save the first decision and recover from an invalid input” gives the day a finish line.

1. 01
   Name one outcome. 🎯

   Write the one thing that should be more true by the end of the work block.

2. 02
   Work until the next decision. ✂️

   Do not invent extra scope just because there is time left.

3. 03
   Leave a restart note. 📝

   Record what changed, what is open, and the first useful action for tomorrow.

4. 04
   Step away properly. 🚶

   A real break makes returning easier than half-working all evening.

The restart note is the smallest part and the most valuable. I write the current state, the unresolved question, and the first action that would produce evidence. That note removes the need to trust memory after sleep, interruptions, or an unexpectedly busy morning.

Reduce the scope, keep the connection

Some days will not support deep work. On those days I shrink the loop instead of pretending I can force a perfect session.

• Review one open decision.Clarity still moves the product forward even when code does not.
• Fix one small source of friction.A better name, note, or test can make tomorrow easier.
• Write down the blockage.An explicit obstacle is less expensive than a vague feeling of being stuck.

The point is not to protect a productivity score. It is to keep a live connection with the product.

On a bad day, the minimum version may be reading yesterday’s note and making one decision explicit. That still reduces the cost of tomorrow. Consistency becomes resilient when the routine has a smaller mode instead of an all-or-nothing rule.

The five questions I use each week

This is not a complicated operating system. That is why it survives busy weeks. Focus, build, leave a clear trail, and come back.

I end the review by removing one obligation that no longer serves the main outcome. A useful weekly reset should create space, not turn unfinished work into a larger pile of guilt.