Slashdot Mirror
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?"
As long as you're interested in what you program, you can easily do it full work days. However it seems like you're doing the usual code monkey job - these effects are what happens when its not fulfilling or at all interesting. Not in your area of interest and not challenging in the needing-to-think-and-solve-problems way, but just to produce code. That's what it basically comes down to.
A friend of mine gets his job done and still plays computer games and codes his own projects at work a lot. Since he gets his work done, it's not a problem (though he hasn't told this). Another programmer I know spends 30-40 minutes breaks playing Civilization or other games he enjoys and his boss knows this and likes it because after those gaming breaks he has unwind, maybe has think some of the problems and gets really good programming done again. But he works at a software house, attends to meetings and is in other ways involved in the business too.
It's no surprise that so many programmers also go as developers later. You get to solve actual problems and do more interesting stuff. When you were a teen, you didn't just program - you developed and spend time thinking what you did. It's no fun if you leave that part out.
To this day I sometimes catch myself working on some interesting problem at home and putting in 30+ hours over three days when I've got some time off from work, because the problem is interesting and there's no one around to make it uninteresting by coming up with changes halfway through, demanding arbitrary things that have no place in the app and similar stupidity.
But when I'm at work building some glorified CRUDified spreadsheet in WEB_LANGUAGE_OF_CHOICE and I can't get two hours of coding in before the specs change or some PHB from another department feels like pointing out that the blue background color is a bit too blue for his tastes or whatever, well I sometimes end up taking a lot of little breaks just to clear my head enough to be able to function at all.
Greylisting is to SMTP as NAT is to IPv4
I am going on 10 years of development, mostly web related stuff. If it is "same shit different day" type of work 20 hours is a good estimate of actual work I get done in a week. However, If I get to work on new and interesting stuff, I can go 50 -60 hours a week easy, but those are rare.
When I was 20, I would program 8-10 hours a day, then go home and code for 4-6 hours into the night.
Now I get distracted before an hour's coding is up. That's why I moved into management.
The cake is a pie
In the right environment on the right projects with the right team....I could easily design, develop, and test for 40+ hours a week and feel energized. Unfortunately that right environment, project and team is very rare.
I think bigger question is how many hours a week are you actually able to program when you consider all interruptions. I rarely am able to program for more hours than my brain is capable of.
When you have managers wanting meetings three times a week (granted, they are short usually), you expect to get a least a few inquiries a day about the code from someone who's not understanding what you are doing, and you work from home and/or you just get called frequently by the Significant Other... all these interruptions break up your day resulting actual concentrated programming being hard to do for any length of time.
I find I probably only spend 10 - 16 hours a week doing solid coding. Another 10 - 16 is spent just thinking about higher level things like architecture or scaling issues or whatever, and depending on the week 4 - 8 hours "alternately stimulating" my brain with related (slashdot) but not directly applicable stuff. The rest is taken up by the aforementioned interruptions.
But I'm not a "grunt programmer" either.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
Thinking is a physical thing, it requires energy, and can tire you out. If your body isn't in good health, you're not going to be able to concentrate for long periods of time without getting exhausted. If you aren't feeding yourself properly, you aren't going to have enough nutrients to keep your brain going.
Now, being in good physical form doesn't mean being skinny: you can have terrible energy levels even if you are skinny, and you can have amazing levels even if you are fat. That said, the easiest way I've found to increase energy levels are first, to get enough nutrients (proteins, carbohydrates, fats, vitamins, fruits and vegetables) so your body can rebuild itself, and second, running. If you can run far, you will be able to program 60 hours a week without a problem. If you want inspiration (ie, extra motivation beyond just high energy levels), check out this book (I've no relation to the author, just found it inspiring).
Whether you would want to program 60 hours a week is a different question.
Qxe4
See above where I said "unless you're working in an orthodox manner". UML is used where UML is used; it is consider "orthodox" (AKA CYA). That's why I said the separation is harder when you're free from that sort of overarching process (which is good for some things, but overkill for many others). Point being: if you find development dull, yet you are in a very Waterfall-oriented organization, then well... might not be the programming part. :)
but usually I only GET to about 10-15 hours, and spend the rest of my time dealing with meetings, documentation, etc. Coding is the fun part.
In Soviet Russia jokes are formulaic and decidedly non-humorous.
You said you usually work about 10-15 hours per week. So that means that on some weeks, you fuck off on the internet for 30 hours a week!?! Sorry you to hear you get "interrupted a few times per day" while Facebooking. You poor, poor thing.
We need to get away from this paradigm of "You must work 40 hours a week" to the paradigm of "You must do this, this, and this for me and I will pay you X." Sometimes we work the full 40, sometimes we work more, sometimes we work less -- the important part is delivering to your employer what he wants. Clearly, asker is doing that or he wouldn't be employed.
I subscribe to the "As long as you're not illegally gambling or moonlighting from your desk, and as long as you're getting me what I need and not bothering anyone else, screw around on the Web as much as you want."
It's interesting how you mention reducing distractions / interruptions with headphones, etc. Here where I work they have moved most people (not me so far fortunately) out of offices and into cubicles. The claim is always that it fosters collaboration and teamwork (while of course the reality is it reduces real estate costs). Interestingly they just started a new deal where they gave people "do not disturb" signs to hang on their cubicle walls. Apparently there was too much collaboration and teamwork going on and people couldn't do any actual work. I did have to go from 1 person in an office to 2 people in that same office but at least we have a door for the "do not disturb".
As I like to tell people when they interrupt me, it takes about 15 minutes to get back into a task. Every time they interrupt me, that counter is reset. So when they come by every half hour to see how well I'm making progress, that means it's taking twice as long. Being that they keep doing it and I expect an interruption every 30 minutes, I stop at about 20 minutes (5 minutes of productivity) and prepare a report of what I've accomplished.
So, in 8 hours, I may accomplish 1.5 hours of work.
Some employers and staff understand this. I end up coming in at my own time (usually around noon), spend the first few hours taking input and answering questions about the progress, and then around 5 I dedicate myself to work until midnight. So 5 hours of chitchat and minimal on-task work, and 7 hours of serious uninterrupted work.
So 7.5 hours vs 35 hours of accomplished work. Which is more advantageous to the company? Quite often I've accomplished a week long task in a single night.
At one employer, they asked me to modify a partially completed application for a new client with new specifications. This was on Friday at 4pm, and was required by Monday morning. They were specific down to what font, size, and layout of the GUI. I said it would take a month or so. They didn't like my answer, so they got the lead developer from the project who talked in circles and finally said it would take a few months if he put his entire team on it. I came back with "I can start from scratch and have it done by Monday morning, but don't expect me to come in til after noon, and no one is allowed to call me all weekend. I'll initiate any necessary communication.". They said it was impossible for me to do that, it took the original team two years to get it to this point. I worked all weekend by myself at home, and at 6am Monday I sent them the finished product.
1 sysadmin who does development for fun 1 weekend vs a team of developers for two years. Hrm. My code was only a few thousand lines. Theirs was a few hundred thousand lines. I considered taking some of their code to use in mine, but it was so chaotic and poorly written that I would have spent the whole weekend reviewing it and fixing it.
The customer was happy, but the boss was pissed at me for some reason. And I was a salary employee, so they didn't even pay me anything extra. The sad part was, it also served almost all the functions of our primary product, which didn't always work right. There was lots of "but you didn't do it this way.", which I followed up with "but this is better, faster, more robust, and made the customer happier."
They fired me a few months later for an arbitrary reason to get me out. Go figure. I think they gave me the impossible task to accomplish in a weekend so I would fail and they could fire me for it. I was given a few other "impossible" tasks, which I accomplished also, before they finally just got rid of me. Hmmm, I did more than the entire development group, by myself, with easy to understand and manipulate code, and they weren't happy.
Serious? Seriousness is well above my pay grade.
>>Also, I find that when you're in the "zone" it's not painful at all. Sounds like you may be working on something you don't enjoy so much? :D
When I'm in the zone writing code, I can easily code for 10 hours straight. However, doing this on a day in, day out basis tends to be wearing from all the focus. When I worked for other people, I found that working about four hours a day when my brain was freshest yielded the best results. Since I was being paid hourly, I wasn't even forced to sit around waiting for five o'clock to roll around. I'd bill four hours and bail out. Got a project that had been budgeted for three years and half a million dollars finished in a summer for (unfortunately) much less money.
This logic is not sound. I remember reading a WW2 manual that warned the officer that if he goes into an area, and he sees men suddenly very busy at his approach, it probably means that they were slacking off while he was gone.
I know many people like that. Since employee/employer is a type of contract, what the employees do is a form of fraud by deliberate misrepresentation/deception. That's why companies pain themselves to come up with some type of productivity metric to measure these things, and in the long term, yes, the company knows whether you are worth it or not.
But going by other businesses, where an employee can bullshit/dupe an employer for a good while because the boss doesn't hang around their shoulder.
To make it easier, just extend that to subcontractor (let's say construction), and tell me they can't steal from the employer. The overall lesson you were putting across stays the same (Caveat Emptor) but leaving the employee without any morale responsibility is the wrong mindset.
(Now, I don't care if someone surfs for a while, you have to accomodate for human nature, but there are various degrees to everything.)
Comment removed based on user account deletion
I've written intranet applications for the US government that had more business rules than I've seen in any other application. One was a rule making system for the FAA. More workflow rules than you can imagine. Those were not easy in any fashion so I'll reserve judgement on the poster.
UML isn't about programming. It's about documentation for large projects that require division of labour. It's about specifying functionality for communication between business experts and the people who get the work done. It's about getting the big picture without having to pour over the whole picture with a magnifying glass (i.e. reading the source code).
Seriously, I might consider contributing to more open source projects with bug fixes if it didn't involve scanning though megabytes of code first to narrow down the source of the problem.
Something that I think Sourceforge or an equivalent repository system really needs is a tool for reverse/round-trip engineering UML diagrams of the projects it contains (i.e. identifying how/where code restructuring affects UML documentation and supporting the update of that documentation). One reason why nobody has actually tackled this may be that Sourceforge projects may contain various combinations of Java, C++, python, C, PHP, perl, etc and UML really works best with object-oriented languages.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
Employees are now working at least 12 hours per day, six days a week, yet the letter claims they are being increasingly disregarded and dehumanized by management.
Working conditions at RockStar
Maybe we need unions again?
-- Political fascism requires a Fuhrer.
UML can be a programming language. It is used in model based software development, which is still mostly an academic discipline, but working its way into industrial applications. The scope is often limited to an application specific language with a classically developed framework or code generator in the background.
One of the problems of classic development is that there is no way to express complex high level interactions in a way which is tied to the actual code. The result is that developers take a long time to familiarize themselves with the architecture by reading "prose" specifications or documentation. That inevitably results in an incomplete picture and diverging perceptions between developers, a problem which is amplified by changes to the specifications, which then also tend to divert from the actual implementation. Over time this creates bit-rot and the code base becomes rigid and unmaintainable, often prompting rewrites.
UML wants to be that high level language, and to fulfill that promise it has to be used as an actual programming language, from which executable code is produced.
I'm biased because it's a hobby of mine, but yes, I could see doing that if the break allows for thinking about drought resistant perennials, planning so that the garden has some interesting blooms each month, and thinking about how to get rid of some bugs that other gardeners are succumbing to. Then again, gardening is a pretty good activity to think while working. As an aside, and it may be observation bias, but I do know quite a few long time programmers who do get into gardening for the mental challenges (we had some folks at the Tech Shop/Maker Fair working on wireless soil sensor equipment).
What constitutes work for a gardner? Is he working only when blades of grass are cut, only when he is moving, only when bushes are being trimmed?
Now, what constitutes work for a programmer? Is he working only when he is typing code, only when reading specifications, only when debugging?
It is hard to imagine that the gardner who works 20 hours a week but charges for 40 needs the extra 20 hours to plan out his next move. Yet, for the programer, the thought process is just as much work as the typing. And the vast majority of programs are the result of thinking done while resting or being distracted. Like a benefactor supporting an artist, the manager pays for the final product, which involves time beyond the simple manufacture of it.
My page.
That is indeed fair system. Keep it honest, and going. Don't ever forget to really reward for getting most done, and if someone fails remember to check the specs, if it was feasible or was the problem elsewhere.
I've been with an employer who constantly gave me more work. He gave me about 6-7months total working time to complete 13month project, which was in the first place under budgeted, under manned effort. He told me i can use couple guys as much as i need, but told them to refuse almost anything but the absolutely most crucial, by keeping their workload and priority list so that i wouldn't get any help. Needless to say that project was late at the time of my departure, but still within 13month hour budget, and 95% complete.
During this time i was given a complete company to look over which was acquired, i was made the manager of network operations. My job also consisted of whole new areas, i also did some sales and customer support. I saved multiple client relationships by pulling aces out of my sleeve by stepping into the project. During the short timespan i was in the company, on paper i was least experienced, least educated, but when i left i had the 2nd biggest responsiblity in the company, directly after the owner & founder of the company. I was involved literally in everything. I worked way too long hours too, at constant sprint speed. It was a reaally lucky day if i got a 10minute break to read slashdot.
I told my responsibilities and workload does not match anywhere near my compensation. I was being paid 30% under average, basic junior web developer's salary. I was laughed at and basicly told to f* off. This despite being just offered partnership, which was used as an excuse for keeping my salary same. Partnership you ask? Yeah, he asked for money. I would have had to buy shares, without knowing if there will be dividends. I was given absolutely no details. I was also invited to the board. Best of all? My salary was so low that i couldn't afford to buy shares. I was living from hand to mouth. Every person in the world needs hobbies etc. to stay sane, so my only choices was to end all my hobbies to afford even proper clothing required for my level. I had only 300e monthly budget for extra expenses. The lowest i've had ever, even unemployed i had more.
Don't become that slaver. There was plenty more wrong in that place, such as working time was accounted at 15minute accuracy, and you were supposed to put almost every single minute of your working time to some client.
Pulsed Media Seedboxes
To those doing all the UML bashing...
Have you ever used it, or more to the point, have you ever used it properly ?
I find it hard to believe that anyone with any experience with it at all would take that stand. It's not because I think it's particularly easier to create a complex object oriented design using diagrams - that depends more on the particular project as well as the experience of the developer. No, the real reason I find it indispensable is that (unlike apparently some of the bashers here) I have to communicate my designs to people that are not software engineers (i.e. customers, managers,etc.). These folks may not even understand the language I'm developing in - or care, but if I've done a good job, they can understand the diagrams.
That macho "real programmers don't use UML" crap doesn't fly with me, and I've been around long enough to have used Rumbaugh, Booch and Fusion before it became UML.
Real programmers (at least any that I would employ) use whatever is the most efficient tool for the given task. You can keep you're "I only program using vi" attitude and get washed out by a college grad or offshore resource willing to work for a fraction of your rate who understands the basic principle that for a design to be good it must be comprehensible by someone besides the designer.
Now get off my lawn!
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
Having worked both union and non-union jobs I can tell you that your generalization of unions is incorrect. A Union is merely a collection of workers. Unions collectively bargain with employers. Yes it means that all members of the Union agree to certain standards, but it does not mean that they are necessarily without any control over their own employment. The Union can bargain for non-salary requirements such as insurance benefits, limits on overtime hours, and safe working environments. Unions can bargain to minimum salaries with out making a stipulation on higher pay negotiated by individuals.
Every time you bargain with, or enter into any agreement, with an employer (accept in very rare circumstances), you are bargaining collectively. The problem is, that with out a union (be it formal or informal) you are not the one with the collective backing you up.
Employers naturally collude to keep expenses low, and that includes salaries. Employees have no such natural collusion as it does not batter to us if our coworkers are underpaid. In many cases people would support their coworkers being underpaid if it meant them getting a slightly larger share because of it.
Unions must exist for capitalism to remain viable. In the past 20 years we have seen the weakening of the power of the established unions, and it may just be a coincidence that this coincides with economic collapse, but I personally doubt the two are unrelated.
A very wise electronic systems guy (use to be a telephone guy before e-systems) once told me. "Always leave at least one thing to do for tomorrow." (when working for an employer)
open source sub sim. I might start coding again for this. http://dangerdeep.sourceforge.net/contribute/
Why do you think that you have the right to waste the employers time and money watching youtube videos, updating facebook and surfing the web. They are paying you to work, not to have fun. Sounds like you're just an asshole slacker.
I might agree somewhat if GP had talked about 25 hours a week or something, but 40-50 hours of true working time a week in a programming job without slacking is bordering between heroic and impossible.
Nobody I know can really program -- or do another similar mentally intensive and somewhat creative work -- very efficiently for even 8 hours a day without having small breaks every now and then. If you don't have those breaks consciously, your brain begins to have small breaks every now and then, your concentration will falter more easily, and you begin to make more mistakes. Even if you think you're constantly working at full steam, your brain probably isn't. The difference is that making those breaks conscious (and not having superiors watching you all the time as long as you get your job done) is a lot more comfortable and less stressful than trying to force yourself through without them to no avail.
Of course there's the occasional case of deep hack mode now and then where you can focus on your single task for hours and hours on end, at least seemingly without loss of productivity, but most people certainly can't keep that up all the time. Perhaps some exceptionally focused people can do it a lot of the time but most people certainly can't and would just be cheating themselves if they pretended so.
For that vast majority of people it's simply inevitable that working 40-50 hours a week (as GP said he did) will mean mental breaks every now and then, much more often than 2x10 min + lunch per day. I'd say that regularly working upwards of 40 hours a week in a programming job doesn't make much sense in the first place, though, for the very reason that most people will have their productivity suffer if they try to do that. They simply wouldn't get much (if any) more work done in total if they tried to do 50 hours per week rather than, say, 35. The total work done would just span over a longer period of time with more breaks and non-productive periods in between, whether conscious or not.
If GP's managers in the job he described didn't understand this, and they were actually monitoring him to make sure he (supposedly, not actually) was getting things done all the time, they were fighting against the very reality and were doing so at GP's expense, and probably also at that of the employer because GP wasn't at his most productive. I fully understand his frustration with the situation.
An anecdote is always just that, but sometime last year I was working part-time around 25-30 hours a week on a project (mostly non-programming, though, but in a software project nevertheless), and if I wasn't at the most productive I've ever been, I was at least damn close to it. That is, I've got more things done within an single week than I got within a single week at that time but the productivity I was able to sustain for a few months was almost certainly higher than that of any other period of similar duration. I was highly motivated and was working pretty intensively and productively (not entirely without surfing/youtube/whatever breaks, but with relatively few of them, and with strong concentration), but I certainly couldn't have kept the same pace for even 35-40 hours a week, much less 50. I'd probably have got less done in total if I had tried to do that. If someone had forced me to do that and expected me to do it without any slack, they'd have also shot themselves in the foot, not just me. My managers were smarter than that.
I appreciate high motivation to work but it should be motivation towards getting things done, not towards sweating your ass off. The amount and quality of "done" in a programming job doesn't scale with the amount of effort infinitely, and maximising the latter rather than the former just makes no sense.