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?

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

3

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...
–
eflatFeb 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...
–
DarenWSep 20 '12 at 0:00

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.
–
weronikaAug 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 WijsmanAug 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.
–
weronikaAug 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 WijsmanAug 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.
–
weronikaAug 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.

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.
–
RualStorgeDec 24 '14 at 19:11

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.

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.

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.

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

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 WijsmanAug 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.
–
tobySep 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.
–
weronikaSep 1 '11 at 4:13

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

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.

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.

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.

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

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

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

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.

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.