Actually, it is not a myth. I have done this, more when I was younger, but it still happens occasionally.

One reason for the midnight oil is that the phone stop ringing, everybody else goes home, there are no distractions. Another reason is that the business demands it. Let me give you an example. There is a story that the folks at WordPerfect, which had (and still has, if my mother is any indication) fiercely loyal customers. They had a very family-oriented company culture, and nobody stayed past 5. Microsoft did not go home at five, except maybe at 5 am. Microsoft ate their lunch.

In several situations, I could not get access to computers until after the day shift went home. In Portland, while on co-op during college, I would walk to work at about 0200. The path took me past a bakery that was in full-on baking mode. While building a real-time medical data system, we had one production computer and a second computer that was occasionally used for production at night, so we worked nights to integrate both parts of production so that the other computer would be available for development all day.

And sometimes a problem will grab you and not let you go. The story of fluidics has as its beginning a 36 hour creative burst by its major contributor. And there are problems that I have worked on that have a multi-hour daily mental ramp-up.

The myth part of this is that you can get away with doing this constantly. You can't. As you say this very act should be resorted when you have no choice.

What the midnight oil has taught us in the industry is that the best programming is done in an environment free of interruptions, and that the plentiful availability of development equipment removes scheduling constraints previously imposed on programming.

And I am older than those two numbers and still occasionally pull the midnight oil.

These are two different things. One is working at night, and the other is working non-stop. I like working at night (I wake up at 1ish pm and go to sleep at 4-5) because it's more quiet.

I don't put in 16-hour days, though. There's a clear distinction between the two, and "burning the midnight oil" refers to the former. You can get the advantages of working nights without overworking.

I agree, and I think the ramp up time plus the intoxication of total absorbtion almost mandates some degree of obsessiveness that makes programmers more similar to artists than other types of engineers - there has to be peace and quiet and you have to lock into the problem and once you are locked in it is difficult and unpleasant to disengaged.

I'm not quite sure about the long-term solution. Normal family life has never been something that many artists are capable of (i.e. Van Gogh), and perhaps companies need to be more accommodating of employees that work two 10-16hrs bursts a week, rather than the normal 9-5.

Personally, I am in the "at risk" category for leaving the industry for this reason -- it is both burn out and lack of interest. I don't know, I still think there is some great code left in me, but it needs more challenging problems then I am facing at present.

An interesting thing I've noticed is that burning the midnight oil works really well if I haven't been coding all day. It can work marvelously - it's quiet, nobody bothers me, the internet is asleep and I have a clear focus.

But if I've already spent the whole day thinking, then decision fatigue kills my productivity completely. Some might say I'm just tired, but it isn't related to how much sleep I'd had, just how much time I've spent thinking.

Or even worse, spent the whole day dealing with bureaucracy and mundanity and meetings and crisis management... Forget about getting any actual work done.

I once spent the night on the stern of a sailboat with 6 cans of Red Bull, debugging a Mac driver for a piece of hardware that may end up being used by Foxconn to test iPhones.

I would have been much more comfortable in the cabin but the marina WiFi network didn't reach that far.

Why burn the midnight oil? It was either that or no sailing out next morning to spend a week at sea.

That just seems highly irresponsible though - you are working on adrenaline and caffeine to get a product out so you can go away and be offline for a week right after. I've been in your shoes before, and tight deadlines can warrant the need to just get shit done - but I also make sure I am around after some brief rest to handle any additional issues.

In college I used to dream in/of code. More than once I've fixed things in the hour or so that I was about to fall asleep, got up, made the changes half asleep, and went back to bed. More often than not, it actually worked the next morning.

In those days (85-90) version control wasn't a big thing with a 1MB machine, 65MB HD) but my habit of "take a manual snapshot of my current project at the end of every day" is the result of one or two failed "sleepcoding" events.

Tangent: reading the post the other day about how Turbo Pascal fit in 40kB blew my mind and brought back many good memories. I also realized I was much smarter then.

I don't think it's about time/schedule but rather intensity. I would agree in that the majority of application code really is just little bits of accumulation - piling on another feature or fixing another bug. Those are things you do optimally if you're lazy, knocking off a few each day while spending the rest with non-coding tasks. And with those tasks the slow pace is beneficial in giving yourself room to examine all angles and stop yourself from a trap later on.

You only need to pull the long hours when a big impact is really needed - generally, learning something new or introducing major new concepts into the codebase. With those projects, slicing up the hours is detrimental to understanding of the problem. You still don't want to make an unnecessarily complicated solution, but long hours make necessary complexity easier to tolerate.

I don't think anyone really knows what they are going to do 20 or 25 years into the future. I like coding and expect to code for a while. But, I understand that I have also changed a lot since I was pulled out of the womb 26 years ago.

I've gone to work after staying up all night before, and produced code that looked unfamiliar to me the next day. Some of it had stupid mistakes, but on the other hand, some of it was "I wrote that?" in a good way.

Granted, I'm not writing CompSci research papers on what I do at work, so the difficulty level might have something to do with it.