Slashdot Mirror
Do Long Work Hours Affect Code Quality?
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.
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?
"Old man yells at systemd"
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!
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.
..8 hours day have to stop.. BULLSHIT. Period.
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.
..There's a-dooin's a-transpirin'
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.
Evolution: love it or leave it
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.
DISCLAIMER: This post was not checked for speling and grammar- if you complain- you're a whiner
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.
Sailing over the event horizon
the important point is to make sure you are paid punitive overtime rates
Um...do you live on a planet where programmers are paid overtime?
-=Maggie Leber=-
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.
Rapidweather's Linux Screenshots.
Chapter (cached) from Steve McConnell's book, Rapid Development
"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"
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.)
Stupid job ads, weird spam, occasional insight at
sPh
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.)
Funny, but the only situations where I've seen this kind of mismanagement and staff abuse are those where the staff is on salary. Set an ignorant deadline, then tell the coders it's *their* responsibility to meet it, "whatever it takes"...the additional time and work effort being "for free".
What's truly astounding is that the same managers, who were at pains to hire the brightest people they could find, think that those same people won't figure out what a fraud that is.
-=Maggie Leber=-
From personal experience, anecdotal for sure, I've written code during an all-nighter, which after a few hours sleep, was obviously not just wrong, but not even code, although it seemed perfectly fine at the time.
I left a job I had worked for 15 years because I was pulling 16-18 hour days for the last two years and, I was just discussing this with a friend a couple hours ago, didn't even realize it had happened. I was chugging extreme amounts of caffeine, going through a pound of Kona a week, and doing some serious damage to my own health with lack of exercise and fast food diet. If this is your manager's idea of how to _regularly_ accomplish things, then get the hell out. I mean it. Once managers realize they can pull shit like this all the time, they will! And guess who gets fair compensation for this, not you!
It is the result of poor management, particularly very bad planning. If there's some advantage your employer can gain by pulling all the strings, once, ok, particularly if it means you get compensated fairly or your employer stays in business, I can see it. But if they're doing this as habit, you seriousl are doing yourself harm by remaining staying and becoming a victim.
When I started my next job, after the one which nearly burned me out, I was shocked when my manager asked me why I was staying 10 minutes after five, "just a few things", his response was, "they'll be there tomorrow, go home, get!" It really was a different world, where work got done in 8 hour days, and planning made it work. Too bad new management came in and fouled it up and sunk it, but that's another story.
A feeling of having made the same mistake before: Deja Foobar
I own my own company in a highly competitive IT field. Our company is surrounded in our regional market alone by many other small businesses who provide a similar service, at a cost that we've found is typically more expensive to the end customer than us. Given that I'm the owner of my company, I suspect you might take the following with a grain of salt - I'm biased... =)
Still, we have recently hired a number of employees and many of the potential candidates were from those same competitors. Often, they were being paid less than we were offering, and worked long hours without much reward for those hours. Two of our first employees were from a direct competitor who sounded almost identical to the environment you describe.
In our company, staff get all stat holidays, one full week from Dec 24th to Jan 1st, with regular hours (regular being approximately 8 hours with most people starting anywhere between 8am and 10pm and finishing anywhere from 3pm to 6pm) and usually a couple of weeks holiday through the year.
So what makes our company able to do this when theoretically our competitors are twice as productive because of the extra hours they work employees? Our employees LIKE coming to work. We're a community and people want to be there. We involve people in decisions about how they do their work, and we insist that people take time off. Yes, occasionally we ask staff to work long hours - and a long day for us is 10 hours - but I then insist they take a long weekend or some other time immediately to reflect that extra effort. Not six months down the line when the manager has forgotten the extra time and gives it out begrudgingly, but when it will be felt and appreciated most.
We also practice continuous improvement. If we do the same thing over and over, we look for ways to improve the process so that we can do it in half the time so that those who are working don't get bored, and can finish off monotonous tasks more quickly. We encourage staff to take courses to further their skills and allow them to move around in their jobs.
By no means do I think we're perfect - there are lots of things that we do poorly. But for the most part, we know what they are and we focus on them. And I don't think we're alone in our business philosophy. There are companies out there that don't treat employees like cattle but they're not always easy to find as so many companies sound perfect during the interview. See if you can interview the company employees before you're hired and ask them to be frank with you. Sometimes even that doesn't help if the company preps their employees, but it might give you some idea of the mentality of the company. If possible, always get to your interview at least 10 minutes early so you can watch the dynamic of the office that you're looking at. It will tell you a lot. I still do this when sizing up potential clients because it will help me determine what kind of client I'll be dealing with.
Anyway, good luck with your job, whatever you decide to do! But whatever you look for, to me the best way to a good comfort zone is always creating the right balance both mentally and physically. Without balance, something invariably begins to break down.
This is the part that has always amazed me. How can they ask you to do something this stupid with a straight face?
My last boss caused me great pain with such stupidity. One of my Debian buddies sent me a good explanation after I spent the afternoon complaining about it. That PHB did not even understand that laying me off was actually a reward. My nerves are finally starting to recover and I should be able to kick-ass on my next job ;-)
In most cases, as a programmer peon, you really don't know what's actually going on in your company. Oh, sure, you think you do, but you don't. Do you review the sales pipeline every week? Do you know the state of your company's balance sheet and financials? How about its credit facilities and payables? When's the last time you sat down with the bankers or the investors and heard the real story?
Do you really know what's going on with the competition, or do you just believe what the suits tell you? Is the pricing strategy correct, or are the Marketing people on drugs?
The problem we all face when we are in your situation is that we are operating in a vacuum. I've been a coder my whole life, spent the last 10 years in upper level management positions. Let me tell you something profound: You do not know what upper management knows. They will never tell you the whole truth. Therefore, you cannot make a rational determination as to whether this request to work overtime is reasonable and thoughtful, or whether it is just the last frantic thrashing of the whale's tail before death.
I've been coding for 32 years, I've started two companies, worked for many. Here are two general observations that may or may not apply to your specific situation:
1. If you are working massive overtime, do so because you are starting a company on the side, not because your current company has understaffed the department.
2. It is easy to believe in your own importance, and that you can make a difference by working OT. Sadly, you probably won't make any difference at all.
Hope this helps.
The Air Force has a strict limit of twelve hours on a shift, even in time of war. They understand that after twelve hours you're making more mistakes than you catch, and, since most high ranking AF officers are pilots, they really care about quality of aircraft maintanence.
Absolutely.
It does not matter how long I am at the office. I can only deliver 6 hours of code. And that's if I am well rested.
If I'm very tired (less than 6 hours of sleep) then the amount of good code goes to zero.
I know that because the next day I spend 6 hours fixing the code I wrote the day before. So in actuality, in 2 8-hour days, I produce only 6 hours of code.
When I come in on a Saturday like today, I'll be here for 7 hours, but plan on coding only 4. Why? Because I know that I won't have to screw with that code ever again, and in two-three years it will be chugging along happily without a single failure.
Oh, and it will be properly indented, properly commented, and have failover redundancy, event logging, and a fully detailed technical paper in html.
And that is what my company is paying me for. Not face-time.
"Piter, too, is dead."
There's a difference between telling an employee to work more efficiently throughout the day (your union example) and telling an employee to work longer than is reasonable. On one hand, yes I do believe work should be rewarded, but on the other hand, you don't want to create an environment where long hours are expected and considered reasonable. Work should not have to be an employee's whole life (yes, I'd define 60 hours per week as "your whole life"), and an employee who wants to have a decent life outside of work shouldn't lose out because other employees either don't have or don't want a life outside of their workplace. Around the places where I've worked, unless something was breaking terribly, a sysadmin was expected to work 40-45 hours a week. And there's no reason why this shouldn't be the expected.
Always, always remember: the company is not more important than the employees. We heard a lot of bullshit during the dot-com era about how the employees needed to sacrifice everything to advance the company.. somehow it was reasonable to expect 80-hour work weeks, weekends, all because the company was in a groundbreaking new field and it would make all the employees rich.. and we know how empty those promises ended up being.
I guess my (admittedly rambling) point is that employees should have the right to expect the 40-hour work week. Some people might want to work a little longer for extra pay, and I have no problem with that. The only things I fear is that then this becomes expected for other employees, and they are pressured (or simply fired) for not upping their own hours.