My number one rule is to reduce the code, compile, test iteration cycle. If your compiles are too slow then get a faster computer. Writing a hardware driver o

My number one rule is to reduce the code, compile, test iteration cycle. If your compiles are too slow then get a faster computer. Writing a hardware driver or developing embedded code? Make sure your test hardware is sitting on your desk. You can have it somewhere else if it's ssh-able and has a remote reboot button that's accessible from the command line. Because if those are true then your build is scriptable. Always make sure that you have to run only 1 command to compile and load your new code to the test hardware (IE, up-arrow return does it all). If you have to do more than one thing to get your code running then you are wasting precious brain cycles on your build process which can be as big an interruption as a phone call or email, especially if the things you have to type aren't even the same every time. At the moment I'm violating this principle by having to drive 15 minutes to get access to my test machine. I can program there too, but it's kind of a hassle. Needless to say this project has dragged on for weeks longer than it should have. Sigh.