I recently had a job interview in which they gave me an hour to write some real code. It wasn't a huge amount, probably less than 100 lines. After about 45 minutes, I compiled, ran it, and got it to work. I may have spent 5-10 minutes working out compile errors and a couple minor bugs, but overall it was very smooth. (Incidentally, I did get an offer from them.)

However, what puzzled me was that after I handed over the completed code, the interviewer told me that the only thing I did wrong was "not compiling as I go along". I asked him what the difference is, and he said "what would you have done if you finished the code and it didn't compile in time."

In my understanding that's an invalid argument, because "getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time, which should be the same whether you do it after you finish writing the code, or if you interleave it with your coding time. If anything, interrupting your coding to search for missing semicolons would probably be detrimental to your efficiency. Except in extreme circumstances when I'm experimenting with obscurities around edge-cases on things like virtual functions in derived classes, etc. it seems reasonable to expect that code written by a an experienced developer will compile, minus the occasional typing error, and even if it doesn't, it's not as if I would have to rewrite a portion of the code in order to fix the compile error.

In another similar incident, I was given an incomplete codebase in an interview, and asked to finish it and make necessary modifications to get it running. I started by reading through the existing code, and then after a few minutes (even before I had finished looking at the code), the interviewer told me that's enough. When I asked him what he would have done (i.e. "what did I do wrong"), he told me that he would have started by immediately getting the code to compile.

Why is that even relevant? In my opinion and in my experience, whether or not a piece of code compiles is essentially random, involving things like whether or not semicolons are missing, and has little to do with the correctness of the underlying program. (To me, focusing on compiling is like running an article through a spell-check without proofreading to check the grammar.)

If you give me a piece of incomplete code, the first thing I do will be to read it. I won't even try to compile it until I know what the code is doing and I know the algorithm is correct.

Anyway, these have been just a couple recent incidents, but in general I've heard many developers talk about compiling their code as they go along, and yet nobody has been able to tell me the benefit of doing so. I understand the benefits of *testing* your code as you go along, but why compiling?

So my question is this: Is there something I missed? Is there actually a benefit to compiling as you go along? Or is this some sort of myth propagated by the software community that you must compile your code frequently.

Quick fix

There is. It gives you a shorter feedback loop—which in general, when designing (UI, writing software, visual design etc.) is a good thing.

A short feedback loop means you can quickly fix errors early on, before they become more expensive to fix.

To borrow your example, say you were coding in a C-like language and forgot a '}' somewhere in the middle of the program.

If you compile just after you finish writing the statement, you can be quite certain you have just introduced the compilation error and can fix it there and then, within seconds.

If you don't, however, you would have to spend a good amount of time reading the code, looking for the exact position where the '}' is and making sure, once you have located the error, that the fix is indeed what was intended. This would take place a while after you left that bit of code. It wouldn't be as crystal clear as during the moment you wrote it.

Now, yes, the end result is the same, but you wasted a good amount of time on syntactical issues that the compiler is there to help you with—an amount of time that could be significantly shorter if you compiled as you went along.

Part of the test

Compiling is a form of test, especially in languages which make extensive use of types such as Haskell or ML. In other languages it's a syntactic scan that tells you little.

Having said that, "compile as you go" seems to me a very situational habit. You could equally be marked down for being "twitchy" for compiling more frequently than the interviewer's personal prejudice. It sounds like nitpicking; nobody likes to admit that a candidate has aced the test. It tips the scales of the salary negotiation.

Not all build systems are fast. I worked on a (C++) project where Make would spend 30 seconds just stating everything to determine whether it needed to build or not, and most files would take a couple of minutes to build if you had made changes. We were reluctant to do this more frequently than every 10-15 minutes. Someone will no doubt supply an anecdote of when compiling involved taking your deck of punch cards and carrying them to a different building.

Compile when you feel you've done a complete conceptual unit in your head and are ready to have it validated: once a minute or once a week depending on the workflow.

Find problems early

I actually agree with you that compiler errors should be no big deal for an experienced developer. I don't think the cost of fixing them increases significantly enough over time. If it were possible to postpone fixing all the compiler errors until just before a push, I would do so, as it would present a much smaller and more consolidated interruption.

Unfortunately, finding compiler errors isn't the only thing compilers do. At the risk of stating the obvious, compiling is required to run your program, and running your program is required to find all the more complex, subtle, and interesting runtime bugs that even experienced developers create. And those types of bugs are more difficult and therefore more expensive to fix the longer you postpone debugging them, because they can build on or mask each other.

However, I wouldn't necessarily mark someone down in an interview exercise for postponing compiling until the very end. Interview exercises tend to be very straightforward, and experienced developers usually know their limits. The more confident you are about what you wrote, the longer you will go between compiles. That's just human nature.

In order to not mark you down for it, the confidence would have to be justified, though. If you had spent 45 minutes writing something without compiling, then required another 45 minutes to debug it, I would have weighed that heavily against you.

Find more answers or leave your own answer at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and ask a question (it's free).