This is an easy problem to solve. Keep a to-do list for down times - small tasks that are not too urgent/important, but can save time in the long run.
If you absolutely can't find anything to do in your task list, then you could do one of these two - first : find a colleague who needs help and help them. Second, keep a diary (or text file) and learn something new that is specific to your job/company. In my case, I work on a mid sized webapp, I know probably 30% of the application - so I make it a point to learn something small here and there, and it adds up over a period of time. Yes, I am aware that this knowledge is useless if I leave this job, but until then it is very useful.
Spend time investigating how you could make the build faster. (tweak makefiles, compile only some parts, divide the app in shared libraries, stop using too many templates, move slow parts with lots of templates to a utility library, etc...)
There's an important distinction between "taking a break" (e.g. playing foosball for a few minutes) and true downtime (I wouldn't be doing work right now even if I wanted to, because I don't have anything to do).
If you absolutely can't find anything to do in your task list, then you could do one of these two - first : find a colleague who needs help and help them. Second, keep a diary (or text file) and learn something new that is specific to your job/company. In my case, I work on a mid sized webapp, I know probably 30% of the application - so I make it a point to learn something small here and there, and it adds up over a period of time. Yes, I am aware that this knowledge is useless if I leave this job, but until then it is very useful.