You set a timer
for twenty five minutes.
Work until it rings,
five minutes off,
start again.
For the first ten minutes
you circle the problem.
You reread the code.
You try the wrong idea
and throw it away.
Around minute twenty
it starts to open.
You can hold the whole thing
in your head at last.
The timer rings.
You stand up,
because that is the rule,
and when you sit down again
the whole thing has gone
and you start circling
from the beginning.
A timer is a good tool
for the hard part,
which is starting.
It turns a task
you have been avoiding
into a promise
small enough to keep.
Just twenty five minutes.
Anybody can do that.
It is a bad tool
for the part after that,
because it does not know
where you are.
Deep work takes time
to load into your head.
The first stretch of any session
is mostly loading.
A fixed bell
stops you on its schedule,
not the work's,
and for the hard problems
it tends to ring
just as the loading finishes.
So you pay the setup cost
over and over
and rarely get to spend
what you paid for.
Keep the timer.
Change what it means.
Treat it as a floor,
not a ceiling.
When it rings,
you are allowed to stop.
You are not required to.
If you are still circling,
take the break.
You have earned it,
and walking away
might loosen the knot.
If you are in the middle of it,
keep going
and stop at a natural edge.
A test that passes.
The end of a function.
The moment you have written down
the next step.
Take the break there,
where the state you lose
is state you have already saved.
Use the fixed timer
for the shallow work too,
email, reviews, tidying,
where there is little to load
and the bell does no harm.
And if you notice
you keep ignoring the bell
for three hours straight,
that is a different problem,
and your body will tell you about it.
The timer was there
to get you in.
Do not let it
throw you out.
– Serguey Asael Shinder
Top comments (0)