
Ask HN: How to use small chunks of time productively - AndrewKemendo
We all know about Flow and how long of uninterrupted periods one needs to get into it. I am wondering about how to take advantage of the opposite of those long periods.<p>Due to many different unforeseen circumstances, I can&#x27;t get more than about 20-30 uninterrupted minutes at a time throughout the day from 7am-8PM. I am sure I am not alone in this.<p>All of the tricks of the trade (email once a day, phone off during set periods, scheduled alone time etc...) are not possible for the foreseeable future. I am wondering if anyone has any good ideas for how to be productive in those short windows. Assume that standard work&#x2F;sleep hours are enforced and that the job is as a Product Manager.
======
drewcrawford
The best algorithm for interruptions I know is the one that computers use: the
journaling filesystem [0].

The way it works is simple. When you want to do a disk operation, first, you
write down in a special place (called a _journal_ ) what you are going to do,
at a high level. "I'm going to delete this directory and all its files." Then,
you go through the steps of actually doing that. Finally, you record in your
journal that's what you did.

Now when power is interrupted during a disk operation you simply look at the
journal and you can complete any operations that were in-flight at the time of
the interruption. For example if the journal says "Delete X folder" and you
see it still exists, now you can pick up where you left off.

The application to interruptible programming is straightforward. I have an
actual paper journal and I will in a few words explain a task to the journal
before I begin. Often I end up with a hierarchical journal, like

    
    
        get the unit tests to pass
            the unit test doesn't pass on OSX because postgres isn't running
                start postgres
            the unit test doesn't pass on Linux because the postgres credentials are wrong
                refactor postgres credentials to work right on both platforms
            one particular Linux machine still doesn't work
                Is it 32-bit related?
                    No
                Are we using the same compiler on that machine?
    

The overhead of recording this information is microscopic, and the benefit of
returning from every interruption to a page or so of context is awesome. It's
almost better to be interrupted now, because I come back to a clearly defined
problem, as opposed to starting on "blank slate" items with no direction.

As a side benefit, I now write really good commit messages, because I just
write what my journal says I did. Which is quite a lot more detail than it was
when I was trying to remember things after the fact.

[0]
[http://en.wikipedia.org/wiki/Journaling_file_system](http://en.wikipedia.org/wiki/Journaling_file_system)

~~~
gee_totes
If you want to use a journaling system digitally, I would suggest starting a
slack chatroom for just yourself. It's designed for teams, but using the
simple chatroom interface for just yourself works surprisingly well.

~~~
unclesaamm
I realize this might have some merit as a life tip, but it also sounds
hilariously lonely

~~~
dwc
It can also work digitally with a text file, which may feel less lonely.

------
japhyr
My kid will turn 4 this spring, so I've been dealing with fragmented time
constantly for the past few years. It's been frustrating at times because I
have tremendous mental energy, but can't get much done because I can rarely
get more than 20-30 minutes of uninterrupted time. I've done a few things to
make effective use of the time I have:

\- Learn to manage workspaces efficiently on my OS. I can't afford to open all
the files for a project and get significant work done, so I keep more projects
open at a time. I went from typically using 4 workspaces before I had a kid,
to consistently using 12 workspaces these days. It's nice to have 3-4 projects
open, spread across 2-3 workspaces each.

\- Documentation of my own projects. I keep a text file for each project, with
notes about what's been working, where I'm getting stuck, and which resources
are helpful. I've used more complicated tools at times such as issue trackers,
but simple text files with names such as _notes_ , _next_ , and _mental_dump_
still offer the least friction for recording the little notes that make it
easier to pick up wherever I end up having to leave off when I get
interrupted.

\- Recognizing my mental state, and what I can get done in any given block of
time. Sometimes that's moving a project forward, sometimes that's catching up
on HN, sometimes it's reading a technical article I've kept open for a while.
Sometimes it's recognizing I shouldn't try to get anything done, and I should
sit and stretch instead.

I find that I'm using each of these strategies in my day job as well. I've got
to go serve some porridge now, but those are a few things I've come up with.

~~~
jefftchan
Any recommendations for software to manage workspaces on OS X?

~~~
walshie4
I use the default 'spaces' along with Amethyst
([https://github.com/ianyh/Amethyst](https://github.com/ianyh/Amethyst)).
Works quite well.

~~~
afarrell
I use this as well and can confirm that it works.

------
bikamonki
I tried similar approaches to the ones commented here but in the end none
worked: delivery took longer plus quality suffered. I am not aware of your
unforeseen circumstances but for me the solution was to plan the whole week
and if I'm programming that's it, no interruptions except emergencies. I feel
fine if I lose a day or a day an a half to 'unproductive tasks' if the rest of
the week I was commiting like a maniac. I learned that 99% of emails, calls
and IMs can wait for hours and that's fine; in fact, some communications
expire if left unanswered for a few hours, no need to answer at all. After
planning for weeks I learned to plan for months. I now know that I can do one
big project every 4-6 mos and one small one ever 3-4 wks. The rest of my
recipe is discipline, which I completely lack, so every now and then I need to
reset the process. Normally the big projects are paying the bills while the
small ones are what I call R&D (product ideas). Don't let one of those 'super
good ideas' interrupt a work in progress until you've completed an MVP ready
for testing/first couple of customers. Finally: if feasible hire help.

------
bonobo3000
Essentially you want to make context switching into a task as easy as
possible. Some ways to do that are:

. Maintain a list of tasks you can work on, and make it good enough that you
can blindly pick one up and start working after a switch.

. Saving context via documentation/text/workspaces as japhyr mentioned helps
me a lot. Whenever i come across an issue that i cant handle at that time, i
throw it in a text file. At the end of a session, i organize the list. When i
come back to task X, i just look at the list and start working on it. Just
going through the list, seeing what I did and what remains is the fastest way
ive found to warm up and get back in the flow of a project.

. Optimize your workflow. With a tiny chunk of time like this, 5 minutes
setting up a workspace or even re-reading an article is too much. So save as
much of the workspace as possible, take notes on how article X applies to your
project.

------
palesz
For me what works the best: Start early in the morning, before the sun and
everyone else rises, this will give ~2 hours of time in a single block, the
rest of the day is there just for interruptions and small tasks.

~~~
beebs93
Agreed.

I work out every morning Mon-Fri then I'm at my desk a good 45-60min before
everyone else arrives.

I'm more productive during my "silent endorphin" rushes than any other time of
day.

As soon as I hear the first person arrive, I toss my noise-cancelling
headphones on, crank some white noise, set my IM status to "Busy" and then go
for as long as I can before someone interrupts me. (usually ~30-60min).

------
mooreds
Focus and timeboxing are your new best buddies.

I would keep a task list of short tasks. Use a spreadsheet or text file.

If you come up with something else to explore that you'd typically dive into,
don't. Instead, just record it on a separate part of your task list for future
investigation.

Realize that you can do a lot with 5 or 10 30 minute segments, especially if
you focus on the right tasks.

Set a timer, if possible, and take the last 3 minutes to leave yourself some
context (in the bug tracker if you are fixing a bug, at the end of a document
if you are writing something, etc).

Put on headphones for the 20-30 minutes you do have.

Postpone any really deep thinking until after 8.

~~~
dwc
I did this, or close enough. I fastidiously added lots of small tasks, and any
time I had a few minutes, or a half hour, I would scan through and find
something doable and check it off. I got a LOT of stuff done. I also added the
larger things, so I could keep track.

The only downside is that there were larger things that I couldn't break up
into smaller things without getting deeper into it. It was too easy for me to
put those off (because I didn't have a solid block of time) and just complete
several smaller items. The large items started to pile up, to my detriment.

I'm not trying to say there aren't ways to deal with this. There are. I was
still exploring such ways when I recently took a job where I once again have
decent blocks of uninterrupted time in a quiet environment.

~~~
mooreds
Yes, finding time to work on large items that require uninterrupted thought
would be tough given OP's parameters. If we had more context, might be easier
to offer useful suggestions.

------
Mz
One thing you can do is make your peace with the fact that it will take a
couple of minutes or so to refocus. So assume that three 30 minute blocks of
time are worth at least six minutes less than an uninterrupted 90 minute block
of time. Yes, that's frustrating, but may not be as huge a loss as you think:
You can still get about 84 minutes worth of work done. It adds up over time.
Also, if those 30 minute blocks are in quick succession, it will take even
less time to get back in the groove than if there are large interruptions that
make you completely lose your train of thought and, thus, require you to
reread things and so on in order to figure out where you were.

While I am on that topic, one way to be more productive when your focus is
broken up is to find ways to track where you left off. If you do a lot of
reading of dead leaf materials, book darts can mark the exact line you were on
when you stopped, which can prevent you from scanning two pages to find where
you were. Online, leaving things open at the place on the page you last
scrolled to and similar. I try to open tabs I need to do something with later
even if I can't get to it just yet so I will, at some point, check that tab
and go "Oh, yeah. I need to do that thing." Otherwise, I may completely forget
about doing that thing at all on that day. It may get ignored until the next
day -- or the day after or whatever.

I also found it helpful at BigCo to make a spreadsheet and track certain
things. Creating the spreadsheet took just a few minutes, updating it took a
few seconds here and a few seconds there. The amount of stress and distraction
from worry it saved me was worth many times the amount of time sunk into
creating a simple tracking mechanism.

~~~
bachmeier
> One thing you can do is make your peace with the fact that it will take a
> couple of minutes or so to refocus.

This is very important. It takes me three minutes to adjust after an
interruption. I sit in my chair with my eyes closed to avoid distractions.
Even if I make notes, I have to process the interruption and then shift to the
previous task. It really helps to work on a big project so that you can ask,
"Where was I?" and get back into it.

------
redmattred
Ruthlessly prioritize and learn to say no. As a PM, it's very easy to have
your time eaten up by unimportant but seemingly urgent activities. Keep and
prioritize a backlog not just for your team, but for yourself as well.

------
zackmorris
One thing that works for me is the beer test. If the task is something that
you could do after having one beer, then it won't present a problem if you do
it while getting constantly interrupted. Multitasking debilitates focused
concentration at least as much as intoxication, which is why most people can't
text while driving etc.

If you find that the entirety of your to-do list is made up of things that
couldn’t be done after a beer, then you are going to be unproductive in your
work environment. Focus on eliminating the interruption. You may have to hack
together a solution that people who don’t spend long periods deep in thought
will understand.

For example, wearing earbuds even if no music is playing, randomly shutting
your door, making an emergency script that opens MS Excel when someone walks
in so it looks like you were working rather than wandering Wikipedia so your
subconscious mind could solve a problem, writing a description of something
you are working on at the same time every day on your office calendar so that
people will subconsciously not bother you during that time, and speaking at
half speed when people ask you a question so that they jump to conclusions
about what you might be thinking and reprimand themselves for not being more
prepared before they come to you.

Basically it comes down to the liberal use of improvisation of your work
environment isn’t structured in a rational or logical way. I faced the same
problem at a tech support job I had that demanded 3-8 computer repairs a day
but didn’t delegate phone or front desk support to employees on a rotating
schedule. The level of stress was at least 3 times higher than it needed to
be, which is why I inevitably burned out and quit.

------
samatman
Following good code practices makes this easier. First chunk, write a few
paragraphs about the purpose of a module. Second chunk, mock out a few
functions with control flow and prints. Third chunk, write some input and a
test, fourth chunk, implement the top function, and so on.

Each piece leads to the next, and passes on the context needed to get back on
task. Which is exactly what we should be doing anyway.

------
garysieling
I make lists of things that need to be done during the day when I start -
usually 3-10 things, and a list of things that might be deferred, which makes
it easier to make sure I return to the right things when I get interrupted.

If someone comes to talk to me, I write down any actions that come out of the
conversation immediately, so I don't lose track of them, and try not to
promise to resolve them immediately - that adds to the above list, so things
naturally rotate in and out over time.

I like to take half hour walks to think - that helps ensure that I'm really
working on the right things on a longer timescale, even though I get
distracted on details at times.

With code, interruptions have forced me to think in terms of breaking work up
into small, atomic commits. It makes it harder to do larger design/refactoring
exercises, but it forces you to get better at splitting work up.

With smaller tasks, I tend to make a lot of tickets to track what needs to be
done over larger timespans, which conveniently makes it easier to delegate.

------
jcrites
I'd recommend investigating and trying the Pomodoro Technique. I shared a bit
more about it in another comment [2]. Ebook describing how it works [1].

It's a mental framework to help a person drive their interruptions to zero, in
order to work with full concentration on a single task; and to take full
advantage of blocks of time as small as 30 minutes. It's especially helpful
for combating internal distractions, such as a tendency to spontaneously or
unconsciously switch away from work to web browsing or email. It helps one
become consciously aware of such interruptions and their impact on effective
time worked.

[1]
[http://baomee.info/pdf/technique/1.pdf](http://baomee.info/pdf/technique/1.pdf)

[2]
[https://news.ycombinator.com/item?id=8804552](https://news.ycombinator.com/item?id=8804552)

------
franzpeterfolz
Don't start working on things you can't finish! Seriously. If tools are
missing or requirements are not well defined or other people you depend on
have not delivered now, than simply don't start.

This approach can reduce your work in progress tremendously. The benefit is,
that it becomes easier to choose from your open tasks.

When everything you need for your work is ready, you can finish your tasks.
Otherwise you start working and interrupt yourself because you have to wait
for others.

Making assumptions on not not well defined requirements may lead you to work
which will be discarded upon wrong assumptions.

And last but not least:

Work on things that matter.

Follow those things and I promise you that the disruptions will disapear.

------
pa5tabear
Keep different lists for tasks requiring different levels of focus and/or
prep.

My job has a mix of rote work and analytical work so I try to switch between
them to maximize my focused time without fatiguing too much.

------
spooneybarger
When I have days (sometimes weeks) like that, I figure out everything I need
to get done that can be done in 20-30 minute chunks (or broken down into them)
then only work on those things.

~~~
maemre
Reminded me the Pomodoro technique[1]. The only difference is, you also add
extra things on bottom of the list. I tried it but couldn't effectively apply
it, I'm better with long, uninterrupted chunks of work and prefer nighttime
for it, but YMMV.

[1]:
[https://en.wikipedia.org/wiki/Pomodoro_Technique](https://en.wikipedia.org/wiki/Pomodoro_Technique)

~~~
jcrites
I saw the post title and instantly thought of the Pomodoro Technique. A free
ebook is available describing the technique in more detail (linked as a source
from Wikipedia):
[http://baomee.info/pdf/technique/1.pdf](http://baomee.info/pdf/technique/1.pdf)
\- a bit more detail for others who are interested:

The goal of this technique is to drive interruptions to zero - during solo
(IC) work. It's one of the best techniques I've learned for improving focus
and squeezing the maximum value out of each minute.

How it works: set a timer for 25 minutes (a "pomodoro"), and then work without
any interruption on your project. If you get interrupted for any reason,
cancel the timer and start over. When the 25 minutes is up, optionally take a
5 minute break (recommended) and start again. Take a note of finished and
canceled pomodoros.

Focus solely on your work, whatever it is. If you find yourself doing anything
else, cancel. Interruptions include internal interruptions, such as "I'll just
head to news.ycombinator.com or open email for a moment". Nope. If you find
yourself doing it: cancel, start over. External interruptions: "I'm in the
middle of something - can I follow up with you in <25> minutes?" (if the
conversation goes any longer than that, restart)

Some of the benefits of the system (in my opinion):

(1) Helps you become aware of distractions, so as to better combat them.

(2) Helps you have a grounded view of your own capabilities. How much focused,
productive time do you consistently have in a day? Try the Pomodoro technique
and find out.

(3) On a larger time scale, by measuring your complete and failed pomodoros
daily, helps you become aware of factors that impact your focus (sleep, etc.)

(4) Gamification can provide a minor incentive and sense of progress.

(5) The approach is especially good at taking advantage of small units of
time. When not using the system, one is tempted simply to 'waste' a block of
30 minutes leading up to a meeting, for example. When in the flow of using
Pomodoro regularly, you know that you can simply complete "one promodoro",
which is a useful unit of work. You set the timer, get to work, and forget
about the meeting until the timer "wakes you" out of flow.

I would highly recommend it - not necessarily as a system that a person would
pick up and continue to use for the rest of their life, but as a technique
that one learns and experiments with, gaining some insight in a self-discovery
process. Perhaps a person will use it on an ongoing basis, but even they you
don't, the experience will likely have been worthwhile.

The mental discipline required is similar to that needed for meditation. A lot
of folks who try out the technique are surprised at how much internal
distraction they cause themselves, just by spontaneously opening a browser,
email, phone, etc., after having worked for only a few minutes. (Anecdotes
from sharing and discussing the technique with colleagues.) Suppressing this
behavior can take practice and force-of-will like quieting your mind does
during meditation.

------
hardwaresofton
Maybe keep a list of short <30 minute tasks? It's kind of impossible to work
deeply on a subject when you know you're going to context switch 30 minutes
later. The only way to get something done in that time frame seems to just do
something that you can finish in that time frame.

~~~
chrisshroba
I have to strongly disagree with this. It is only very difficult to make
progress with a long term task under a certain set of circumstances: namely,
having no context in returning. This is because it takes time to recall where
you left off, what resources you were using, what the current subtask was that
you were working on, etc. But all these problems can be remedied by methods
mentioned by some of the other posters.

By keeping some sort of log of where you left off, you can more easily
transition back into a complex task, and make meaningful progress more
immediately.

~~~
hardwaresofton
I agree, and thought of this possibility when I said "kind of" impossible --
The problem is, if you want to do truly deep thinking on some subject, or get
into the meat of a non-trivial problem, the time that you will take to catch
back up on where you were will be a limiting factor (and one I think will be
too limiting to make substantial progress).

The more complex the task is, the more state you'll have to dump (especially
if your 30 mins was up and you did not finish a concrete step, but were rather
part-way through some sub-step), and over time, that will cut into work/think
time.

Also, I think your example actually supports my suggestion -- by dumping state
and remembering "subtasks", you're breaking up the work into small pieces,
right?

------
kephra
Shut off your phone for this half hour, leave your laptop in the office or at
home and take a walk. An other productive and healthy task one could do within
half an hour is cooking. Or just sit back and relax. You need to work !LESS!
not more.

------
bootload
_"... I am wondering if anyone has any good ideas for how to be productive in
those short windows. ..."_

Simple timer (loud). Set for 30 minutes. Work like hell.

------
dgreensp
If you're sitting down to work and your brain is telling you that you can't
get anything done in 20-30 minutes ("or, at least, nothing that constitutes
meaningful progress" to quote my brain), one of two things is happening. 1)
Your brain is totally, 100% lying through its teeth. This happens all the time
and is the basis for procrastination. 2) Your brain is tired and telling the
truth -- you don't have the mental resources to focus right now. This happens
to me after about 60-90 minutes of concentration, and it takes 20-30 minutes
of "lightening up" to recharge. (Note that these numbers are taken in the
absence of major stressors like babies and in-laws. You may also need to eat,
sleep, or perform some other kind of self-care to recharge.)

In case (1), it's fun to imagine that your brain is maliciously lying to you
about the progress you'll be able to make, but it's more ignorance than
malice. Get good at recognizing the real obstacles and talking yourself
through them. Is there some key piece of understanding you're missing, or some
design problem you couldn't solve in your head? When you have to go long
periods during your day without access to your tools, you'll build up
questions that you need the Internet, a computer, or pen and paper to answer.
Remember what they are; don't just unconsciously make assumptions or treat
these questions as unanswerable. Another mental blocker besides lack of
understanding is worrying prematurely about the properties the finished
product must have (it must be good, it must be well-written, it must look
beautiful, it must be a complete treatment of the subject, etc.). Another
blocker is stacking up tasks in your head so that one blocks another -- I
don't want to do B until I've done A, but I don't have the mental energy (or
other resource) to do A right now, but I should just force myself to, but I
can't... These blockers will dissolve once you recognize them and look at them
properly. If you feel any resistance to working on a task (whether it's a
short, 20-minute task or a longer task to make progress on), immediately ask
yourself why.

It's particularly frustrating, for example, if a 20-minute task is put in the
front of your queue, ahead of your "real work" that constitutes "real
progress." A bug pops up, or a configuration issue with your computer, or an
urgent email, or a git conflict. You thought you'd have just enough time to
implement and test feature X, which is just a one-line change, and now there's
no chance. There's not much to do about these things except to recognize them,
and to adjust your definition of "real work" and "real progress" to account
for them. If you were going to use the time to dump ideas, code, or text from
your head, dump notes into a text file for a couple minutes.

Don't get me wrong: the limits of 20-30 minute work blocks are real and not
all in your head. You can go to far-off places when you have hours to immerse
yourself in something, and in addition, just the knowledge that you have this
time seems to unlock creative thinking. However, don't believe everything you
hear about what's possible in 20-30 minute chunks either.

I'm writing about time management generically or from the point of view of a
programmer, but it depends on the nature of the task. I've never worked
closely with a PM, so I don't know what sorts of tasks we're talking about. 20
minutes sounds perfect for answering an email or two that doesn't require too
much writing. When I have to write a longer email or a design doc, blog post,
etc., I write in my head while doing other things and then dump it out, or I
dictate into a voice recorder (which is valuable for getting ideas out whether
or not I later listen to the recording).

I echo what others have said about keeping your work windows open on your
computer, and keeping a log of ideas and what you're going to do next when you
come back. Hope this helps.

------
thaumaturgy
I've had the same problem for a while -- one of the down sides to running a
business and being its sole software developer / sysadmin.

For software development specifically, you can change how you approach
programming and find that it's possible to still make progress on software in
30 minute increments.

Practice thinking about your project throughout the day. Get the "big idea"
stuff done while you're on the toilet, driving, taking a shower, getting
lunch. Keeping the project "loaded" in your head helps to predict
architectural issues, makes it easier to break the project down into smaller
pieces, makes it easier to get started coding, and keeps you motivated to work
on it.

Choose a list of small things that need to be done. Every project has them.
Don't try to get the small thing done completely right the first time. For
example, say my project needs to be able to read email headers. How should it
go about that? (Think about that throughout the day.) It will need a function
that reads a message and spits out the headers separate from the body. Write
that, that's easy. Then it'll need a function that reads each line of the
headers, and returns them as an array. Write that, that's easy. Then it'll
need another function that takes each element of the headers array and splits
them into label: value pairs. Write that, that's easy.

A nice side effect of this approach is that you end up with some very clean
code. Each function does one thing, does it well, and its output feeds
naturally into the input of the next function.

Build a library like this. If you only have 30 minutes at a time, your
personal library of code is essential. Maintain and organize it. (That's
another thing that can be done in 30 minute chunks.) Keep a notes file open in
a tab in your IDE and do regular brain dumps to it. Write unit tests, or go
back and do cleanup on a function that needs cleaning up.

Then, on a regular basis -- at least once a week, in my case -- retreat to a
coffee shop or call up a buddy you have that's a writer, and set a
"productivity day". The key is to get out of your regular environment and have
another person with you. You each end up pushing the other to focus and be
productive. Use this time to put all of your functions together, do some
testing, and build scaffolding for the "big" parts of your project. My session
about a week ago netted me almost 1,000 lines of added/deleted/modified code,
according to Github.

It's a very different approach from the usual method of "sit down and bang it
out for hours," but it works, and it helps to defeat all that mindset about
flow that other programmers struggle with.

------
jseliger
Relax.

