Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

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?

See:

share|improve this question
17  
xkcd.com/303 - not useful, but related –  michaelc Aug 21 '11 at 6:04
6  
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
1  
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...... –  naxa May 22 '13 at 13:43

12 Answers 12

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

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

Fight with swords while riding on chairs.

Compiling

'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
2  
Equally unproductive: check for new questions on Stack Overflow. –  Andrew Grimm Nov 17 '11 at 10:15

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

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
1  
Or get a faster computer! –  toby Sep 1 '11 at 1:51

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

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

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 stackoverflow.com!
  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

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 750words.com. 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

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

Your Answer

 
discard

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.