How Many Hours a Week Can You Program?

An anonymous reader writes "How many hours a week should a full-time programmer program? Trying to program anywhere near 40 wears me out. On a good week, I can do 20. Often, it is around 10 or 15. I'm talking about your programming session at the console, typing — including, of course, stopping and thinking for a minute, but not meetings, reading programming books, notes, specifications, etc., which by comparison feel like lunch breaks. I rarely get called to meetings (which is good) but that means to keep my brain from overheating I spend several hours a week surfing the web (usually reading tech news but also a few stops on Facebook, email, etc.). I should add that I am interrupted a few times per day. Me and another guy maintain an intranet site of a couple dozen web apps for an IT department, so we work on a few different things: phone calls, bug fixes, feature adds, as well as writing new web apps from the ground up, all in a day's work. And I know that wears a person out more than if they had just one project to work on. I wonder if programming is like mental sprinting, not walking, so you can only do it in bursts. Am I normal or stealing?"

Comments

Re:Programming

[unother]

What he said. Exactly.

Re:Programming less effort than surfing the net

[MrEricSir]

Well isn't that special!

Does this help!!

[omar.sahal]

Paul Graham notes..

If a hacker were a mere implementor, turning a spec 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 hacker is a creator, we have to take inspiration into account.

In hacking, like painting, work comes in cycles. Sometimes you get excited about some new project 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. Backing off can likewise prevent ambition from stalling. In both painting and hacking 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 hacking, this can literally mean saving up bugs. I like debugging: it's the one time that hacking is as straightforward as 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 win in the end. It's as relaxing as painting a wall.

Luminaries such as Jamie Zawinski and Richard Stallman work long hours. Richard Stallman worked 70 hours a week creating GCC in the 80s. There is an Arabic saying "If you want to surpass others you have to burn the midnight oil" I suppose that's why their the best.

Re:Programming

[rockNme2349]

FAQ

Be Original: Avoid being redundant and just repeating what has already been said. Smirk. Yes, being moderated as "redundant" is worth "-1" to your post and your karma. Especially to be avoided are the "what he said" and "me too" posts.

Take note of the first quoted comment to avoid. I understand that you feel like his description matches your experience, but you haven't added anything to the conversation. Your comment was certainly not harmful, but it wasn't helpful. Hence the Redundant moderation. All you need to do is say What he said, and then expand on your situation and you have a recipe for an insightful post. Also if you really want to make sure you get moderated well, add in a "I know i'll get modded down for this but...". Moderators love that shit.

What Its Like for Me As a Programmer

[Shouden]

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 Oper