# Staying focused during automatic processes, “It's compiling”

I recently ran into quite an ironic situation. After changing a small part in some code and telling my computer to start compiling, I switched to a website and ran into this:

[xkcd comic 303 by Randall Munroe]

At my company they choose to work with a tool that's notoriously slow at compiling programs. It's chosen for the ease of implementing programs, they're used to working with this language.

I often find myself hitting the compile button, and either waiting for about 30 seconds or getting distracted. After those 30 seconds, I get back to work, only to find that I made a small mistake, and have to hit compile again within two minutes.

Waiting for 30 seconds once isn't too terrible, but having to do it about 15 times an hour is tedious. Getting back to work after those 30 seconds gets harder by the day.

How can I stay productive?

Edit:

Apparently the kind of mistakes I run into wasn't clear. I'm not talking about mistakes caught by the compiler. It's mostly mistakes that I only spot once the program is running, for which it needs to compile. For instance, interchanging two (poorly documented) ID's. The mistakes are hard to see from the code, but easy to notice from the behavior.

Update:

I've taken from a lot of the suggested answers, and none of them is "the right one", as they all offer different ideas and opinions. Some are great ways to speed up the compiling, but unfortunately none of those apply to me. I work on a fast system with 2 ssd's, but the bottle neck is that I'm working on Android, which has to upload via an USB. So as the compiling can't be sped up, I'll have to keep my workflow going differently.

@Coteyr's answer is great, but unfortunately this is pretty much my sole project. That does allow me to focus on this project better, but as I don't have too much other work to do aside this, I won't be able to apply this answer to myself. I hope others find it useful though.

Dennis' and Иво Недев's helped me a long way. I've started going through my code while it's compiling, and adding comments where needed. It's difficult to get started with though, as the idea "meh, anybody who reads that should know what it means". Pretending that people who read my code will be stupid did help a lot in adding proper documentation.

What I think had the biggest change is something not mentioned in this thread though, as I did not provide the specific details for an answer like it to come up. While walking though my process again, and actually timing the compiling time (turns out to be 1 minute 15), I realized that the biggest problem was that I couldn't actually do anything while it was compiling. Visual Studio has the nasty habit of locking your files... So thanks to https://stackoverflow.com/questions/3123624/visual-studio-locking-files-while-debugging I've managed to change that, and I can say, it helps a lot to be able to touch your code while it's running.

A big thank-you to everybody who replied, it just became a lot easier for me to keep up my focus for 8 hours a day.

(Please if you have any other suggestions, do feel free to add them as answers, they could be very helpful for future passers-by)

• Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Jun 22 '16 at 12:24
• The question got protected so I cannot add a new answer but I think there is a better answer than the ones already given: Make better use of unit tests. You can create the class and test its behaviour in unit tests that you can run in your IDE. It'll probably also allow you to run one specific unit test to check if your changes have fixed it. This way you'll need to deploy it way less often. – flup Jun 24 '16 at 7:01
• Amusingly - I got here while my latex document was compiling... – Joel Jun 24 '16 at 15:15
• ...But the bottle neck is that I'm working on Android, which has to upload via an USB. So as the compiling can't be sped up... - Then your bottleneck is not the compilation step. It's the uploading step. – Jim G. Jun 24 '16 at 19:08

A long build cripples the entire software development process. You shouldn't accept this as a fact of life without first taking steps to reduce the build time. Here are some ways you can do that:

3. If you're developing a web app: Use browserify to hot reload your client-side code.
4. While developing, build only the portions of the code base that are changing.
5. Investigate the build code and, on your local machine, short-circuit the build so that it builds only the portions of the code base that are changing.
6. Consider running automated unit tests only before check-ins.
7. Collaborate with team members and managers to permanently reduce the build time.

More on #1 and #2: These are especially effective. You should do these even if you need to spend money from your own pocket because they will increase your overall workplace satisfaction. A good carpenter wouldn't tolerate a dull saw, and you shouldn't tolerate a slow hard drive or a workstation with insufficient RAM. You want to be home at night, eating dinner with your family or watching Netflix. You don't want to suffer a miserable "death by a thousand cuts" by waiting for slow builds.

EDIT:

1. To those people who said that I didn't answer the OP's question: Please consider this Meta answer.
2. A slow build can cripple the workplace. It's very important to explore all options before accepting the fact that the build is slow.
• Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Jun 22 '16 at 12:25
• I'd also add in looking at other tools. I remember having to work with Sharepoint and it took 15 minutes to deploy and test a JavaScript change! I used Fiddler in the end to re-direct calls to JS files to locally stored ones that I could rapidly modify. – Ian Jun 22 '16 at 13:21
• Can confirm. Had an old rig for a pretty long time and it was really aggravating. After getting one with more RAM work was way better than before. – Gigala Jun 23 '16 at 12:20
• Also benchmark your virus checker and see how much is slows down the build. Change virus checker if needed. – Ian Jun 23 '16 at 20:47
• Just to add on to #1 and #2, if you have enough RAM for it maybe look into putting all your development on a RAM disk (plenty of resources on how to make one on your system), just make sure you have something backing it up every couple minutes in case of a power loss, unexpected shutdown, etc. I've used this myself to great effect, by putting my entire development environment in it (Java instance, ant, eclipse, source code etc) – Mitch Jun 24 '16 at 14:58

A sword fight is great exercise. Use it.

To be honest, there's not a lot you can do with the code when it's compiling. You can try to reduce the compile time but some times that's just not possible. You can try to reduce the number of compiles, but again, sometimes it just sucks.

SO.., to improve productivity, you just need to get better then a chair, sword fight. I would suggest:

• Document Tickets
• Document Application
• Commit to SCM if you can
• Take a legit break.
• Handle other non-related code tasks
• have meetings with team members
• take a nap

Honestly it's one of the reasons I like the languages I like. No compile time. If you have compile time that is long, your just gonna have to deal with it assuming you can't address it.

For example, in .NET you could separate large chunks of logic to DLLs. Then you only have to compile sections of code frequently.

You could also look at compiler options and choose options that "abort after first error".

Note Just noticed your build time is 30 seconds. That's not a long build time. If you want something to do in that time, then do finger exercises, or stand up and take a deep breath. Long build times are 10 mins. or more.

• You should read about how bad it is to switch of tasks again and again for producitivity. Things like this doesn't really work. He will lose in producitivty even more and get more stressed – Walfrat Jun 20 '16 at 14:31
• Well, when I first read the question I assumed a 30 minuet to an hour was a long build. If you have half an hour to kill while you wait for the compiler, then best to fill it with at least semi-related tasks. If your talking about 30 seconds.... Well it's as good a time as any to do some kind of eye strain or finger strain exercise. There easy and fast, and EXTREMELY important. – coteyr Jun 20 '16 at 14:35
• Consider adding a bullet point: "Check StackExchange Hot Network Questions list" ;-) – Digital Trauma Jun 21 '16 at 1:46
• @DigitalTrauma That must be one of the worst productivity tips ever ;) Almost as bad as "read a wikipedia article and try not to follow any links" (never works that way). – Sumyrda Jun 21 '16 at 7:26
• "Commit to SCM if you can" before a build has finished? – StuperUser Jun 23 '16 at 13:52

Something from my own experience:

# Try to fix multiple mistakes at once.

Sure, it is very quick to swap two columns, after you notice that they are swapped. But, make sure that you don't stop checking after you find 1 fault.

For example, you could reduce the number of cycles by checking other things:

• Are the columns at least formatted properly?
• Do all other columns contain what they should?
• ...

This is especially important in the first 1 or two cycles and could help you go back from 15 to 5 delays of 30 seconds (and probably a better result as well).

• Oh man, this is so critical. We focus so much on reducing cycle time... Total time = cycle time * number of cycles. Reducing the number of cycles is just as important as reducing cycle time!! – corsiKa Jun 20 '16 at 16:15
• I think this overlooks the cost of fixing too many things in a single cycle - this makes it very hard to isolate the impact of individual changes. That's why there's such a focus on cycle time - reducing the number of cycles generates other detrimental effects – Dancrumb Jun 20 '16 at 17:32
• @Dancrumb It doesnt have to be if you manage what to fix, especially in the phase where everything is 'built' and you are testing. While testing, make a good list of all issues you have to fix. Try to figure out what you have to fix, so you don't need trial and error later. Test as much new/fixed functionality as possible. Then kill the program, go into your IDE and fix these all. Mark in the list which ones you have fixed. Then do your build and test all your fixes - strike through when done. This way you can easily make cycles of 10-20 fixes at a time before having to rebuild. – Jan Doggen Jun 20 '16 at 17:39
• This is what I do. More specifically, I try to work on two independent issues at a time. I'll work on task #1, hit compile, swap to task #2 which is email, or a different code-base. Then swap back to task #1, test, and repeat. – user1361991 Jun 20 '16 at 18:23
• I lost count how many programmers I've met that rush to debug and solve just the first bug they find without testing the rest of the changes. This is an excellent answer. – T. Sar Jun 21 '16 at 20:41

Try making a script that does what you need it to do then makes an audible ding noise and/or makes a popup. This way if you want to divert your focus you don't need to worry about zoning out completely and forgetting to check if you are done. To me it's fine to get "distracted" by looking at other things like other code but the problem is when you "go too far down the rabbit hole" and forget to check if the process is done.

I won't bother giving a suggestion on how to do this as it will vary by operating system, method of compiling, and other factors. I'd just Google something like "make sound and popup in (insert operating system here) when command is done" or something of the like.

Update: as some of the comments have pointed out, there may be ways to do this in certain programs with GUIs, not just from the command line. As before I won't bother giving suggestions here because it will vary widely by what program it is and what is taking a while.

• Slack integrations or similar work well for this – Joel B Jun 21 '16 at 20:57
• +1; delays happen, and unless you give yourself enough monitor space to watch results while multitasking, the best you can do is to avoid the human equivalent of "polling". It may also be easy to wrap the compiler command to make it pop up a message; I use a very short notify shell script that is, in short, "$@"; notify-send "$1 is done." (docs) – Jeff Bowman Jun 22 '16 at 7:03
• Tangentially related to the subject of long processes, if you are routinely doing long-running SQL queries some SQL clients can provide a sound on completion as well. – Talonj Jun 22 '16 at 19:14

My answer depends on the compiler but try this:

If the compiler allows for you to view the code, and it's compiling in the background, then you can perform your own version of RDD. While the compiler is doing its business, just go trough the code you've just written, compile it in your head, review it, and try to find any errors.

You will:

1. Not get distracted and lose focus.
2. If there's an error, it won't take you two minutes to fix and compile again, but much less.

For instance, interchanging two (poorly documented) ID's.

I've seen this issue in many programs that use Int or String for every single ID; in this case, it is easy to accidentally pass one ID instead of another and not notice it... for a long while.

If you can pass a Chicken ID to the Drink Machine, your code has an issue (*).

The trick, then, is tagging IDs. Since you are talking about long compile times, I assume that you have a statically typed language at your disposal, in which case you should leverage said types. A ChickenId is not the same as a DrinkId. A DrinkId is not the same as a FuelId.

Make them different types, and the compiler will happily point to you your errors, which will speed up the Fix-Compile-Test Loop (by cutting out the Test step and interrupting the Compile one).

This is the statically-typed version of the Fail Fast principle: there is hardly faster than having the compiler (or even IDE if it compiles in the background) pointing errors to you.

As a bonus, you can even introduce some validation in the same system. In my part of the world, few IDs are ever negative for examples... or if you a String, an ID of 2KB is surprising, to say the least.

(*) Unless drinking chicken blood is standard practice at your place, what do I know...

• While it might not directly address the OP's question, this isn't bad advice. Compare Making Wrong Code Look Wrong on Joel on Software or How do you make wrong code look wrong? What patterns do you use to avoid semantic errors? on Stack Overflow. – a CVn Jun 21 '16 at 15:28
• @MichaelKjörling: Indeed; it's not a new idea :) Also follows Daniel J. Bernstein's principle of trying to eradicate bugs classes rather than bugs occurrences. – Matthieu M. Jun 21 '16 at 15:32
• I get the spirit of this answer, but I'm failing to see how you can actually apply that to something like an id. There's only so many static types to choose from in the first place, and a lot are substitutable. If you made an id long, for example, you could still accidentally give an int. Besides, this would just be insane in practice. – Chris Pratt Jun 21 '16 at 18:16
• @ChrisPratt some languages make this sort of thing Ludricusly easy (F# and OCaml, for example). The idea is that even if two IDs are the same primitive type (int, say) that you have a type around int for each type of ID (ChickenID, DrinkID). While they are functionality the same, the semantics of the type system mean you can't get them the wrong way round. When code needs to perform comparisons and such on the ID, the appropriate methods can either be implemented per type, or the type specific code can decompose them where nothing can go wrong. – VisualMelon Jun 21 '16 at 19:04
• @ChrisPratt: To expand on VisualMelon's comment, using different built-in types would be a terrible idea as many languages have implicit conversion anyway so nothing would be gained. Instead, for each business entity you need to have a business type with the appropriate functionality; on top of avoiding mistaking one entity for another, you also avoid invoking non-sensical functionality (even if an ID is numeric, 2+ID, 2*ID, etc... just do not make sense!). – Matthieu M. Jun 21 '16 at 19:51

The obvious way to mitigate this is to stop making numerous small errors in the first place. This is where I would start anyway.

If the compiler takes 30 seconds, then the compiler takes 30 seconds. We all make errors, but 15 times an hour would be a flag for me to have a more robust error checking methodology.

There is probably as many ways to do this as their is people programming. Whatever works for you. Fix the problem at it's source.

I'm not a programmer, so I need to do quite a bit of messing around to make things work sometimes. How I stay productive is by multi tasking, when one thing is unable to be worked on, I work on something else.

• Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Jun 22 '16 at 12:26

Invest the time in yourself.

10 seconds free: Do pushups.
60 seconds free: Browse Stack Exchange Hot Network Questions.
120 seconds free: Get up and drink some water.

I just got up from doing 20 pushups while I was waiting for a coworker to answer me on Slack. Any time that I see I have 10 < seconds < 120 to wait for something, I use the time to better myself. Since I've started doing this a few weeks ago, I feel healthier, more energetic, and less tired. I see that my productivity has skyrocketed. And I feel great.

I often find myself hitting the compile button, and either waiting for about 30 seconds or getting distracted. After those 30 seconds, I get back to work, only to find that I made a small mistake, and have to hit compile again within two minutes.

Waiting for 30 seconds once isn't too terrible, but having to do it about 15 times an hour is tedious.

If you have to recompile 15 times an hour because you made that many small mistakes, then clearly distraction is not your problem - you simply aren't being careful enough.

And if you are making small mistakes that are being caught by the compiler, it's probably a sign that you are also making logic mistakes that aren't being caught.

Make an effort to be more conscious of your code before you compile.

Look it over, write some comments, look it over again. Then compile.

If you find yourself making the same kind of small mistake repeatedly, then perhaps you need to spend more time understanding your programming language. A small investment in learning might pay off in the long run.

• Sorry for the inclarity, I'm not talking about mistakes caught by the compiler. It's mostly mistakes that I only spot once the program is running, for which it needs to compile. For instance, interchanging two (poorly documented) ID's. The mistakes are hard to see from the code, but easy to notice from the behavior. – Daniël van den Berg Jun 20 '16 at 10:04
• @DaniëlvandenBerg If this situation happens often you could also consider incorporating TDD (Test-driven development). – Brandin Jun 20 '16 at 11:00
• @Brandin TDD relies heavily on short cycles and recompiling very, very frequently. While TDD is nice, it will certainly make his problem worse. – nvoigt Jun 20 '16 at 11:21
• @nvoigt: No because recompiling very frequently will limit the scope of potential reasons for compilation (and build-time automated test) failure. If you're making only small changes in between builds and you still find that you need 15 attempts to get it right, then (downvotes notwithstanding) the programmer is simply making too many mistakes (but will hopefully improve in time as they gather experience). Either way, TDD will limit the damage done. – Lightness Races in Orbit Jun 20 '16 at 14:08
• @nvoigt: If you make 50 substantial code changes before you try a compilation, you will have more to fix and more re-compilation necessary before you reach your target. Each fix/change risks affecting the 49 changes you made. If you instead make 1 substantial code change then immediately test it, and you find that you failed, the damage done by that mistake is likely to be far less pronounced. Although to be honest I find this entire thing moot as the OP says compilation only takes 30 seconds, which is nothing! :D – Lightness Races in Orbit Jun 20 '16 at 15:54

## Be more careful / Get better software

Is the real issue that you have to wait for the build to finish to know if you made a mistake, or that you are letting enough small mistakes through that the very short build time (30 seconds!) became a problem?

Not all problems are going to be immediately obvious; that's why programming by accident is an awful idea, and it sounds like what you are engaging in.

Your edit suggests you are doing this because the software you are using lacks documentation. That is a problem with the software and it should be addressed. Documentation isn't a nice extra, it is core functionality. If you have spent enough time guessing about the API to ask this question, it's probably time to discuss if that software has become a liability.

## Use the time for small one-off tasks

30 seconds seem the perfect amount of time to do several small, not entirely likely to sidetrack you, tasks. The best examples I can think of are playing/changing a music track and checking your official email. While the second might distract you, that might not be a bad thing inherently.

As my comment on the question stated, I am used to builds that take a lot longer than 30 seconds. If your builds start taking longer, you might want to ensure you always have a second task to switch to during them.

I try to have a task A and a task B - task B having nothing to do with compiled programs, which I can work on while task A is building and sucking up almost all my disk IO.

• This is a normal flow for TDD, Little bit of test little bit of code. Not programming by accident. Programming by accident you dont care about your tests – exussum Jun 21 '16 at 20:06

Implement a Continuous Integration/Build Server and automated tests.

Once you make a commit, your build server should notice and start an automated build. This immediately frees you to continue working.

When the build finishes, your server should run some automated tests to catch common problems like what you described (mixed columns, etc). The server should email you if it finds any compilation and/or test errors.

The benefits of this workflow is you never get pulled out of focus. You keep working on your current task, and asynchronously get feedback about build. This allows you to complete a thought, and then go back to fix errors, not constantly bounce back and forth, causing many context switches.

• Please don't use the build server as your compiler. Your coworkers will quickly learn to hate you. – ThatGuy Jun 24 '16 at 0:13
• While this is good advice it is incorrect. You should be compiling and running unit tests locally before committing. CI servers only give you the guarantee in the case of lazy or less experienced coworkers who commit without doing these things. Also, your reasoning is flawed when you say you can keep working on your task with this method, because you can keep working on your task if you build locally too. – Captain Man Jun 24 '16 at 13:43

(This is in response to the edit to the original question stating that the errors in question are not compilation errors but those which you only spot once the program is running.)

Time spent with behavioural or runtime issues can be drastically reduced or eliminated by writing unit tests. You will not only save time by not manually having to run the same steps after each iteration (Let the machine do the menial work for you) but the act of writing code to ensure you can test it in the first place will help you reason through your code better and force you to think about data flow and consider edge-cases.

Given that the errors here are not poor coding but poor documentation, is it possible to (1) catch many IDs in one compile run, rather than fix them individually, then you may be able to work more productively given your build system or (2) move the IDs you have a problem with into a text file which can be read at run time. Then you wll compile ok, and then spend your time in a run-edit-run loop, which may be faster in your case.

# Better hardware

Before changing anything, have you tried throwing more/better hardware at the problem? Having an upgraded workstation isn't just a nice-to-have, it actually saves the company money. Everytime you get distracted, the company loses money (for the time you spend getting focused again).

# Better build process

If more/better hardware didn't solve the problem, look into streamlining the build process to be faster or even changing the toolchain for a faster one.

# Better yourself

The reason I suggest both of these approaches first is that this will reduce the distraction time for all developers in your company, rather than just you. If both of these approaches don't make the problem go away, then indeed there is only one variable left and that is you.

When I am working on an issue, I plan out how to solve something in multiple steps. An example would be implementing a login button. This is a multiple step process.

- Find the appropriate button icon and place it in the index.html file.
- Make the button call something on the backend, usually an API
- Make the API call the appropriate service.
- Let the service call the appropriate DataAccess methods
- Create tests for valid and invalid logins (backend)
- Create tests for valid and invalid logins (integration)
- Add these tests to automated test repo
- Commit code