How do you keep focused through long compiles

Question

I find it fairly simple keep focused on a task at hand whilst I am actively engaged on it, however, during a long compile (and our current main project can compile in 5-10 mintues on a bad day) that my focus will drift.

I'll start procrastinating, check the web, talk to someone, start thinking about something else, and just generally lose my attention, and realise that the compile had finished a while back and I have lost my train of thought, or worse, a lot of time.

This is hurting my productivity, and whilst it has not been mentioned by anyone, I think it's a habit I should stop. I have tried white-noise generators (brilliant whilst I have something to focus on), shutting down my web connection and the like, however, through long compiles what can I do rather than stare at the monitor?

What tricks or tips can be used to keep focused without spending large amounts of your day starting at a compile in boredom, just to ensure you don't miss it finishing?

Hang on, my build broke 10 minutes ago ... :)

Finally, I am fairly sure this question isn't a dup of this, as as I am talking specifically about compile times, rather than waining motivation. Foosball is not an option, rather the problem :)

EDIT People trying to gloat about their language of choice compiling faster are not really helping, nor being particularly amusing. Thanks anyway.

Answer 1

I don’t. :-( We actually bought swords for the office.¹

Still, the following helps:

Immediately start some writing task. You know, that one method you wanted to write documentation for but never got around? There’s one piece of code that badly needs an explanatory comment. Work log needs updating? Now is the time.

It’s very important to find a writing task immediately, otherwise the 10 minutes delay will be too small to get anything done. To help this, I keep a list of “to do” items that is either already opened in the background or can be opened by a single command.

An alternative is littering the code base with TODO Documentation/comment tags. I do this a lot, and by and by these TODOs get replaced. I don’t know if this works for everyone but it works for me.

---

¹ Bokken, actually.

Answer 2

The biggest problem with a long compile phase is that it lengthens the amount of time in the code-test-fix cycle which breaks flow, increasing development time and decreasing your effectiveness as a developer. The best way to maintain flow in this case is to avoid compiling. To do this you can spend a little extra time before compiling to ensure that when you do compile it will be effective (e.g. waiting even 1 minute to find out you made a syntax error is a waste) and that the code you write will work the first time (because a stupid/simple logic error will cost you an extra 5-10 minutes).

To become more productive you need to alter your development process to reduce errors when it's cheap, in this case before you compile. The Personal Software Process introduces a personal inspection phase before compilation to help accomplish this. So rather than following a code-compile-test-fix cycle you would follow a code-inspect-fix-compile-test-fix cycle. With practice, inspections can be quite effective, and having an effective inspection step will let you get away with compiling less often.

There are other techniques for "defect filtering" used in the PSP, but I've found personal inspection to be one of the most simple, effective, and universally applicable techniques to use.

Answer 3

Where I work, a clean compile takes 45 minutes. A squeaky clean compile from scratch takes 4.5 hours. One line changes take about 5-10 minutes each. And this is on a machine that has 32 cores and 128 GB of ram.

How I get around this is to have a separate compilation for my module alone. This also has the added advantage of being more modular, since I will know all the dependencies of the module. Also unit tests give the execution context needed for the module. So I have a ready made unit test framework also. Only after all unit tests pass, will I start compiling with the platform and do integration testing. Compilation time for individual modules are typically within seconds.

Answer 4

(During a compile) I had an idea of Visual Studio alerting me to an end of compile and found an answer on (of course) Stack Overflow. This will help, at least, to warn me that the build is done.

Answer 5

You might want to raise the issue with the project-lead and manager to see if you can collectively come up with a means of either shortening the compile-time or requiring less-frequent compiles.

I've been in a similar situation where the effort required to do basic tasks continued to grow to the point that it was impossible to remain focused and be effective. After a year of trying my best to offer alternatives and suggest changes I hadn't seen much response--and it ultimately led to me changing jobs.

Perhaps more constructively; could you spend the time on related--but non-coding tasks (such as time-accounting, updating ticket-statuses, code-reviews, etc). While they might not address the main issue of you losing your focus they at least keep you up-to-date on the pencil-pushing during a big downtime.

---

Also, just noticed you mentioned "don't want to miss it finishing". A simple solution is to have an egg timer you can quickly set to 10-minutes; or possibly explore if there's a notification of the build-completing that you can use. For example, if it can send you an email, and you use Outlook, you can create an Outlook rule that says "when mail received from buildserver@example.com with title 'Build Complete' then play sound Alert.wav"

Answer 6

Don't focus, it's the perfect time for a short break, programmers are human and they need rest too, don't they?

Answer 7

I like to thread my development tasks.

After kicking off a build to test my latest changes on task #1, I'll immediately jump back to the editor and start working on task #2. By the time I'm done with #2, the build for task #1 will be ready for testing. Eventually I'll start a build to test issue #2, giving me time either to return to issue #1, or start on #3 if I'm done with #1.

Obviously this can only work if you can find two tasks such that development in one area shouldn't affect the other. You'll also have to deal with the overhead of switching threads - sometimes it would take me a few seconds to remember which change I was supposed to be testing in the new build.