After reading this, I felt compelled to compile some of the similar thoughts from here and put together a short blurb on what it's like for me, being a programmer.
Programming is Mental Sprinting
Written by: Maxwell Rathbone
Pieces Compiled from:
http://ask.slashdot.org/story/10/04/14/1925218/How-Many-Hours-a-Week-Can-You-Program
I do find myself writing code in a sprinting fashion. I can always code when it's time, but sometimes I get a burst of speed and clarity that I might not have every single day. I sprint ahead and make up for the days when I'm not so sharp. Many programmers do this. Programming is hard, and it's easy to get distracted. As a programmer, I have honed my ability to focus, almost in a meditative state, while I write code. While I'm in this meditative state, I'll have dozens of pieces of my code visualized in my head, potentially solving multiple 'problems' at once related to the project. I'll also have the overall path of the project and the various smaller tasks I could potentially be working on visualized. Getting distracted while in this state is the equivalent to someone walking up to my mental whiteboard and erasing everything on it. For this reason, when I'm distracted it takes additional time to regain my previous state of concentration and clarity. It takes time to reload into my active thought process all the pieces to the project I'm working on. For this reason, it is imperative to retain my focus while coding.
I do believe this 'mental sprinting' changes with age. Years ago, coding 12 hours a day for weeks on end was not difficult to pull off. The catch was that a very high percentage of the code I wrote, was either poorly written or bug-ridden and easily could have been written in far less time had I spent more time thinking about the code before I wrote it. As I've gotten older and gained more coding experience, I've found that it's easier to spend a large amount of time contemplating the code, and then writing the code in shorter bursts. The difference is that when I write code this way, far less hours are wasted.
Our minds naturally work in a cyclical nature. Sometimes I'll get excited about a project or idea and I'll want to work sixteen hours a day on it. Other times, nothing seems interesting. To write quality code and keep my efficiency up, I take these cycles into account. I've discovered they're affected by how I react to them. I keep a cache of easy tasks that are part of the larger project, so that when my mental cycle is at a lull, instead of trying to force difficult code out, I can give my mind a rest and perform easy tasks. Debugging code is great for this. Debugging is as straightforward as most people think programming is. The problem is completely constrained, and all I have to do is troubleshoot it. It's almost relaxing. When my mental cycle is at a peak, I'll perform coding bursts up to 16hrs a day. Generally this does not last more than a few days before I start feeling mentally 'burned out.' By working with these mental cycles, I'm able to keep my coding efficiency as high as possible.
I do find that with some projects, I can write code like a mad man much more easily. Others are painfully slow dredging, and I have great difficulty focusing on them. There are also times where I'll spend hours looking at a problem and just can't seem to make any progress on it because I have a degradation of clarity in visualizing the problem or best solution. Because of this, it can vary greatly how productive I am when I write code. I could spend 40+ on one of those mad man sprints, or a much more painful 15 hours of slow dredging.
I've taken all of this knowledge and experience into account and now my plan is, that when I reach 90, I'll just wake up in the morning and fart.
My very lengthy and heavily customized script will analyze the fart and translate it into C++.
"Oh, boy, I wrote another new Operating System this morning!"
by Anonymous:
"If a programmer were a mere implementer, turning specification into code, then he could just work his way through it, from one end to the other, like someone digging a ditch. But if the programmer is a creator, we have to take inspiration into account. In programming, like painting, work comes in cycles. Sometimes you get excited about a project or idea and you want to work sixteen hours a day on it. Other times nothing seems interesting. To do good work you have to take these cycles into account, because they're affected by how you react to them. When you're driving a car with a manual transmission on a hill, you have to back off the clutch sometimes to avoid stalling the engine. Backing off in programming, can likewise prevent ambition from stalling. In both painting and programming there are some tasks that are terrifyingly ambitious, and others that are comfortingly routine. It's a good idea to save some easy tasks for moments when you would otherwise stall. In programming, this can literally mean saving up bugs to fix. I like debugging; it's the one time that programming is as straightforward as most people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x, instead it does y. Where does it go wrong? You know you're going to correct the problem in the end. It's as relaxing as painting a wall."