Staying focused during automatic processes, "It's compiling"

Question

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)

Answer 1

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:

1. Buy an SSD.
2. Add more RAM.
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.

Answer 2

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:

• Answer emails
• 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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.

Multitask

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.

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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
- proceed to next task

Notice that all of the tasks are in a logical order (atleast for me), but they are not dependant in the sense that the change in code would happen in different places. This allows me to plan my next task while my current task is compiling and/or running tests.

This approach does however demand that your ability to context switch between two tasks is up to par. If it is not, then this approach isn't suitable for you. Other approaches (mentioned above) like stretching, finger exercises might also work.