Ask HN: How to use small chunks of time productively | Hacker News Reader

Ask HN: How to use small chunks of time productively

109 pointsAndrewKemendo55 comments

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.

Due to many different unforeseen circumstances, I can'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.

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/sleep hours are enforced and that the job is as a Product Manager.

View on HN

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

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.

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

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

slack's search may also come in very useful if you want to pull up an older solution or re-read your notes

If you send yourself more than 10k messages, you'll have to pay for slack if you want to search. Grep is free.

Or use org-mode?

And this is the basis of any other lock-free algorithm also (it'll make it easier to hand-off, delegate tasks, let others finish what you started, ...)

Nice analogy. Trello is my "journal".

I do this very thing on a legal pad, except before "get the unit tests to pass", I add a box that I can check off because checking boxes makes me feel nice.

One advantage of physical paper for the journal is that it doesn't take up screen real-estate or require switching tabs to enter into it. Another advantage is that I don't have to clear it out when I get done with a task. I just turn the page.

Physically writing something also does _things_ in your brain that typing on screens doesn't.

I've noticed that moving things around to different parts of your brain helps cognitive functions.

One example of this is rubber ducking [0]; the act of moving a problem from the part of your brain that you use to think about it, out through the part you use to serialize sentences to another person, helps in problem solving.

[0] http://c2.com/cgi/wiki?RubberDucking

I have found this works often in my day to day life. I will be get struck at one thing and when I about to drop a mail, and I write the detail explanation about the problem, I get the answer.

Nice to know this is called as "Rubber Ducking"

This works for me, I used to have a file I would create with 'to do', 'doing', and 'done' values on each of the steps. But someone here on HN pointed out that I could use Trello for that which I tried, and it was absolutely the best for this. Make a board,, think of the top few things that have to be done, pick one, move it over to 'doing' it will spawn a few more things, start picking them off one by one. And putting them into the done column.

To whomever suggested that, I owe you a beer or something :-)

Asana is my tool for doing this. Easy to get back on track, when i have clearly defined tasks.

I guess that is the skill you should develop, to write clearly defined and small tasks, then it solves it self.

Some days, I do this. I never related it to journaling, thanks for that!

The days I do it are really more productive. It is easier to acomplish tasks this way.

I use just a new tab in Sublime Text. I maintain this tab for several days. I never save this file.

I might try this in an Evernote notebook! Thanks!

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.

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.

This one is one I have been doing and I have found that I end up getting distracted between segments. I think it's a good approach though and seems to be the most effective so far - it really helps "knock down" targets.

You could use tmux and script it. This way, you would not actually have workspaces open, but instead reduced startup time.

> sometimes it's reading a technical article I've kept open for a while

I am glad, that I am not the only one. The angel an my left shoulder tells me to read it, but the devil on the right says that this would be work and I could as well write a comment like this and close the HN tab, which will feel just as rewarding.

Any recommendations for software to manage workspaces on OS X?

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

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

It's not OS X specific, but Tmux and Tmuxinator have done wonders for my productivity.

And on Windows?

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.

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.

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.

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).

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.

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.

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.

This is pretty much what I do. I decide that on a given day I will move my project forward somehow, with whatever amount of time I have. What I actually do depends on how much time there is. It might be outlining a blog post, researching a technology, market research, or actual code.

One important thing I've learned over the years is that, at least for me, Flow is overrated. You can do an awful lot with little, fragmented bits of time. I used to absolutely hate interruptions, but once I resigned myself to them happening, I became much more productive.

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.

> 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.

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.

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.

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.

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.

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

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

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.

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.

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.

Yea, good approach. For some things though it's hard to estimate how long they will take so they end up just getting pushed to the back.

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

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 - 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.

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.

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.

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?

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.

"... 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.

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.

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.

Relax.

Reply on news.ycombinator.com