Avoiding "the stupid hour"
There's a lot of talk about this subject as if the practicioners of coding long past the point of optimal productivity have a choice not to code when you are at that point. I don't think most of us actually have a choice - it is often a case of ship or lose customer x. Promises are made that can't be kept by humane working hours. Things break days before a huge demo. Someone gets sick. You are in an arms race with a well-funded competitor.<p>Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters. Usually, the first product to market wins, or the programmer who kicks out the most features as long as the features works. Shipping isn't just a feature. It is the only code quality metric that matters to anyone who isn't a coder. It also is easier to ask forgiveness for refactoring after the ship date than it is to ask for permission to push the date back. All-nighters are ingrained in the practice of programming for a living. The code may not always be robust or elegant, but in most cases what matters is that it works and gets done faster than the others guys' high quality code job.