There is a reason why "Test Driven Development" has become extremely popular today - it lets developers write a little bit of test, a little bit of code, compile it, test a little (maybe debug it, if necessary) and refactor it - in cycles measured in minutes, not days or hours. So there is a broad consensus that it is definitely not a good idea to write a block of 500 lines of code and then let the code run the first time, see if it crashes (which it most probably will), and then start to look for all the possible root causes (which are many in a code block of that size).
There is only one situation where I can think of coding in larger steps and "debugging later" might save time - when you have very large turn-around times. When each build cycle takes 30 minutes or more, you don't want to compile, build and debug after every 10 new lines of code.
Fortunately, most development environments today don't impose such build times on the devs, and even in large-scale C++ projects, there are means available to mitigate such issues.
However, this is not only a matter of the environment, it is also a matter of structuring your project into components. If you can implement, say, 450 lines of the 500 total lines of your code in a separate component, which can be compiled and tested apart from the rest of the system (maybe using TDD, or at least using unit tests), then you can (and should) develop the component in as small code/compile/test/debug cycles as possible, even if a full build of your system would take more than an hour. Afterwards, you may finish the separate integration step with the final 50 lines of code "en block".