Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Reading about producitivity lately, it seems that multi-tasking is a bad strategy* (and I certainly feel that it contributes to stress), but I'm not sure how to avoid it when working on legacy software that takes tens of minutes to compile.

What strategies can I use to avoid the overhead of task switching, without just sitting and watching my code compile?

I've tried doing small tasks (cleaning my desk, checking e-mail), but I go through tens of edit/compile cycles on this project per day, so quickly run out of trivial tasks to complete.

Alternatively, what are some strategies for managing context switches without burning out?


share|improve this question
What language are you working with? I'm just curious if it is a modern one where something can be done or if really has to take 10 minutes to compile. – Jeanne Boyarsky Aug 21 '11 at 23:54
How about document the time spent waiting to compile, do a little match on it and see if you can use it to justify a faster machine (including an ssd drive) to you manager... – eflat Feb 14 '12 at 0:12
I have switched from using C++ to D, Ada, and various other languages, where using a compiled language matters. Now I never have this question of what to do while waiting. No more a few minutes of fun... – DarenW Sep 20 '12 at 0:00
+1 for saving up for an SSD...... – n611x007 May 22 '13 at 13:43
I wish it took only 10 minutes to compile and link in my work environment. – Arlie Stephens Apr 28 at 0:01

16 Answers 16

Multi-tasking is deemed bad; so indeed, stay coding...

  • Figure out how to make your code compile faster, a very interesting thing to look into.

  • Figure out how to need less edit/complie cycles; defensive programming can help you avoid bugs.

  • Use Test Driven Development, so that you need to compile the tests rather than the whole product.

  • Think about the next thing you have to code.

Surely, this should provide you a way to decrease context switches as well as to code more efficiently.

share|improve this answer
This is probably an individual difference, but for me multitasking by quickly switching between multiple aspects/tasks in the same project is precisely the easiest way to get myself confused and unproductive. – weronika Aug 23 '11 at 2:07
@weronika: Multi-taksing usually refers to switching context, which does not take place here. Consider the gain/loss of my suggestions, I doubt if making your code compilation take 10 minutes less than it usually does would make you confused and less productive. As well as doing anything to avoid compilation while at the same time you apply tests and defensive programming. It can't get much better than that... – Tom Wijsman Aug 27 '11 at 0:49
It feels like context-switching to me - even within one project there are usually different "contexts", since I can't keep the entire thing in working memory at once. I definitely agree that all the things you mentioned are worth doing, but they might be worth spending a few continuous hours on instead of going back and forth in ten-minute pieces. – weronika Aug 27 '11 at 6:34
@weronika: No, those are called tasks; the context that they are in is the project. Multi-tasking is amongst different contexts (hence projcets), not amongst different tasks. Of course switching tasks need you to swap your working memory a bit, but not as intensive as switching context. My view was that the OP has 30 - 60 minute compilation times, in which (according to Pomodoro Technique) you can spent 1 - 2 Pomodoro on the things I mentioned. Of course, for shorter periods I agree that it's more wise to schedule it away (perhaps look into it at home) and use 1 Pomodoro to implement. – Tom Wijsman Aug 27 '11 at 13:02
Oww, that's some confusing terminology! ;) So "multitasking" doesn't refer to "tasks"? Ah well. In any case, you're right, those things are doable in a 60-minute chunk - that's very different than the 10-20 minute ones I was thinking of for some reason. – weronika Aug 27 '11 at 17:32

I'm not a software developer so hopefully this question isn't totally ignorant, but if you're doing tens of edit/compile cycles a day and each compile cycle takes 10 minutes, then it seems like a good use of that time would be using it to work on shortening the compile cycle.

You're talking about an hour of unproductive work a day--an hour I can see you not being able to fill day-after-day. Channeling that time into streamlining your compile process seems like it would pay of handsomely, and more if you're not the only developer with this issue.

In the case that the compile time is limited by some sort of hardware restriction you don't have the power to improve on your own (e.g. scripts and other type of automation can't solve the compile time problem for you), then I'd gather the data on "wasted" time and take it along with an accounting of what you need to the person who has the authority to help you and make your case.

share|improve this answer
I am a software developer. Your answer is exactly what I would do. The only thing I see missing is to refactor the project into smaller ones/components so you don't have to compile the whole thing so often. – Jeanne Boyarsky Aug 21 '11 at 23:54
Many processes developers deal with can be time consuming, slow, and repetitive. Compiling, Checking in / merging code, publishing changes, etc. When ever you hit a bottle neck with any of these or time in general scraping even 20 - 30 seconds off a process can save incredible amounts of time in the long haul. – RualStorge Dec 24 '14 at 19:11

Fight with swords while riding on chairs.


'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.'

share|improve this answer
And now (I wish I could find that cartoon again) the new excuse is Map Reduce :-) – ℝaphink Aug 22 '11 at 5:13
Equally unproductive: check for new questions on Stack Overflow. – Andrew Grimm Nov 17 '11 at 10:15

Decompress while it's compiling. Your right brain will continue to work on coding. Don't do something else productive. Watch some semi-lame movie that's barely enough to keep your interest. Read your rss feeder desultorily. Capture ideas and todo items that pop into your head during this time. A 10 minute break is nothing. Work out a little, stretch, walk around, whatever.

Doing minor organization like you mentioned is not a bad idea either.

share|improve this answer
It's the new workout plan. Compiling to 5k. – Jemmeh Oct 15 '15 at 15:52

Very good question! I would like to add a suggestion that can easily be combined with all other sugegstion already given: optimize your computer! When I look at my computer while compiling, most of the time the CPU is not working as hard as you'd expect. Most of the time it's just waiting on the harddrive. Optimizing the hard drive can be done by creating several partitions: one for your source code, one for the object code, and one for all other things. This keeps the harddrive from becoming fragmented quickly. You'd be amazed by the performance gains. Another option is to replace the hard drive by a solid state drive.

Also, what kind of versioning system do you use? I have learned that subversion, and especially the tortoise tools cause enormous cpu and disk usage.

share|improve this answer
Or get a faster computer! – toby Sep 1 '11 at 1:51

Something that I do at times is to work on two things: Work on project A until I reach the point where I need to compile/ask someone a question/something else that blocks my progress thread. So, I kick off that thread, and switch to project B and do the same thing. Typically the blocked thread will have cleared by the time I block on project B. It doesn't do away with the task-switching overhead, but at least my segments of time are decided by project realities, rather than some "optimum" length of time.

But then, I'm also looking at the pomodoro technique, so all of what I said might be completely invalidated as time passes.

share|improve this answer
Reminds me of the "cooperative multitasking" of old time Microsoft Windows vs. modern systems that give processes time slices. The latter has worked better for operating systems, but for Humans it's better to switch at natural break points. – DarenW Sep 20 '12 at 0:06

I find that doing simple, easily interruptible, and absolutely non-work-related things, usually online (skimming the news, looking for interesting stackoverflow questions but not actually reading them in detail, social sites), makes returning to the original task much easier than if I try to work on another project or even a different part of the same project in the meantime.

I know it seems like a waste of time, but I haven't found anything better. Trying to spend that time on work so I'd feel like I wasn't wasting it would just make me less productive overall.

Of course, getting up to stretch a bit, rest your eyes and have a drink of water is great too, if you're not doing it every fifteen minutes.

(Note: this answer applies if your breaks are on the 10-20 minute timescale - if they're longer, doing something more involved is probably a good idea, see other answers.)

share|improve this answer
Ignorance by distraction is bad; the compiler has a big impact on your overall productivity. It forces you to do non-work-related things and taking more regular pauses than would be necessary, that context switching induces a "bottleneck" and that's the reason why it feels like a waste of time. Teach the compiler a lesson... – Tom Wijsman Aug 27 '11 at 0:58
Very bad idea. It's very easy to get completely side tracked and find that you did nothing for the entire day. – toby Sep 1 '11 at 1:51
Personal differences, probably. For me those kids of things are something I'll never do for very long, so they make better "filler activities" than something I might get really absorbed in. – weronika Sep 1 '11 at 4:13
"Marty Lobdell - Study Less Study Smart" is a good video to watch, it puts emphasis taking breaks. I've done it for years, it works great. But I think a break as long as 10-20 minutes is too long, especially at a point where you're not trying to get unstuck from a problem(which is when breaks are great), but just waiting. While I'm a big supporter of short breaks for productivity, I don't think in this case it's the most efficient thing to do. – Jemmeh Oct 15 '15 at 16:18

In my opinion, you need the compile process to be under half a minute at least. Some ways to achieve this:

  1. Use an interpreted language. Interpreted languages(Python, Ruby, Perl, etc) don't require compilation, so you've just reduced compile time to zero. It might be hard/impractical to throw away your existing codebase, but you can incorporate an interpreted language on top of your existing code base - this is not uncommon practice and has been done with great success.
  2. Buy or build an extremely fast machine. See Jeff Atwood's building a PC series
  3. Break up the build into small modules, compile and test them individually, as Tom stated in his answer. By making your app more modular you should get a faster build time on average because most times you'd only be rebuilding part of the app.
share|improve this answer

Push-ups :) The longer it compiles, more push-ups you do. You then get motivated to code it so that it compiles faster. If you can't shorten compile time, you become stronger physically.

share|improve this answer

This is an older question, but I thought I'd give my 2 cents:

  1. Write some unit tests to perform e.g. in a spreadsheet, write a list of things you want to test for this software
  2. Lookup / Answer related questions on Stack Exchange
  3. Set appointments in your calendar for other things you are thinking about - that way you can clear your head and focus on the task at hand
share|improve this answer

Do planning: think about what you are going to do after the compilation finishes.

  • Jot down some plans for your next steps.

Pen-and-paper is best for sketching short-hand ideas. I also write in a Campfire chatroom or on Putting things into words helps to clarify them.

  • Update your task on the issue tracker: progress, clarify description, chosen approach.

  • Take a walk around and let your brain mull over what you're working on in peace.

Don't check email or news or social media, don't start work on something else. They start you thinking about other things, leading to a major context switch to get back into the task after the compile finishes, and they can turn into a lot more time than just a compile.

share|improve this answer


Your biggest risk is losing focus or flow if you start swordfighting. Meditation not only helps you maintain focus, but it helps defragment other things floating around in your head.

It's not hard. Sit in a relaxed position. Breathe in. Hold your breath. Breathe out. You'll have a bunch of random thoughts come and go. You can jot those down on let them go past and ignore them.

Another alternative is doing some design related to work. Make flowcharts or wireframes on paper.

share|improve this answer

I am a newbie programmer and have had similar situation compiling modules for GNOME Desktop project. These things worked for me:

  1. Setting up a audible notification for when the compilation finishes but being within earshot to notice this.

  2. Moving away from desk because I would know when compilation has finished and doing something physical such as watering plants or doing the dishes.

  3. When I was in a short compilation time frame, I would turn away from the computer and write a note to self on what I felt about work so far or where I am stuck. Just writing down my current thoughts on paper gave much clarity on what I wanted to next.

Hope this helps!

share|improve this answer

Here's something I just came up with myself, but it is highly dependent on the way your dev team operates:

  1. If your team practices doing code reviews independently, check for any pending code reviews, and review them. You don't have to finish the review entirely and stepping away from that code and going back to it intermittently might actually help you spot new things you never noticed before.
  2. If your team is using any project management software you can check or update the status of your tickets (your PM will be proud)

The first point is very useful but only if your team doesn't do in-person reviews. As mentioned by someone else I've also found TDD to be very useful to keep cycle times down.

share|improve this answer

I experienced doing parallel jobs which are totally different is the only thing you can do while compiling or more generally while an application is eating a good slice of you CPU.

For example try these, in parallel to slow app:

  1. Wokring on another app UI sketch, on paper.
  2. Checking facebook
  3. Check!
  4. Thinking on marketing your app, checking new articles on marketing and finding out iOS is much more money market than Android, still!

But don't try reading stories, novels or blogs, because they will attract you and you will come back minutes after END OF COMPILE.

share|improve this answer

I would highly recommend standing up and taking a break for some sort of (even slightly) physical activity. This can be as simple as taking a walk around your building. This will not only reduce and soften the potentially negative physical side effects of sitting at a desk all day, but it will also allow your brain to decompress. Your subconscious mind will have a chance to sort things out without being impeded by your conscious thought processes. This will keep you from feeling "brain-dead" at the end of the day, and your mental stamina will increase over time.

share|improve this answer
This is already suggested in one form or another in other answers. – Jan Doggen Dec 24 '14 at 8:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.