A 15 second build over a 30 second build saves way more time than 15 seconds a build. It means that I'm more likely to hit compile after a smaller change before moving on to the next thing. It means I can iterate more rapidly on my approach to fixing a bug, keeping the issue hotter in my mind. It means I have half the time to get distracted by something shiny. Any time you can make the build perceptibly faster, you win big.
For the Arora project one of my default git hooks it to build the project, tools, manualtests, matching autotests (and run them for regressions) before each commit. This slowly increased to the point where it was taking minute or so (over the course of just a few weeks). Taking a few hours I cleaned it up and had it back down to just a few seconds at most and on average less then a second. I did it the more correct way and did some quick profiling to see where the time was spent and then fixing that (mostly that object files that could be were not being re-used across different project when building). Making sure that I never break the build on any commit really pays off. There have been less then a dozen build breakages in the entire Arora commit history due to this git hook and those I believe were either build breakages introduced on OS X where a.cpp == A.cpp (breaking it on win/linux) or when we broke the build against older versions of Qt so it build against 4.5, but not 4.4. When you have a quick build time doing things like build hooks are very possible and useful.
Playing the devil's advocate, I would say that you can also look at it the other way and say that a developer might not build as often but instead make sure his/her code is right before building, thus being more careful about what s/he's writing. (just for the sake of argument ;))
Right, because I was advocating typing line noise until it makes it past the compiler.
I can't count the number of times I used to make a tiny change that I didn't think was worth running the build for, only to have it be the first thing to pop up as wrong next time I compile (now I always run a build, because we made it super fast).
And iterating over a bug, that can involve a lot of little changes, it can involve writing a ton of unit tests trying to duplicate the problem, it can involve subtle interactions that all seem right until you figure out what the issue is. Yes, you have to think, but sometimes you just need to churn through it, too, and frankly it's ridiculous to suggest that having a faster build process wouldn't help this.
And I, personally, get distracted pretty easily. This comment courtesy the 5 minute test suite I'm plowing through in the background right now.
