+1. I've found that thinking hard and long about most problems before coding them results in less buggy (sometimes even no bugs!) code. I remember my friend telling me that his dad had to stand in line and wait literally days to execute code on a computer (using punch cards) and they had all the time in the world to write the code, but very little to execute it. One mistake during execution and they would have to wait a few days for their turn, delaying the results that they were seeking.
I try to emulate this environment (by not compiling/running code) and trying to tell myself that I really should get a large chunk of thought (followed by relatively bug-free code) down before I let the compiler/interpreter in. This discipline has helped me a lot imho.
Yeah my Dad has told me similar stories. In fact, I'm finding a similar thing now when I'm using the university supercomputer. I don't have to submit using punched cards anymore (thank goodness) but I do have to submit jobs to the batch queue and give them an estimated time the job will take to complete. This impacts the scheduling of the jobs, so if I submit a job and say it'll take 12 hours to run, then it is unlikely to start for a while. This gives me another reason to check the code very carefully, or I wait overnight and find that my code crashed after 2 seconds with a silly error!
I try to emulate this environment (by not compiling/running code) and trying to tell myself that I really should get a large chunk of thought (followed by relatively bug-free code) down before I let the compiler/interpreter in. This discipline has helped me a lot imho.