Forgot your password?
typodupeerror
Programming IT Technology

Do Long Work Hours Affect Code Quality? 911

Posted by Cliff
from the unreasonable-management-expectations dept.
tooTired asks: "At my company the owner is heavily implying that the development staff needs to start working longer hours and weekends to shorten the time-frames on our current projects. The exact quote is 'These 8 hour days have to stop, we need to be working 15 hours a day and weekends, balls to the wall.' We are heavily under-staffed even with my multiple attempts to show the owner that we need more resources. My general feeling is that long hours is generally a symptom of poor project management, and not something to be sought after. I wanted to ask the Slashdot community their opinions on how working long hours during the week and weekends affects the quality of the code they produce, and the overall success of the project." A large reason why many in this industry find themselves working long hours and weekends is that management makes unreasonable expectations and deadlines. Are there ways of communicating to management that long hours to rush a project to completion is not the way to complete a successful project? Update: 08/30 23:11 GMT by C :Grammatical errors in title, corrected. Sorry about that.
This discussion has been archived. No new comments can be posted.

Do Long Work Hours Affect Code Quality?

Comments Filter:
  • Eh? (Score:2, Funny)

    by doublesix (590400)
    Long hours seem to affect spelling.
    • Hmm... (Score:3, Interesting)

      Long hours dont affect code quality, employees ambition affects code quality! If its late and im working on a project (personal) that i enjoy, and im way tired, i still code fine. If its something my hearts not into it then i wont be able to work. My suggestion to employers: Pay lots for overtime and reward good coding with acess to a "special fridge" filled with energy drinks and jolt!
      • Time has to be provided for adequate rest (sleep), and also some form of exercise needs to be done, walking, bicycling, not just pumping iron, or working out with an exercise machine. A lunch hour, actually about an hour and 20 minutes, spent walking will improve the overall health of the person. Remember, we are a human animal, and not a machine. The health of the circulatory system, lungs, needs to be maintained. Sure, if one is on a roll as far as coding goes, then spend the time working, then rest. Otherwise, the health of the individual will eventually suffer, and the employer will only get new employees to replace those who come down sick. Bicycling is dangerous, but gives enormous benefits. When you go up that first long hill, you'll spout cuss-words, etc. as you work to get up there on that bike. When you get to the top, and you back off, and start to yawn, that's when you know that you have done all you can for your heart, lungs, and circulatory system. Coast for a while, then go after another hill. Be sure and get a reliable bike, one that the gears and transmission won't slip when you press it hard. These cost several hundred, but you'll love the thing. Watch what you eat, and you'll soon begin to lose weight. It's your health, not your employers. Eventually, you'll be replaced in your job, and you want to have your health when you leave there.
        Oh, btw, hope you don't smoke, or all bets are off.
      • Re:Hmm... (Score:5, Interesting)

        by sphealey (2855) on Friday August 30, 2002 @07:55PM (#4174118)
        The nuclear power industry has done extensive studies on this subject. Tradition in the industry (partially the electric utility industry; partially coming from ex-Navy guys) was to work long shifts - 24 and 36 hour work days were not uncommon.

        The conclusion of the studies was that people become increasingly ineffective after 10 hours per day, and very ineffective after 12 hours per day. BUT - they don't realize it. If they are "motivated" they think they are doing fine at hour 16 or hour 20. Objective testing shows that they aren't.

        And similarly, anyone can work one or two 16 or even 24 hour days. But after a week of 16s, or ever 7 straight days of 12s, performance again drops significantly.

        But hey, since your project won't hurt anyone else if it melts down, go ahead and work those hours!

        sPh

        • Re:Hmm... (Score:3, Interesting)

          by langed (142123)
          A small anecdote to relate to the article:

          At my university, we installed a computer-controlled train lab. It was the first semester of the course, so we students were put in groups of three "in order to be more effective software pioneers." My group was unfortunate in that one student dropped the class, so we were shorthanded. Then another student decided to focus on his senior project. So from a group of three, I became the only student in my group writing code.
          I was the only student in the class with experience with electronics and device drivers, and several years experience with linux. So I got to be the volunteer sysadmin in addition to course assignments, and additional code that would be provided to the other students in the class; it was assumed that they would not be capable of writing device drivers, and these were outside the scope of the course anyway.

          Long story short, at least 5 nights per week were tied up in that computer lab (the other 2 nights were long nights at a part-time job), keeping the machines going, performing backups, fixing windows and linux interoperability problems, and coding the drivers that were passed out free to the rest of the class. Since we were given keys to the lab, I came in any free moment I had, and worked until I passed out and fell out of my chair, only to be found unconscious by the professor the following morning. Then I'd get up and go at it again.
          I got sick frequently, but came in anyway. I was in the only group that didn't have a working program to control up to 3 trains running the tracks simultaneously, and my code was errorprone and buggy. The other teams actually had to code failsafes for contingencies when my device drivers actually failed.
          My attitude changed that semester, much for the worse. When repeatedly accused of being severely sleep-deprived, I responded with "Sleep is for the weak! It's an addiction! The addiction should be broken!"
          But even the professor, for whom I was putting in so much effort, accosted me of pushing too hard, and getting nothing done. I was then enlightened of the cliche "diminishing returns"--you can keep putting effort in, but without proper rest, you'll get less and less back out.
          On the other hand, this rather lengthy post (and its likely incoherent babblings) comes from the bleary-eyed eyes of someone working on a goofy kludge of socket programming in C to interface to Java applets. Thing is, I have no control of how many users can connect, so I must assume that there can be thousands of simultaneous connections.

          Oh how I long for the days of sysadminning--I got more sleep as a sysadmin than I do as a programmer!

      • Re:Hmm... (Score:3, Interesting)

        by Anonymous Coward

        I certainly did not like my programmers working extended hours; at least not routinely. It made them tired, irritable, and a pain in the ass to have around the office. The code got sloppy, too.

        As for deadlines, I found the way to achieve them was to have the deadlines set by the coders and tie their bonuses to the quality of code and ability to deliver it on time. When I did that, the deadlines were met and the bugs largely went away. Obviously, you need to know enough about the technical aspects of the project to tell if they're blowing sunshine up your ass.

        I found that to mitigate extra hours, I let the programmers work from home via VPN and I kept track of the extended hours to comp them extra time off. To be honest, some of the most productive days had all my coders at their houses VPN'd in and conference calling to work out issues. Some worked at night, some early in the morning. They worked out their stuff between them. As long as good code flowed, it didn't matter.

        Not bugging the programmers is the number one key to good code.

        I never felt that the programmers really had a large enough equity stake in the company to justify working extended hours.

        It's a professional thing. Pay people well for doing their job well. Give 'em a cost of living raise for simply doing their job well. After all, that's the expectation; it's why they're paid. They shouldn't make less each year for doing a good job. Give 'em a raise as the market and their knowlege makes their talent more valuable. Bonuses are for extra effort. Can be equity (if it's worth anything). Can be more vacation if cash is short. Cash is good too.

        But long hours with no real equity stake? Screw that. Sounds like someone has some project management issues. Get out as fast as you can.

        Just my 250,000 pre-IPO options (or $0.02, whichever)

        And lay off the spelling, it's late and I don't care.

        • Re:Hmm... (Score:3, Interesting)

          by dubl-u (51156)
          I certainly did not like my programmers working extended hours; at least not routinely. It made them tired, irritable, and a pain in the ass to have around the office. The code got sloppy, too.

          That last one is the real killer.

          Whenever I see one of these if-you-aren't-sweating-you-aren't-working projects, I can guarantee that they will spend a lot more time fixing bugs than is sane. Of course, many of those bugs won't surface until the last part of the project, so it looks like more progress is being made.

          This is the same mistake a lot of people make with credit cards. For the first few months they have them, they're rich! And then suddenly, they're screwed; all their income goes to interest charges, so they're suddenly poor. Some people will make minimum payments for years; some will just declare bankruptcy; a very few will get a clue, pay off the debts, and then never use credit cards again.
  • Simply, no matter what business your in, you start making poor decisions when your tired. Code quality is gonna drop.
    • Re:Yup (Score:3, Interesting)

      by netruner (588721)
      I always understood that people don't do much more than about 8 hours worth of work per day regardless of how long they're at work. 8 hours was defined as a work day for a reason- it's the point of diminishing returns.

      Also - driving your employees like sled dogs will cause them to look for employment elsewhere, and if you don't think that will effect your code quality, you shouldn't be leading a pack of cub scouts, much less a project with a real product.

      The biggest problem with management is that they make decisions they aren't qualified to make. I see it time and time again- it only takes one PHB shooting his mouth off to get the whole development team 6 months behind before the project even starts.

      Sorry- managers are like alcoholics- you can't tell them they have a problem because they think you're out to get them. This is particularly bad in technical jobs because managers that were promoted from within have poor social skills which are necessary to be a successful manager.
      • Re:Yup (Score:5, Informative)

        by Lemmy Caution (8378) on Friday August 30, 2002 @07:55PM (#4174117) Homepage
        8 hours was defined as a work day for a reason- it's the point of diminishing returns.

        No, eight hours was defined as a work day in the US because of the efforts of the labor movement, beginning the middle of the 19th century and, after a great deal of struggle, culminating in FDR's passage of the National Industrial Recovery Act, which was then struck down by the SCOTUS, and then partially replaced by the Wagner Act. The eight-hour work-day came at the expense of workers who were beatened, imprisoned, and killed trying to win it.

    • by gweihir (88907)
      Code quality is gonna drop.

      Strategic thinking will not happen.

      Tactical decisions will most likely be severely flawed.

      In short the most important factors for success will simply go out the window.

      My advice: Leave this company now. There is nothing to be gained by staying. You do not own them any loyalty if they are willing to run you into the ground. While you are still fit and healthy you have a much better chance of getting a new job than after the first breakdown. Such a breakdown can take years to recover from.
  • by 3waygeek (58990) on Friday August 30, 2002 @06:56PM (#4173715)
    but they obviously affect the grammatical skills [dictionary.com] of the editors.
  • Agreed (Score:5, Interesting)

    by SirSlud (67381) on Friday August 30, 2002 @06:56PM (#4173716) Homepage
    Humans are not machines. You simply do not up the hours that they are 'on', and it works.

    Nevermind code quality - what about burnout, resentment towards management, and seeing domain knowledge go out the door when coders get sick of working 15 hour days and leave for another company?

    15 hours? He's not serious, is he?
    • Who cares about burnout? When one lot of programmers is burnt out you just hire a bunch more cannon fodder from the nearest University. The younger you pick 'em the harder you can make 'em work.


      OK, I admit I don't actually approve of that point of view, but it's the attitude many companies take.

    • Re:Agreed (Score:5, Interesting)

      by Albanach (527650) on Friday August 30, 2002 @07:06PM (#4173810) Homepage
      Indeed, in Europe if they had you working 15 hour days, you could go home at 11am on the Thursday and not return to work until the Monday.

      Why? Because the European Union protected its workers by introducing the working time directive which emans the maximum hours you can be contracted to work is 48 per week - you can work longer if you wish and agree, but no employer can force you too, and if you decide not to there's not a thing they can do. Even if later they decided not to promote you on that basis you could take action against them.

      Usually I'd be cautious about such intervention, but certainly here I have to agree that it's to everyone's disadvantage being forced to work these crazy hours - I've done it myself and veryone loses - employer, employee and families.

    • Re: Agreed (Score:5, Interesting)

      by Black Parrot (19622) on Friday August 30, 2002 @07:37PM (#4174019)


      > Humans are not machines. You simply do not up the hours that they are 'on', and it works.

      I was never interested enough in this to read up on it, but supposedly there were studies several decades ago that showed that the total output for a week's work peaks at some certain number of hours and rolls off after that - even for jobs like construction work. I don't remember the exact number (and it probably varies by trade), but it was certainly less than the 15 hours/day that his idiot ^w boss ^w idiot boss is wanting.

      From personal experience, I'd say that for a steady-state arrangement my gross productivity (i.e., total per week rather than total per hour) peaks at around 50 hours a week. I can be productive throughout a 12 or maybe even 14 hour day if I do it occasionally, but for a steady-state arrangement I think I actually accomplish less working 12-hour days than I do working 8-hour days. I would guess that working 15 hours/day would be about as productive as working 3 hours a day.

      With apologies to Brooks, I conjecture that suddenly doubling the working hours would hurt productivity as bad as suddenly doubling the staff, if not more.

      Also, I notice that the asker describes his boss as "owner", and my experience with Pa & Ma shops is that the owner/boss is often running the business more as an exercise in ego than in economics, so he might want to ask himself whether the suggestion isn't more a raw demonstration of power than an attempt at economic efficiency.

      All this is speculative, of course. But anyone interested in this stuff might want to look for some published reports on hours vs. gross productivity, and also reflect a bit on the underlying motives for management decisions when manager=owner.

      • I can't remember exact sources, but I'm pretty sure one of the published papers last year showed that you actively become less effective as a software developer (you introduce more bugs than you fix, etc.) when you've worked more than 48 hours in a week. There was very little direct benefit found to working more than the 35-40 hours that are actually in most contracts, and the drop in morale and loyalty is probably more significant.

        In contrast, there were a few interesting case studies where software houses tried working with significantly shorter hours; I can't remember for sure, but wasn't one of them reported here a few months back? I distinctly remember one company (somewhere in northern Europe, IIRC) which trialled a 30 hour work week. Their productivity rocketed, as their staff came in, worked a solid three hour morning with full concentration, took a comfortable lunch break, worked a three hour afternoon also with full concentration, and then had time left to do anything else they needed. No-one spent the whole day calling the bank or landlord or writing personal e-mails, because they had time to do that stuff after work. And of course, the morale and loyalty of the staff were fantastic, with a near 100% retention rate after introducing the reduced hours.

      • Re: Agreed (Score:4, Insightful)

        by BoneFlower (107640) <george@worroll.gmail@com> on Friday August 30, 2002 @09:40PM (#4174559) Journal
        ". I don't remember the exact number (and it probably varies by trade), but it was certainly less than the 15 hours/day that his idiot ^w boss ^w idiot boss is wanting."

        The average person needs 8 hours of sleep a night. With 15 hours of work, that leaves one hour(on both ends of the sleep cycle, combined!) to shower, shave, and commute. Granted, many people can go with less, but over time it will take a toll. 15 hours+ is fine in the rare extreme circumstance, but not as an everyday thing. How many people at this place will get fired for falling asleep on the job? Quite a few. And several others will start getting sick from the long hours, junk food eaten to stay up... In todays job market, leaving the company may not be an option...
    • Re:Agreed (Score:5, Insightful)

      by iabervon (1971) on Friday August 30, 2002 @08:57PM (#4174401) Homepage Journal
      Solving the problems underlying the code is the interesting part. The rest is just typing. Solutions to problems just come to you while you're sitting around after being exposed to the issues involved in the code. Your subconscious gets engaged and will come up with ideas creatively. Sitting there increasing the size of the program actually inhibits this, because you're distracted by the details and can't think of the abstract concepts.

      Development work, therefore, is done in the 16 hours/day that you're not there. It will therefore halve your output (in terms of solutions to problems) if you're only not there 9 hours/day. If the job actually demands 15 hours/day of sitting at the keyboard working on it, it's data entry, not programming, because you don't have enough time to think about the project.

      I generally get to work with my head full of ideas, and leave when my head is empty and I have no more thoughts about the project. (Actually, I'm lazy, and leave a while afterwards. But I stop getting anything useful done when my head is empty.)

      Debugging, on the other hand, works differently. The problems are small and self-contained, and your time is spent searching through the codebase, not thinking about how the project should go. There are a lot of bugs you'll only find by actually staring at the code, because the bug comes from some code not doing what you think it does; thinking about what is does won't help. There are still bugs that you won't find until you relax, though, so you can't go on forever. It's somewhat reasonable to have a 20-hour day on occasion, where you're fixing a lot of things that don't quite work, but you won't improve the functionality of the project much, just whether it works or not.

      "That's a good question. I'll have to sleep on it." (Three weeks pass) "Why haven't you answered my question?" "I haven't gotten a chance to sleep."

      On the other hand, a 15-hour work day could be reasonable if your work has really comfortable couches...
  • by gatesh8r (182908) on Friday August 30, 2002 @06:57PM (#4173721)
    "Do stellar objects really emit light?" and "Does unoptimized code really run slower?"
  • Walking Papers (Score:5, Insightful)

    by forkboy (8644) on Friday August 30, 2002 @06:57PM (#4173725) Homepage
    If the unemployment rate isn't too bad in your area, I'd be telling them to suck your balls.

    There's no excuse for an employer to consistently demand 15+ hour days and weekends. Once in a great while, when an important deadline is coming, sure it's a reasonable request, but a consistent basis? No way man...don't let yourself get trapped into that. You'll burn out and find yourself embittered against working at all. (I'm speaking from experience)

    It sounds like this company is a poorly managed failing startup and probably isn't long for the world anyway. Quit while you're ahead.

    • If the unemployment rate isn't too bad in your area, I'd be telling them to...

      I got a better idea: Go in there with a loaded shotgun, blow away the receptionist, your boss, and whoever's at the water cooler, and then turn the gun on yourself. Your message will be heard loud and clear all over the evening news, trust me. Also, it's very important that you kill yourself, or the press will paint you as some kind of deranged office killer without mentioning the note you've left on your dresser stating the 15-hour day made you do it.

      Wait, you don't work where I do, do ya? Nevermind everything I just said if you work in Seattle.

      Good luck on the rampage!
  • by Renraku (518261)
    Long hours do affect the quality of code you write. If you're not tired, you'd be more inclined to take the safer, slower way around rather than the faster but unsafe methods. Ever wonder why buffer overflows seem to appear in all types of software?
  • Just quit. (Score:5, Informative)

    by autopr0n (534291) on Friday August 30, 2002 @07:00PM (#4173750) Homepage Journal
    Don't burn yourself out for this wanker. 8 hours a day is a totally reasonable limit for a job

    Sure, sometimes coders spend a lot more time then that on their job, but that's because they enjoy it, because they want to spend that time working on code for their job.

    If your boss is demanding you work 15 hours a day, quit.

    Will it affect code quality? I don't really know. In the short term I doubt it, actually. Will it affect your quality of life? Absolutely. Will it affect employee satisfaction? Probably, and down the line that will affect code quality. If you don't like your job, you're code will definitely suck.
  • by 1010011010 (53039) on Friday August 30, 2002 @07:01PM (#4173763) Homepage

    Executives don't like reality. They are all about wish fulfillment. When your project(s) are not completed by their deadlines, you will be fired. You will be the one who has to pay, because you were the one repeatedly pointing out that you needed more resources, given the requirements and deadlines. You contradicted your executive's worldview. In any competition between reality and an executive's world-view, the executive wins, in the short term. Reality always wins in the long term.
    • by evocate (209951) on Friday August 30, 2002 @09:52PM (#4174599)
      Why does the owner need the development staff to work 15 hour days and weekends? I bet it's because the business plan or market position sucks and the owner is a stubborn brick who cannot accept his failures and shortcomings. He "needs" you to do the impossible because if you don't then his failure at business planning will be on display for all to see. Of course, he won't see that his stupid plan failed. He will see that his development staff failed him, and he will fire them in disgust. Do yourself a huge favor and find something better to do.
    • by DarkEdgeX (212110) on Saturday August 31, 2002 @01:41AM (#4175278) Journal
      Insightful doesn't even begin to describe your post-- I'm living proof of what happens when management expects more than can be realistically be given. A team of 3 developers were tasked with creating an app in 3 months; complete and ready to roll out (bug checked and the whole works, by the same 3 developers). I told them it wasn't possible and was told it WOULD happen and we'd work extra hours to get it done.

      They were so certain of this that I gave up debating the topic, and when month 3 rolled around, lo and behold, NO SHIPPABLE PRODUCT. 2 of the 3 developers were asked to resign with severance pay. I will NEVER accept that kind of shit from management again-- next time it'll be "I work 8 hours a day, and if you don't like it-- too bad!".
  • Good Resource (Score:5, Informative)

    by philovivero (321158) on Friday August 30, 2002 @07:01PM (#4173764) Homepage Journal
    Most of the arguments you'll see in this discussion have their start in Extreme Programming.

    Here's a good reference: Forty Hour Week [c2.com] on c2.com, which seems to be the best web authority for Extreme Programming discussions and patterns.

    Give it a gander.

  • If you want high quality software you need solid processes, smart analysts, and mature programmers. That's how NASA does it. [fastcompany.com]

    What you boss wants is cheap software. He wants a few people to stay all night and write it quickly. You can make a play that cheap software is only cheap in the short run. You can explain that the reduced customer sastisfaction and maintanence costs will prove that doing it right the first time is a better idea.

    However, I'm guessing it won't work. Your boss probably knows what he's getting and he wants it.

    Vanguard
  • Get a new job. . . (Score:5, Insightful)

    by AlaskanUnderachiever (561294) on Friday August 30, 2002 @07:03PM (#4173784) Homepage
    I hate to say it but

    GET OUT WHILE YOU STILL CAN!!!

    I mean good lord man, you're telling me every symptom of every business that I've seen go under locally. The whole "balls to the walls" syndrome is often more of a "we're cutting budgets that we really shouldn't" syndrome. I fully expect that you'll find that the same managers that are willing to have YOU (not them) put in 15 hour days are also the ones willing to say "sure we can do X+Y at the budget for just X" to his higher ups just to look better.

    • At K&S they demanded my dad work manditory overtime for a robotics project. They laid the entire staff off at the completion of the project.

      2 good friends of mine programmed for a local game firm. They worked manditory overtime and were laid off at the end of the project.

  • by nick_davison (217681) on Friday August 30, 2002 @07:04PM (#4173788)
    While, short term, it can work, it sounds as if the owner thinks this is the way to simply work from now on, regardless. That being the case, he really is demonstrating massive failings as a workforce manager. Even if you guys ship the next product or two early, and keep the company afloat for a few more months, in time the moral effect, the exhaustion and all the rest will kick in and he'll be getting worse, not better, productivity. If he's really making those kinds of shortsighted decisions, and he's the owner, the company is going to sink one way or another anyway - it just might eek out a few more months at the expense of a bunch of burnt out programmers.

    My advice would be to use those seven extra hours in front of a PC to tidy up your resume and get it out there. You are going to be looking for a job soon enough, you might as well get the headstart.

    Ask yourself, how many dotcom tales of people agreeing to work without pay for a while; work long hours; all the rest of it, you've heard. Now, how many of those companies actually survived by doing that? Next to none?

    • by gwernol (167574) on Friday August 30, 2002 @07:18PM (#4173918)
      Ask yourself, how many dotcom tales of people agreeing to work without pay for a while; work long hours; all the rest of it, you've heard. Now, how many of those companies actually survived by doing that? Next to none?

      Of the dotcoms, practically none, but then none of the dotcoms that didn't work that waysurvived either. Conversely, look at the older Silicon Valley companies that did make it. How many of those were born from huge efforts by their staff? Apple. Cisco. Palm. Intel. HP. Sun. The list goes on; all companies that were and/or still are legendary for the long hours they expected of their employees.

      This doesn't prove that long hours are a good thing, but there are at least counter-examples to the claim that this approach never works out.
      • by Stephen Samuel (106962) <`samuel' `at' `bcgreen.com'> on Friday August 30, 2002 @08:15PM (#4174206) Homepage Journal
        Apple, CIsco, Palm, etc, worked their employees long hours, but it was long pampered hours. -- and most of those employees had stock options which meant that they shared in the profits that came from those long hours.

        This guy looks like he's walking into a sweatshop environment.. Long hours, little recognition, bad project planning.....

        It's the bad project planning that really gets to me. It's the expecting the employees to be slaves and happy about it. It's the sinking ship, and you better find a raft now feeling to this whole scenario that has me wanting to scream.

        • Get you resume out there NOW!
        Either everybody burns out before the project's finished, or they get fired after it's finished, or they're going to expect you to do it again with the next project.

        In either case, you'll be short a job, a life, or both.

    • Ask yourself, how many dotcom tales of people agreeing to work without pay for a while; work long hours; all the rest of it, you've heard. Now, how many of those companies actually survived by doing that? Next to none?

      Now ask yourself how many of those unemployed coders would be more than happy to take your job when you get fired for not putting in the overtime?

      I'd say it's funny, but it's actually really depressing. During the boom, people were worked to death because of the emphisis on short-term stock gains (lower employee costs == higher profits.) After the bust, people are being worked to death to try and keep companies afloat (lower employee costs == longer run-time on fixed ammount of $$)

      It's very hard to challenge what people believe to be true, be it management theories, religion, C++ vs. Java, whatever. All the statistics, reports, copies of Peopleware you wave at your managers won't make a difference if they believe "more work" is the magic bullet.

      And unfortunatly, sometimes it's the only bullet available. Time Slip = Lost Chance at Revenue, Feature Slip = Lost Customer, etc.

      ObRandomOnTopic: My company sent us all an email earlier this week saying the upcoming long weekend was to be treated as a "normal weekend," i.e. you are expected to be at work. Feh.


  • Sometimes putting in the extra work is worth it; but, if the end of the project is a long way off, DONT.

    If you put in the extra hours now, will it reduce the extra hours later? Again, if so, fine, otherwise, NO.

    Why? Because if the project manager gets it in his head he can have 80hr weeks out of everyone he will plan them that way. It is very easy to become burned out and few managers know how to properly handle it to prevent that.

  • Are there ways of communicating to management that long hours to rush a project to completion is not the way to complete a successful project?


    What about the many stories of caffiene-addled coders working 36 hours at a time, and sleeping under their desks, coding under pressure to get the job done on time? See here [jwz.org] for a good one.


    I mean yeah, most normal people want to work 8 hours a day. But others want to be supermen, and are willing to put in long, long hours of work to beat the competition.

  • by EvilTwinSkippy (112490) <yoda AT etoyoc DOT com> on Friday August 30, 2002 @07:05PM (#4173801) Homepage Journal
    Every project that goes down that path ends with the development team being laid off.

    Don't walk away from this situation, run.

  • by antis0c (133550) on Friday August 30, 2002 @07:06PM (#4173804)
    You're damn right it affects coding quality, and work quality. How can I be expected to work well, with a clean mind and plan if I no longer have my own personal life.

    These 8 hour days have to stop, we need to be working 15 hours a day and weekends, balls to the wall.

    The company doesn't own me. Period. If I heard that statement from my boss, I'd be in my car and on my way home before she had a chance to even blink at me. Despite I do frequent Slashdot, I have a life outside work. When I get hired by X company, I didn't sign on so I could spend my every waking hour and moment working for that company. Any manager who doesn't realize an employee has a life outside the company isn't qualified to manage employees. Period. ..8 hours day have to stop.. BULLSHIT. Period.
    • by evilpenguin (18720) on Friday August 30, 2002 @07:39PM (#4174030)
      If you worked in programming or engineering in the 1980's, you are conditioned to fear for your job. There was a long drought in these fields in the 1980's because massive downsizing by the "big, stable" companies threw thousands of competent professionals on the market at one time. If you are younger than this, you are used to a job market so hot that you can just walk into another job. With the economic slowdown of the last two years or so (the dot com bust, followed by the post 9/11 uncertainty) I'm not sure what the market is like. Clearly, if employers are feeling willing to demand this, they must think the market is tighter than it has been.

      If I were in a more cynical mood, I would suggest that you contact a lawyer and see if "balls to the wall" was evidence of a sexually hostile workplace.

      Personally, I think software development management is of generally poor quality. This is due to a combination of management ignorance, poor engineering practice, the intangible nature of the product (its much easier to explain sensibly why designing, tooling up for, and manufacturing a widget takes a long time), and underestimation by the rank and file developer. If I had the magic bullet for this problem, I would not still be a mortgage-holding software developer, I would be a very highly paid consultant and regular pundit quoted in the trade rags.

      I'd walk out the door too, if I knew I could.

      Tip for the youngsters: Buy less house than you want. Have six months salary in the bank at all times. Then you can storm out in high dudgeon like antis0c suggests...
  • are mostly a myth. I have got the feeling that the ones who spends 14 or so hours per day do not actually WORK for more than maybe 2 * 3 hours seriously. Many people have their lives at work. In some cases this works and in some cases not, atleast it requires strong self-discipline to keep the "playing hours" in control.

    How it affects code quality - don't know. In my case, if I work for around 3 days for around 19 hours and WORK seriously most of the time, that might work, but after that there is a steep decline in quality and productivity. If I HANG AROUND at work for the same amount of hours per day, I can do it for weeks.

    So, I don't have an answer, but I quess it depends strongly about whether you need to concentrate on what you are doing a lot or not.

  • If they want 15 hour days, and they say you need to go "balls to the wall", then that just means that their balls are right up against the wall. These guys probably have a lot more to lose than you. Apply a little pressure, see what happens. Rally the other engineers together. And don't do the long hours unless there are serious bonuses or prospects of equity (and the equity has the potential to be worth something).

    Above all else, remember, you can't do this forever, 15 hour days don't mean twice the productivity.

    I heard a story about someone on deck at a big 5 consulting firm. They worked 100+ hour weeks and all to make partner, and eventually worked until a lot of the systems in their body up and quit. Just overstressed for so long, everything started to shut down at once. Went way over the million dollar lifetime healthcare cap (the firm has to pick up all future medical bills.) The guy made partner and recovered but became a medical case study.
  • If you enjoy the work then work as hard as you want.

    What I would do is not make a big deal of it but make sure you do your 8 hours and go home. If anyone tells you to do more hours tell them politely no. All the time look for another job.

    I assume the owner is the first to arrive and the last to leave?

  • Long hours... (Score:3, Interesting)

    by steppin_razor_LA (236684) on Friday August 30, 2002 @07:09PM (#4173839) Homepage Journal
    I've managed a number of development teams over the years. Here are some of my thoughts. Flame away if you want.

    Sometimes, there are days/weeks where it is neccessary for the team to put in some unreasonably long hours in order to get the project done. Especially during the time immediately before a release/launch.

    That said, when I ask my staff to put in long hours, I'm there with them. If the team doesn't need "management", I roll up my sleeves and do whatever needs to be done whether that is coding, infrastructure work, or being an HTML monkey.

    I don't think it is reasonable to ask for that sort of performance on an ongoing basis or for an extended period of time. It is very draining.

    I also think it is very important for both myself and the organization to show it's appreciation for the people who make these sort of sacrifices for the company. This includes:

    When people are running late, pay for the pizza. Look for other ways to be considerate.

    Have some sort of launch festivities. Celebrate your success. Publicly acknowledge (preferably -- not just within IT) the people who made it happen.

    I think that if management and the company treats its employees reasonably well, that the techies should be willing to work their assess off and burn the candle at both ends when needed.
  • Of course long hours degrade code quality. When you have to trade in the Dew for serious, non-carbonated amphetimines in order to meet a deadline - something's gonna suffer.

    No - really.

    Anyway, my company recently changed our development style to take some pressure off the engineering staff. Whereas previously, 14 hour days were somewhat the norm, those have now been seriously reduced. Those with famlilies actualy get to see them. Those without, get to play Final Fantasy X until 4 AM. Overall, moral is better, and there's not been a signifigant change in output - and the quality is improving.
  • The best option... (Score:3, Informative)

    by The Good Reverend (84440) <michael@nOsPaM.michris.com> on Friday August 30, 2002 @07:11PM (#4173848) Homepage Journal
    The best option, if you can afford it, is to quit and get a better job working for sane people. Sometimes, you'll need to put in a 15 hour day. It's unfortunate, but deadlines happen. But to be expected to put in 15 hour days EVERYDAY is absurd and insulting. You have a life outside of work, you need sleep, and you have rights under the law.

    Back on topic, working 15 hour days WILL affect your code quality, not to mention your quality of life. Different people have different ways in which they work best, and sometimes a long coding session can work wonderfully, but over the long term it will result in frazzled nerves and bad code.

    If he's expecting you to work 15 hour days, you need to let him know you should have twice as many people working 8 hour days instead. If he protests, drop that job like a bad habit. You'll only be hurting your health and sanity if you stay.
  • My experience, after more than 6 years working in Silicon Valley, is that sustained periods of long hours can be damaging. But short bursts to hit a specific project goal can be a good thing. Programming - when done well - requires huge concentration. You have to focus hard on the code. Once you're in the swing of it, you don't want to be interupted. That's why the culture of long and eccentric hours has grown up - its the way good engineers usually work.

    As a rule I figure you can sustain two or maybe three major bursts of 100 hours a week. Each burst shouldn't last more than 5 weeks. I once did a ten week burst and it nearly killed me. Once you go over 5 weeks, you'll get into serious counter-productivity.

    Its also important to have a good reason to do so. If your company doesn't have the cash or revenue to hire more people and needs you to put in the hours to get a revolutionary new product out, that's one thing. If its poor planning or management that causes the crisis, it will be much harder to motivate people to put in long hours.
  • ", balls to the wall"

    sue the company for creating a hostile work place, and making sexual innuendo, then retire. ;)

    this depends. I have seen a 'crunch time' where long hoiurs where out in to meet a deadline. This will work, on ocasion. it will fail long term.

    Look at Tivo. in order to get a product out befor the competition, they had to rethink there process, and pretty much work everyday to meet there new deadline, and they did it.

    now those where people that most, if not all, got a piece of the company, so thats strong incentive.

    However, if you are suddenly expected to work 15 hours a say, and weekends as part of normal operating procedure, I would contact the labor board and see if they can bring pressure onto the management and keep you anonanous.

    This is why I would like to see software developers orginize. If you think you can get support, start a union and strike.
    they can replace you and that impact will be a speed bump, but if they have to rehire everybody, that would be chaos, and that is where the worker has the power.
  • by jdrumgoole (576839) on Friday August 30, 2002 @07:15PM (#4173886) Homepage
    The XP (Extreme Programming not those other guys) have it right here. Programming done right is a task which requires deep concentration for long periods of time and that's just the pure coding part. To actually create and innovate demands that the lateral side of the brain is firing on all channels as well. That just isn't going to happen with permanently exhausted staff. On all the projects I've managed the deal is 40hrs a week max, proper scheduling with serious input from the development team and lets break the bad news early (from the ground up) if there are problems.

    Now if we step back from the coal face and take a longer view the question you have to ask is do we expect our programming staff to pull insane hours every project? Hell no, they'll leave or in an even worse scenario they'll stay and their productivity will drop below the Z. Your fella sounds like he's either new to the game or just wrong for the job. Your can't afford to burn out a development team per project even in these down turn days.

    Programming is an essentially human activity and to get the best out of your real software (the fleshy pink stuff) you need to take a long term view, but I can understand how their are many managers out there who think productivity = longer hours and thats it.

    So use the simple arguments, people who are tired make more mistakes, are less likely to confer with peers, get upset when confronted or corrected, get angry more quickly and generally do a bad job (no surprises here).

    Joe.

  • Who cares? (Score:5, Insightful)

    by countach (534280) on Friday August 30, 2002 @07:15PM (#4173887)
    Who cares if working 15 hour days "works"? Sending kids down the coal mines "works" if your goal is to get coal, but you wouldn't be dumb enough to do it would you? Tell management to get stuffed.
  • Get a life. (Score:5, Insightful)

    by Bongo (13261) on Friday August 30, 2002 @07:16PM (#4173892)

    I wanted to ask the Slashdot community their opinions on how working long hours during the week and weekends affects the quality of the code they produce, and the overall success of the project.

    Forget about code quality. Forget success. Your life is too short.

    There's nothing wrong with having a modest carreer, and enjoying your work. But just be straight about one thing: when you are 60, you will in all likelyhood look back and see it as a waste.

    People who are happily married live longer. Having a relationship takes as much time as a full time job .

    You cannot have a relationship with your partner on 20 minutes a day of discussing the bills, the chores, or over a sandwich. It's a full time commitment. It takes spending quality time together, and not just quality, but quantity also.

    Wanna have children? You think they're going to turn out great if you're never there to be there for them? You want them to feel loved, and nourished, and mentored? Then you have to be there. Not at work, not on business trips, not at the mall. But there, with them.

    You want your parents to feel loved by their children (ie. you) when they grow old, and you're all they've got? Then you have to spend time with them.

    Time is all we have. And all we really have, that really counts, is each other.

    Geeks are probably the last people to get this, but if you really knew that a truck was going to hit you tomorrow, you would find that your real desire would be to spend the time with those who are close to you. Your job, money, and gizmos are meaningless by comparison.

    Work, and prosper. Don't be a slave. Have balance. Be sweet to each other. Don't let some stupid and misguided manager tell you that you have to kill yourself to "succeed". Success is measured in happiness, not paycheck or accomplishments.

    If you have the talent to work on class projects, then fine. If you don't, then just let it go. You can still be happy. Truly happy. Just open your eyes and see that life is more than a resume. You have the capacity to love and you can learn to use it to create happiness.

    Be true to yourself.

    • "Success is measured in happiness, not paycheck or accomplishments. "
      OTOH you should see how happy a couple of million would make me...
  • ...when men were men and were happy to hack 15 hours a day and weekend?

    If you really enjoy what you're doing, you're probably already working 15 hours a day and weekend.
    If you don't enjoy it, just quit and do something else.
    But please stop whining !
  • Bad management (Score:2, Informative)

    by Retief65 (539644)
    I'm a manager (government, no less) and this idea of regularized overtime is absurd. If your people are already working 15 hour days, what do you do when a crisis hits? Nothing, you crash and burn. On the other hand, with a well-managed workforce doing normal hours, when the crisis hits they all rise to the challenge because it's unusual, a bit exciting and they know it is not normal. They all pitch in and once you have crushed all before you, they can settle down to the regular routine again. The hard part is not responding to a crisis, it's ensuring the regular day-to-day wellbeing of your staff so they can perform well during a crisis. This guy should be fired instantly.
  • Peopleware (Score:3, Informative)

    by ergo98 (9391) on Friday August 30, 2002 @07:18PM (#4173916) Homepage Journal
    I highly recommend that you get a copy of Peopleware [amazon.com]. It is a fantastic book overall, but it deals in extent with the death march that is development overtime. I highly recommend you give a copy to your boss as a "Boss' day" present or the like, feigning that you're not quite sure what it's about.
  • Management has to realize that their employees have lives and responsibilities outside the workplace. A 15-hour work day is insane. Even 12-hour work days will rapidly lead to poor productivity and burnout. It can also cause serious damage to your health. No job is worth that.
  • "My general feeling is that long hours is generally a symptom of poor project management"

    Actually long hours are good project management but the project manager needs to understand that there will be a huge loss in effectiveness and the more overtime hours somebody works, the less effective they are. If that is not accounted for, that is bad project management.

  • I guess there are two parts to this post. First:

    I believe that working continuous long days and weekends ultimately decreases long term productivity. People get tired, they get frustrated, they make more mistakes and while they may spend more time 'on the job', their actual productivity tends to slip. After the first spike in productivity due to more time 'on the job', productivity will start to even out, even with longer work days, and eventually start to decline. So, this is usually not a good way to go.

    Second:

    But...there are times when increased work time is a tremendious benefit. Having the opportunity for contiguous thought and work for example. I know I've worked some 36 hour days to get massive work accomplished on a project. Now this was on my own accord and when finished I had time for significant down time and 'fun' work, but it was a long day, and was very productive. Second, with the proper motivation even medium length work spikes can yield high production. This production isn't without costs however. As another example our company asked engineering to work 10-11 hour days and Saturday for 3 months in prep for the rollout of our first product. However included with this, were many consessions made by management including: Additional time off, bonuses, free dinner & beer (yep that's right), flexible hours, the ability the throw nurf balls at management (who was there late too) and the realization that we were all working for a common goal. In this case we weren't under the gun due to crappy planning, but we wanted to get to market fast and everyone agreed and stood to benefit. Another example of long hours paying off.

    So I guess my point is that long hours aren't enherently bad. They have to be taken in context of how they're used, how they're brought about (motivated), and what the end goal result will be. It should also be noted that in each case of longer working better, it also cost much more. Explain that in order for productivity to actually match what they expect, they'll have to take into account that it will most likely cost a few orders of magnitude more to due it.

    • That all sounds very reasonable. I went through a similar thing at a previous company.

      This guy sounds like he's working for nutjobs, though. His boss sounds like the Ross Perot in the SNL skits -- "I'm a powerful man!"
      • It does kind of sound like he's working for nutjobs. It's too bad. However if the company is just resistant to hiring more people, which I think is kind of understandable, they may be willing to fork over some money and allow for higher short terms costs to pay for this higher level of productivity. However, if they've been nutjobs in the past, it may not work, and you can only use the carrot so many times before it doesn't work anymore no matter now much you spend.
  • by ryanisflyboy (202507) on Friday August 30, 2002 @07:25PM (#4173949) Homepage Journal
    "We've had you guys slaving away 15 hours a day and the amount of time squashing bugs has increased 200%. You're just not working hard enough. As of today we will require all programmers to move into the office so that you can work without wasting valuable time commuting. Cots will not be allowed inside the cubes so you will need to bring your own sleeping bags and pillows. You will be allowed 5 hours of sleep every 15 hours only if your code is 99% bug free. Visiting slashdot is off limits, and any programmer attempting to do so will be forced to write documentation for 36 hours straight. Those of you who are married will need to sign the divorce papers by next Tuesday to retain employment with the company. That is all."
  • i live every day as if it were my last
    when i party, i go balls to the wall
    </balls to the wall>
  • If the demands really can't be met in time consider using external libraries/applications.

    There are bound to be areas where you're re-inventing the wheel. Do a freshmeat search and find something which does the work for you.

    You might be able to remove entire sections of development and the areas replaced will probably have extra features you'd never have added.

    I think this approch should be taken more often.
    If the code isn't precisly what the software's about -ie where it adds value, you need to justify not using external code.

    Remember, if you code remains in-house you can use GPL'd code.

    Also, make sure all the functionallity really is needed. Drop any extra work to improve flexibility, -your guesses will probably be wrong so spend the time once you know what the new features are (this is just XP).
  • ... people leaving the company. That will be the people that have to shoulder the heaviest load and are the most essential to the project. Alternatively they will burn out or get sick, making them phyiscally unable to contribute even these 40 hours a week.
    Of course the work done before it finally all comes crashing down will be of low quality, with obscure problems and no documentation.

    Bottom line: While there is usually no way to speed up a delayed project, there are quite a few ways to delay it even more or make it fail completely.

    Good literature for the general topic: Brooks: The Mythical Man-Month, Addison Wesley

  • Yes it will result in worse code:

    a) Concentration is reduced

    b) Morale is reduced

    c) Quality is sacrified for "delivery"

    d) Deliveries become bug riddle pieces of crap

    Been there, done it, got the T-shirt. At an absolute crunch you work the weekend, you might pull 50+ hour weeks for a while BUT....

    YOU MUST THEN REST... take extra days off to recharge. Or your immune system becomes weaker, you are at more risk of being ill, and in an under resourced project that is a disaster.

    Work 8 hours a day, review properly and I _guarentee_ that from my experience after three months you will be better off than if you work 15 hour days and weekends for those three months.
  • The productivitiy will go down. I don't know about quality, but after unrealistic, and sexist and illegal demands, from management your co-workers will be spending their days going to interviews, and submitting their resume to job boards and handing cvs to anyone on the street in a suit.

    Let the managers pay for their own mismanagement. Get a job elsewhere.

    Good luck.
  • It's just a friggin' job. Tell your boss that you will work 40 hours a week (or thereabouts.) If he wants more that that, tell him that you are willing to renegotiate your pay rate for longer hours, but you are not going to give up your friends, family, and social life just so he doesn't have to hire enough people to do the job. If you are hourly and renegotiate pay, tell him time-and-a-half for overtime between 40 and 60 hours and double-time for hours above 60. If he won't go for that, then tell him that you want comp-time for all of the overtime: If you work 60 hours in a week and you get 20 hours of comp time to take when you want.

    One question that sticks in my mind:

    Are they offering to pay you for those hours, and if so, at an overtime rate, or are they expecting hours like that from salaried employees?

    If it's the latter, tell me something: Would you quit if your boss announced that he was cutting your pay in half? If you answered "yes", why would you consider doubling your hours for the same pay?
    • ...but you are not going to give up your friends, family, and social life just so he doesn't have to hire enough people to do the job....

      Which reminds me. Aren't there supposed to be still a lot of unemployed programmers in the US? (FX: Everybody nods.) So shouldn't it be relatively cheap/easy for the boss to increase the programming staff a little at a time over the next year or two?

      I know all about Brooks' Law; this won't help your immediate "crunch" situation. But going forward with new projects you need the right number of highly qualified programmers--why not start as soon as possible?

  • I have to ask - how are you being compensated for the additional time spent working? Are you getting overtime pay? Do you have equity in the company? Profit sharing or royalties for the project you are working on? a big bonus? extra time off in proportion to overtime given?

    And the kicker: What does the owner of the company, who is issuing this order, get out of it? Does he get richer while you get nothing? Is he going to take a bunch of personal time off when it's done while expecting you to continue working normally?

    I think where I am going with this is obvious: Can you tell if you are being exploited or working in your own best interests?

    If you and your team reasonably share in the rewards of the project being successful, then that is a very different situation than if you are giving up part of your life (which you can never get back) to your detrament for the sole purpose of rewarding someone else. Given the nature of employment in this modern era, there is no 2-way street or life-long contract anymore, so you have to be looking out for your own best interests as nobody else is going to.

    I've worked in such situations in the past. When I was young, I felt I needed to do whatever it took to keep my job. I was afraid. I'm older now, and I've developed some common sense and a spine. I won't let my self be exploited. Since the original poster didn't elaborate as to the circumstances, I can't say if the situation is exploitave. But if it is, I say leave, and leave now. Your sanity, health, peace of mind, and precious moments of life are worth too much.
  • talking about the first computer they got at Los Alamos. Before that they used a room full of "girls" at Marchant adding machines to do the calculations. Feynman had figured out a way to maximize the output of the human workers and he tested them against the computer, they were just as fast, but. . .

    The computer didn't get tired and start making mistakes. The "girls" did.

    Do long hours effect the quality of code? Well Duh! Does the Pope shit on a bear in the Vatican woods?

    Will anything in this thread help convince your boss the whole thing is a bad idea? Nope.

    Is it time to bail? Yup. Do it now. The people telling you you're just going to end up fired anyway know of what they speak.

    KFG
  • My boss works insane hours, and I think to some degree he expects that of us sometimes. I don't mind, if we're under a deadline to deliver to a customer, I'll happily work extra hours to help pull a project through, but otherwise I work 40 hour weeks.

    For years, working overtime was just part of the job. I then started suffering from severe stress related problems. I have a new policy. I don't work extra hours for the sake of working extra hours. Period. As other intelligent people pointed out, life is too short.

    If your manager can't handle that, find a new job, unless you want to do it. Yes, your productivity will go to hell, yes, code quality will sucks, but who cares. Your life will suck, that's what matters. No job is more important than your happiness.
  • My guess is that the impact of long work days on the quality of the finished product varies from person to person. I have colleagues who can pull 12 hour, 6 day workweeks for a few months and deliver code that still passes rigorous peer reviews with flying colors. As for myself, I am able to work very fast and deliver quality code, but only for 6 hours a day. After that, quality definitely declines.

    As for your boss... If my boss would use such language, I'd suggest he speak for his own balls and I'd give him the finger instead. I'll work such ridiculous hours for pay, or if a critical project that is running late requires it. I do have that much loyalty for the company. But I'll be damned to work harder for better profit margins, bigger paychecks for company presidents or increased shareholder value, of which I can expect to see exactly zilch.
  • ... if our schedules weren't defined by trade shows.
  • by Lumpish Scholar (17107) on Friday August 30, 2002 @07:46PM (#4174068) Homepage Journal
    Chapter (cached) from Steve McConnell's book, Rapid Development [216.239.33.100]

    "Chapter 43: Voluntary Overtime: Too much overtime and schedule pressure can damage a development schedule, but a little overtime can increase the amount of work accomplished each week and improve motivation. An extra four to eight hours a week increases output by 10 to 20 percent or more. A light-handed request to work a little overtime emphasizes that a project is important. Developers, like other people, want to feel important, and they work harder when they do."

    "Use a developer-pull approach rather than a leader-push approach.... Gerald Weinberg points out that one of the best known results of motivation research is that increasing the driving force first increases performance to a maximum, and then drives it to zero (Weinberg 1971). He says that the rapid fall-off in performance is especially observable in complex tasks like software development: 'Pressing the programmer for rapid elimination of a bug may turn out to be the worst possible strategy-but it is by far the most common.'"

    "Don't use overtime to try to bring a project under control.... Ask for an amount of overtime that you can actually get.... Beware of too much overtime, regardless of the reason."

    Slashdot discussion of [Philip] "Greenspun on Managing Software Engineers" [slashdot.org]

    The original is lost, but I squirrelled away some choice quotes:

    "From a business point of view, long hours by programmers are a key to profitability. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive as one who works 40 hours per week.... A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week)...."

    "If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer...."

    Greenspun said the following in the Slashdot discussion:

    "Most of the people at ArsDigita are young. They have no families. They have no personal reputation. Find me a 35-year-old who has accomplished a lot IN ANY FIELD, who has changed the world in some positive way, and who has never worked long hours. The articles I put on my various Web sites are not intended to help people who just want to live a quiet comfortable life (I'm not an expert on this). They are intended to help young people turn into Linus Torvalds or Richard Stallman or Dan Bricklin and Bob Frankston (Visicalc)."

    "At ArsDigita we do tend to get fairly young people who are very bright. They want to do something that will impress their classmates from MIT or UCLA or Caltech or wherever. The key to successful management is to provide an inspiring goal that these guys and gals can buy into and then a working environment that lets them achieve the goal. It does result in some long hours but [at ArsDigita, at Greenspun's insistence] they have 5 weeks/year to recover. If they get sick of it they can always join a slacker company and work 40 hours/week."

    "Let me say that I did not intend "Managing Software Engineers" to be the last word on the subject.... I don't want to be remembered for advocating a long work week. There is a lot more to the article and I certainly wouldn't advocate long hours to anyone who didn't love his or her job and wasn't learning every day."

    (The banner ad for this page says, "Find a better job, NOW!" I tend to agree.)
  • by Matey-O (518004) <michaeljohnmiller@mSPAMsSPAMnSPAM.com> on Friday August 30, 2002 @08:12PM (#4174197) Homepage Journal
    that $80,000 a year job at 40 hours a week is $40 bucks an hour. That sounds pretty good, right?

    Work _80_ hours a week and you're only making _$20_ an hour. You're getting robbed if you're really worth $40 per.
  • depends (Score:3, Interesting)

    by bob_jenkins (144606) on Friday August 30, 2002 @09:09PM (#4174446) Homepage Journal
    My personal experience is, when designing code, I prefer to work 6 or 7 hour days. When debugging new code I prefer to work 12 hour days. I never work weekends; working weekends burns me out by Tuesday and I get nothing done Wednesday through Sunday.

    I've never succeeded in doing 15 hour days for any length of time. I spend at least 8 hours sleeping (9 or 10 when designing something hard) and 2 hours eating every day. That rules out 15 hours days right there. (I do a lot of design work in my sleep or half-sleep. I often wake up at 4am to do algebra on paper when I realize I can't handle the math in my head.)
  • Hows this? (Score:5, Insightful)

    by emitseum (604669) on Friday August 30, 2002 @09:45PM (#4174578)
    I was working at company...we put in the long hours, some all nighters. My boss used to work 3 days in a row with no sleep. Now he is dead. Heart Attack. He was 38. He looked at least 50. Sort of puts things in perspective.
  • by Samrobb (12731) on Friday August 30, 2002 @10:14PM (#4174695) Homepage Journal

    Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects [amazon.com] by Ed Yourdon.

    Buy, borrow, or spend a few minutes in a bookstore reading the first 2-3 chapters, where Yourdon describes the four different type of death march projects, the prersonalities and politics surrounding them, and what your options are.

    What you'll read there will likely be the same sort of advice you're getting here. Yourdon's presentation is a bit clearer, though, and he raises a lot of good points about how to make a decision with regards to whether or not you'll buy into a death march project. The middle section of the book details how to survive on such a project if you do, indeed, decide you're going to take it on.

    At the end of the book is "Death March as a Way of Life." The long and the short of it is that these type of projects are increasingly common. If the project fails, then then it's your fault - you didn't work hard enough; the next batch of folks will no doubt be harder workers than you were. If you succeed, and ship on time, you'll just show management that death march projects work. Either way, you'll be in a job where every project requires increasingly superhuman efforts.

    Better to decide if you want to deal with that now, instead of trying to do so after a few years of insane workloads have destroyed your marriage, health, and/or mental faculties.

  • Simple Math (Score:3, Insightful)

    by MisterBlister (539957) on Friday August 30, 2002 @10:28PM (#4174734) Homepage
    Your boss is asking you to take a paycut of almost 50%. (Nearly double the hours, same pay). What would you say if he came in and said you were going to take this big of a salary cut directly? Whatever your answer to that is your answer to working these longer hours.

    Me? My answer would be 'fuck no', but I do realize not everyone is a position to say that.

Nothing is more admirable than the fortitude with which millionaires tolerate the disadvantages of their wealth. -- Nero Wolfe

Working...