See Work 2.0, an excellent article of the "advice from the trenches" variety penned by Steve Streeting. He's the (former, I hear) lead of the OGRE project; back problems are forcing him to modify his old work habits.
...the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in. 12-16+ hour days, evening and weekend coding marathons, pizza in the keyboard, crunch times, 3am debugging sessions where you just can’t go to bed because you can feel the source of that bug just beyond your fingertips, dammit, desperate last-minute sprints to deadlines where you manage to slot that last piece in, Jack Bauer-like, just before the world goes to hell.
We call this "flow". I first heard about it from Peopleware back in the day and it sounded great: better concentration, more productivity, less human interaction! For a young programmer what wasn't to like? And yet, as a young programmer, I had about as much say in how the office got run as the water cooler. My attempts at "flow" were perpetually foiled by meetings, phone calls, and chatty neighbors. I got frustrated, believing that things could be better, pushing against the situation instead of learning how to work within it.
Farther along now, I think that flow is not only over-rated, but potentially harmful. Let me qualify that: I find flow to be counterproductive. A quiet work place free from distractions: very good. Getting into a zone and sitting in it for hours: very bad.
Flow makes you blind. When you get into a flow everything falls away and it's just you and the problem to be solved. You crank away and turn over code and it is all great fun. But flow, by definition, puts you on a rail. You came into the session with a collection of beliefs about the problem, with preconceived notions of the "right" solution and about the problems you would encounter along the way. Now you're on the rail, you're in your flow, and you're shooting like a bullet straight at that goal. Wonderful.
But, in my experience, we rarely if ever aim correctly the first time. And while you're whizzing along in your flow you are flying past all kinds of possibilities and opportunities. If you don't take time to step back and take a breath, you just flat out miss them. Sure you solve the problem you went in to solve, but not as well as you might have. And the cost of those missed insights and opportunities, over time, is huge.
Flow blocks inspiration. My best ideas come as inspiration, often appearing as fully formed thoughts from...well, from I don't know where. Inspiration only comes away from the keyboard. It seems to be a truth of the human condition: you work your ass off on a problem only to have the answer appear while you're standing in the shower later (and I wonder if anyone has ever tried to correlate increases in intellectual output with advances in plumbing). When you're in flow, you're by definition sitting at the keyboard. You are in "output" mode; you are not receiving. Again, opportunity cost.
Flow creates work. You're in your flow, you're knocking out code left and right. You've totally whipped the problem you set out to solve, and it's only midnight! What do you do now? You can't switch to a totally different task, because that would require reconfiguring your mental working set and ruining the flow. Documentation is no fun, and you're too locked in to the task at hand to make any sense anyway. You don't want to walk away and lose a good flow. So instead, you start gold plating. You start "fixing" things, and adding "features". Of course, there's always just one more thing you can add, and the next thing you know you're in one of those "3 AM debugging sessions" Steve mentioned, trying to solve the bug caused by the crap code you wrote two hours ago when you should have just gone to bed, and which tomorrow you're going to have to rewrite anyway. You're working "12-16+" hours when you stopped being effective after 8. (And believe me, I'm not casting stones here, I've been there and done that too many times myself.)
I've come to prefer working in what I'll call "pulses" instead of "flow". I like focusing completely on a small, well-defined task for a short period of time. I like using the pomodoro approach: 25 minutes on, 5 off. I like doing long-term improvement projects, both personal and professional, in small intervals as part of scaffolds. I like having a variety of projects going at the same time and switching between them at regular intervals. I like getting away from the computer entirely and doing something else (the lack of which I consider to be my biggest weakness right now). In all of this, I believe strongly that the time not actively working the project is just as productive, if not more so, then the time sitting at the keyboard.
To bring it back around, Work 2.0 provides some excellent advice on working effectively with pulses. In particular, I like his advice on maintaining an external context: keeping notes, task lists, diagrams—as much of your mental state as possible—outside your mind. I use Things from Cultured Code for this, using the excellent quick entry feature to capture any thoughts or possible next actions. Pen and paper works, of course. Vitamin-R looks interesting too.
The rest of Steve's advice is just as useful: ignoring tangential issues, focusing on individual tasks, prioritizing negatively...check out the full article.
(* Now, sometimes you just need to get the thing done. I put food on the table with client work and I understand the reality of a deadline. There are times when "done" is more valuable than "great", and sometimes more valuable than "good", and in those times the opportunity to get into a flow can make all the difference. But those times should be few and far between.)