What do you do during a build?

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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)

edit:

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.

Answer 9

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.

Answer 10

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?

Answer 11

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.

Answer 12

StackOverflow! :)

Answer 13

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.

Answer 14

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?

Answer 15

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

Answer 16

Read Dilbert!!

www.dilbert.com

Answer 17

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.

Answer 18

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.

Answer 19

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

Answer 20

Sleep. at is a wonderful thing...

Answer 21

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

Answer 22

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.

Answer 23

I've been checking Stackoverflow...

Answer 24

look for another job