At the moment I'm working on a project that has a lot of downtime. It takes 10 minutes to load the development environment, builds can take half an hour, loading the application for debugging sometimes takes 15 minutes. I would like to know what sort of productive work (besides contributing to StackOverflow) people do during these times when no "real" work can feasibly be done. I usually find that any sort of work I do during these times takes my mind off the task at hand and it takes me a while to get back on track after the wait is over, which means that I might have been better off just twiddling my thumbs while waiting.

Sorry if this question is a bit too subjective, but it is my main problem where I work. And I do know that these time sinks should ideally be eliminated, but there will always be some sort of downtime to contend with.

+29  A: 
relax homie, life's short.
It's just one picture. If someone has already lost focus so that they can't scroll down, they have bigger problems. :p (besides, it's obligatory)
He, nice one. The problem is, its not just this question, i see it all over. And it just promotes more of the same. Sorry if it seems like i was targetting this one in particular. Yes it is hilarious. But this was also posted on another topic explicitly asking about funny cartoons.
But does it really detract from the question?
No not this question in partiular. You are missing my point. You let a kid steal a cookie from the cookie jar once, and might do it again. If every applauds and cheers and gives him the thimbs up, he will definately do it agian
That was not predictable at all :-p
Tim Sally
I'd have to say this cartoon fits the question PERFECTLY... if we can't accept a little humor in some responses, what the hell is wrong with us? I know I have the ability to scroll past it and see real answers... surely others do too?
Mike Stone
perfectly? "I would like to know what sort of productive work...". I see. Myabe not. I agree there is humour in it and we need that sometimes. But this is just silly when others actually post useful stuff, other post usefull questions that get closed, theres no rhyme or reason here it seems. Bravo!
Let us not go to StackOverflow. 'Tis a silly place.
here is another perfect example of what happens:
It's just a joke. He even said as much! Lighten up.
+1  A: 

Hanging out on Stack Overflow?

Seriously, I had this problem 8 years ago while still developing in C++. Switching to .NET mostly fixes it. Switching to Python eliminates it completely.

Alexander Kojevnikov
Basically any language that isn't C++. :p
+11  A: 

My most productive use of this time is writing unit tests, since that helps me stay focused on the task in hand.

Often though it ends up task switching for something else (email, support requests, etc) which leads to expensive brain context switching penalties (like forgetting why I started the build in the first place).

Rob Walker
+15  A: 

I really don't mean this to be sarcastic but my answer is look for ways to speed the build. I've been on a project like that before and in our case it didnt seem like it should have taken as long as it did. Its possible your rebuilding the entire linux kernal or some other massive piece of code but id look at improvements so you dont have to worry about it as much.

Once C++ projects (I'm guessing that's what the OP is working with) get to a certain size, build times will get long to some degree. I agree that there are ways of speeding things up though.
This happens with .NET projects as well. I once worked at a C# project that was over 2 million LOC. The solution was enormous and had a lot of projects. The compile took about 45 minutes.
+4  A: 

The build process runs on a separate machine dedicated to doing builds. The build process tags the SVN trunk and builds off that tag. Most of the time I'm not even aware a build is in progress. I just keep working.

Maybe you need a better build process?

+4  A: 

Anything short:

  • clean spam out of the ticket queue, or your inbox
  • make a cup of tea
  • go to the bathroom
  • update your todo list
  • snipe quick actions off of your todo list

Longer things are also possible if you get in the habit of setting a reminder popup. even just

echo "^G^G^G^G^G" | at now + 5min

can be enough to jar you into remembering to get back to what you were doing.


I've had similar situations. When that is the case, I usually just only build the small portion I am working on. Usually you don't need to do a full build except maybe once every week or so... instead, just run the test cases that directly affect you, and build the portions you are modifying directly.

Let the continuous build server notify you if you check something in that breaks either the build or the tests (or if you prefer, run it just before checking in).

The key is to eliminate the downtime, not fill the gaps.

Mike Stone
+4  A: 

More answers can be found here: SO: How to keep concentrated and focused while waiting for the compiler

+1  A: 

In the case where builds have taken around 15-30 minutes, I learned to get things "mostly finished", and then I'd start the build. While it was building, I'd work on finishing things up. It actually takes conscious effort to change your workflow to this method when you're used to finishing things completely and then building.

(but usually I take building as a time to take a break and work on different design issues or answer e-mail or socialize or build toys out of common office supplies)


I wanted to add that my first work project took 25 minutes to build on my PC. I recorded in a spreadsheet how much downtime I spent waiting for it to complete and used it as justification for a new PC. The build took 5 minutes after I managed to get the company to upgrade me from that dinosaur.


Slashdot, stack-overflow, coffee, restrooms, hangout with your teammates, read/answer emails (good if you have two screens and you know immediately when the build breaks!!) Obviously as other says always strive for making your build faster.

+29  A: 

The best answer is to slack-off.

But if you find you would rather be productive, consider fixing the problem of slow load and build times...

From the book The 7 Habits of Highly Effective People:

Suppose you came upon someone in the woods working to saw down a tree. They are exhausted from working for hours. You suggest they take a break to sharpen the saw. They might reply, " I didn't have time to sharpen the saw, I'm busy sawing!"

You might also want to try to divide up your project in a better manner.
For example: do you really need to load and build everything?

Brian R. Bondy
+1  A: 

One thing you may want to do is write test cases to run while your gone. See how much of your code is being executed with a coverage test. Maybe run a benchmark to find that elusive 10% that needs to be optimized.

For me test cases help me see junior level mistakes that I might have over looked while rushing to make the software.

+3  A: 

StackOverflow! :)

+4  A: 

Instead of trying to fill your downtime with other minutia, my best suggestion would be to ask your supervisor/boss to investigate the costs associated with buying a dedicated build machine, or even a small network of build machines depending on the size of your development team.

Given what you've stated, the cost of your downtime (and the downtime of others) far eclipses the money that the hardware + initial setup will cost.


Get a pet for the office. A slug or a snake typically works well. Though some people may start to wonder why there are frozen dead baby mice in the freezer all of a sudden (in the case of the snake). I'm pretty sure slugs like donuts -- who doesn't?

+1  A: 

Depending on whose commit kicked the build off, I pray that it doesn't break.

"Pray" was going to be my answer, just to be funny. You beat me to it.
David Hill

Read Dilbert!!

Decio Lira
+1  A: 

It sounds like your build cycle does not have correctly dependency analysis. Consult your build system to see if this is possible. For example, Ant has the <depend> task, which does an OK job of compiling only what's needed. For me, a clean build takes about 5 minutes, but the code/debug/deploy cycle can be done in under 1, due to proper dependency handling.


Time for a shameless plug: Since we use Delphi, our 600,000 line project builds in 15 seconds without any unusually powerful hardware. Nanny-nanny boo-boo.

On a serious note, if I have unavoidable downtime, I usually spend it reading a blog post that is vaguely related to programming. Steve Yegge or Paul Graham come to mind.


I have a dart board next to my office. I'll typically snag another developer and play a game of drives the PMs mad. :)

Coder Blues

Sleep. at is a wonderful thing...

Jason Mock
+3  A: 

Write documentation about the app - I'm sure that's being saved for the end of the project (if it's even in the schedule!).

  • Explain how the app works.
  • What are its dependencies?
  • How do you troubleshoot it?
  • What were the design decisions?
  • What are the outstanding issues?
  • What's the future roadmap?

You get the idea....


I enjoy picking up a different project on a different, nearby computer. I recently purchased a Mac. When my PC is building, I am writing something in Xcode.

Luther Baker

I've been checking Stackoverflow...

Robert Gould

look for another job