I guess that's one of the advantages of interpreted languages over compiled languages. I spend no time waiting for compilation to happen (ruby). I used to spend a lot in my previous job (C#), where the time was utilised (wasted) in going through blogs/articles.
While long compilation times are incredibly annoying, compilation offers a first pass test on code: Is this code syntactically correct? Do (at least some of) the semantics make sense?
With an interpreted language, you may be able to test for syntactic correctness with a simple scan over the language, but you're approaching compilation at that point. More likely, syntactic correctness is verified by a test suite that's sufficient to provide 100% code coverage (which can be hard to build and maintain).
It's also harder to know if a reference to foo is valid at any point, until it's executed. Which is where the semantic validity and verification of compilation comes in handy. A tool which can do this for your interpreted language is most of the way to being a compiler, it's simply lacking the translation step.
The nice thing with interpreted languages is that you could put off a lot of this verification/validation, similar to the distinction between dynamic and static typing, until you actually need it. The debate is when you need it and how much value is added by putting it at the start. But languages like go and incremental compilation being adopted by more compiler/toolchain developers is at least cutting down on the time to reduce the time spent idling (as a developer) in the feedback loop.