Posted
by
michaelon Monday November 06, 2000 @11:21AM
from the crack-the-whip dept.

Cryofan writes "Very interesting story on managing programmers. Lays bare the dynamics behind what is happening to the software industry." I think Greenspun has it right about the distribution of talent in software engineering, but I'm not sure I agree with his concept that it is necessary to work 70-hour weeks (though for unreasonably long hours, they do pay unreasonably large salaries).

In Greenspun's particular business, what he says may be true. But the open question is whether that is going to be the dominant successful business strategy in the future. Looking at the history of business, I tend to believe the kind of business he is creating, with expensive, skilled craftsmen, will only be catering to a niche market.

Companies like Microsoft are founded on the notion of commoditization. This is quite analogous to what the industrial revolution did for craftsmanship, what MacDonald's did for cooking, and what companies like AT&T did for customer service.

Microsoft has created mechanisms (Wizards, etc.) for software development, analogous to machines to do the "heavy lifting", that allow many people to generate complex application frameworks. And Microsoft has created step-by-step training materials and systems to break up complex processes into something that's easily mastered by everybody.

That's at least Microsoft's story. That's why business people have their organizations buy and develop for Microsoft software. They believe that Microsoft has succeeded at bringing software development to the masses, to the non-craftsmen. Microsoft software is supposed to turn what used to require expensive, scarce, rare craftsmen into something anybody hired off the street can do with a little bit of off-the-shelf training. That's what "easy to use" really means to Microsoft and business management.

Whether Microsoft has actually succeeded is a different question; I think they are still pretty far from that goal, but others will step in where they failed.. And like mass produced trinkets and food, the quality of products built on Microsoft tools leaves a lot to be desired. But, then, that hasn't stopped most people from buying mass produced goods and fast food either.

Skilled software craftsmen may continue to take pride in their work, but whether that is going to be economically a big success or a fringe
business for upmarket consumers, remains to be seen. Good home cooking (free software) and upscale restaurants (skill-based software companies) may be what the gourmets like, but most of America eats at MacDonald's, and the same may well turn out to be true for software.

Ideally it would be possible to conceive a product on Friday evening, set up the
development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday
morning.

He's kidding right? This might be ideal for managers, but I don't know any of my geek friends who would consider this ideal.

A programmer probably needs to
spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the
systems being extended.

Where did he get this figure? From the Man-Month book? There's always an initial period of design that eats time, and various redesigns afterwards, but then there's the time spent churning away code that you don't talk to any of your co-workers, or very seldom.

On weekend mornings you could walk naked through an entire floor of our
headquarters building without fear of embarrassment.

They took a weekend morning OFF?!? Oh the shame!!! What lazy bastards!

Your business success will depend on the extent to which programmers essentially live at your office.

I see this programming ideal slipping away. I think people are realizing that no matter how many foosball tables you put in, programmers will burn out working 70+. I think that this ideal treats programmers as machines. As much as programmers like to think they ARE machines, they are humans and need rest. I think people are finding that if they go home and rest, they come back refreshed. Of course there are crunch periods, but once they're over, take a break.

Most people have a TV at home but
they don't have friends with whom to watch it.

er??? What is he talking about?!? Most people who have a TV don't have friends? Where is he getting this crap?

That 15% OT is mandatory now which translates to ~7.5 extra work days/year depending on where...

And the odd thing is that we all get Thinkpads specifically to work the odd hour or so at home and then get dirty looks (well not actual dirty looks, but some of us get the virtual dirty look in the form of never getting more than a 2 no matter what, never ever ever) if we dare to leave the office before the divorced twice, never home workaholic boss does.

Thanks, Bob. Your point was sort of an unstated assumption of mine. 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 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.

As kids watched the dotcom craze and saw how much SE were making they thought hey i want to be an SE. It's called Invisable Hand in economics. Companies demand more SEs and so the gap is filled with an increase in CS, SE students in our colleges. Expect lower wages to come to computer related fields. The only way to protect yourself is to know more and be able to do more than the next guy.

I don't even put "PhD" or "Dr." on my business card (I admit to having a photo of little Alex on the back, though). You're right that a PhD per se = useless. But at ArsDigita we actually have managed to get a lot of work out of people with PhDs. Much of the edge comes from the screening process. Someone with a PhD from Caltech is going to be very smart and very persistent. He or she will have managed to plan, produce, and publish a long-ish document (the engineers with the most influence are usually those who are willing to write). This is why companies like McKinsey recruit PhDs from top schools. But just like McKinsey, the first thing that we have to do at ArsDigita is deprogram the PhD. We say "here you ship your product every two months, not every two years" and "here you write up your results over a weekend, not over a season" and "here we do look for the grand elegant complete solution but we try to get to it via incremental releases rather than wait quietly for 10 years".

I'm not trying to force anyone to go on a death march! But the programmers with whom I hang out long to do something innovative and creative, to solve a problem that nobody has solved before. It is tough under those circumstances to rely on a project manager to map out everything that must be done. It is also tough to keep people from pounding away at a problem until it is solved.

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).

Private practice 1st year associates in a white shoe Wall St. firm working 90 hrs week command $140K out of school w/ no experience.

The average income of doctors in the US including all of the MDs who now work for HMO's etc. is ~$250k according the personal disability insurance providers.

The average CEO of an American firm earns between 17x and 30x the income of the lowest paid worker. My own CEO earned something like $6-9 million in direct cash compensation, another $9 or so million in deferred compensation, another few hundred thousand $ or so in guaranteed deferred pension earninings and several hundred million dollars in options, grants, deferred stock purchases and other forms of equity. And this is not a startup this is a well established stable company which barring an asteriod will be around for a while.

So yeah - lots of people are willing to work huge hours. Mostly because there is a huge financial upside. Not a maybe, not a chance, not a possible IPO but a definite concrete realistic outcome you can bank on when making other life decisions like what house to buy now like how many children to have now and what kind of schools they can go to, whether you need to be a 2 income family or not.

Actually ArsDigita pays most entry-level workers $100K (these are fresh MIT CS grads). The reason cost of living is high in cities like Cambridge is that Cambridge is a great place to live. You can learn from almost anyone that you run into on the street. They are likely to have an Ivy League education. They are likely to have done something interesting recently and be willing to tell you about it. If your idea of the great life is a big-screen television, 100 channels of Cable, and a big house with blank walls to hold the TV, you're right the cost of living is lower in Peoria. But if your idea of the great life is finding interesting people to talk to, lectures and performances by the world's best and brightest, a city like Manhattan might be a better choice (despite the expense).

Smiley face not-withstanding; in psychology, in this case, "positive" does not mean "good" and "negative" does not mean "bad" (although that's often the case).

Positive is when you get something for your behavior, negative is when something is taken away. In this case, knowing that you will get a bonus, or a raise, if you exceed expectations will certainly motivate you more than simply meeting expectations for fear of a pay cut, or losing your job. Therefore positive reinforcement is a better motivator, in this case.

So, in your case, you studied so you wouldn't fail - you can get C's. But if there were some reward for you based on your performance, you might have done better. In your example, "than when I wasn't failing them" is neither positive or negative - you had nothing to gain or lose at that point. But in that same situation, if you father said he'd buy you a new car if you got a B, and a new really expensive car for getting an A, wouldn't you study harder?

It seems okay to me. I've been using the arsdigita.com site all day. Anyway, there isn't much hardware behind arsdigita.com (normally gets no more than 100,000 hits/day). We never said that ACS was going to handle more traffic per CPU than a non-personalized system that doesn't hit the RDBMS. As for AOLserver and Tcl, you don't have to use either. ACS Java is released and available from http://www.arsdigita.com/download/ It contains not a single line of Tcl code (same old SQL and PL/SQL and Java-in-the-database core plus a 100% Java presentation layer). It should work with any Java application server and any Web server (or no Web server at all; you can run the whole thing from within Oracle 8.1.7 and its built-in Web server).

Let's not forget that the average consulting firm charges >$200/hr for a professional's time. Assuming billing 60 hrs a week for 50 weeks a year, that's $600000. And almost all expenses are billable to the client. When you look at it this way, even a $70K salary is pretty close to exploitation unless there are serious cash bonus payments every year a la banking.

Mr. Greenspun,
My observation that you had a Ph.D fetish was largely based on your description of the ArsDigital workplace culture(at your Web site) back when I was checking your company out for applying for a job. I had significant experience working with some relatively savvy consulting companies roughly in the same space and caliber as ArsDigita; and it seemed weird how the ArsDigita site boasted about how many Ph.D's you had.

My 2 cents is: This is not Los Alamos Labs, for God's sake! I earn my living from server-side Java programming and Web application design, too; and my personal opinion is that any CS Ph.D actually writing Tcl/PL-SQL code for a Web application for a, say, pet food store or an online loan application site is woefully under-utilized. These people are supposed to be out there working on designing better cryptosystems, invent new methods to speed up object relational databases or who knows, perhaps prove that P=NP.

Perhaps my simple, Ph.D-less mind could not come up with a possible justification for employing MIT CS Ph.D's at a Web consulting company for any other reason but a Ph.D fetish. I totally agree the more influential engineers are the ones that are willing to write, but a Ph.D for just learning how to write results? Geez.

Other than this minor point, thank you for taking the time to write. I guess a major part is right-on.

As stock options become less lucrative, programmers are going to taper off their hours, regardless of what Greenspun puts in the office or threatens or promises.

Greenspun and his ilk are going to find it hard to find people willing ot program 70 hrs a week for sustained periods if you aren't going to offer them at least a million in post-tax compensation over the course of a two or three year employment stint.

This long discussion has an awful lot of bashing
Phil about working long hours. Statements
like "From a business point of view, long
hours by programmers are a key to
profitability" sound pretty manipulative.
Much as I'd like it not to be true, there is
some truth here...

I've worked on many hardware & firware projects, often by myself, and almost every time I ended
up working a lot of really late nights. At least
for me, I can get more raw coding and design
work done in an all-night session that an entire
week of 8 hour days. Getting the environment
right... no distractions, music without lyrics,
correct room temperature, etc, makes a huge
difference. I try not to do this sort of thing
often. I try to do all-nighters more for my
own (often free software) projects more often
than I do them for my employer. (trying hard
to resist a shameless plug... the URL is next
to my user info above)

Now I think it sucks to "have no life". It think
it sucks for employers to expect programmers to
work 70+ hours/week. Phil's writing does leave
a bad taste of giving would-be managers a
formula for over-working programmers.

It is true? Yes, I think it is.
Does it suck? Yes, I think it does.

Those are separate issues. Just because it
sucks and is manipulative and/or unethecial
doesn't necessarily mean it's wrong. I think
the a number of comments posted here have
failed to make that distinction.

1 I made zillions as a dotkomissar therefore I am right.
2 I agree with other statements generally agreed to be correct therefore my statements are chistled in granite.
3 Nagging is good because not nagging leads to similar results therefore either negative or positive reinforcement must be a good thing.
4 Stupid people yield stupid results.
5 You are probably stupid if you are not as great as I am.
6 If I say something is correct then it must be a priori since I provide no proof otherwise.
7 Generally agreed upon aphorisms are in fact correct even if you can't prove them to be.
8 Everyone wastes 30% of their time even the most productive and brilliant of us.
9 Hard work is good.
10 Working smarter is no substitute for thinning the herd.
11 If you could bottle it you would. Even though we call it engineering and we claim to agree to be able to manage it at all, it's a really an artform that can't be well understood, documented, replicated or taught. IF you're in the bottom half...tough luck for you.

Brooks may be right but if the variation in productivity is really 10:1 then it isn't engineering at all. That's no measure of the engineering-ositude of anything. If it were then civil engineering projects would have schedules and timelines that look like "whenever...." and we wouldn't be able to tell the difference in the creation process from software, steelmaking or wineries.

So let's agree to disagree. ArsDigita was successfull because of very smart talented people working in small focused groups that specifically WERE NOT ATTEMPTING TO ENGINEER ANYTHING. At least not the way you'd design and build an airliner. Because if you knew anything about actual engineering you'd understand that it doesn't depend on the brilliance of a few to be successful. Is is the application of well understood and documented knowledge processes and tools to create a reproduceable item or service or process.

In fact that is precisely why software is so hard to make. No one has adequately figured out how to engineer it at all. Projects still largely fail and the ones that don't generally have no repeatable success criteria or design or process commonalities. Even successful projects generally are late and an order of magnitude more expensive than projected, don't survive unaltered for as long as projected and cost much more to maintain. Good solid designs rarely survive the tenure of the people who built them and in the end it's cheaper to be ignorant of the whole of a system and attack fixes as temporary point solutions than it is to build maintainability into the system to begin with.

In fact if software was engineered then you would see larger groups successfully develop it and maintain it. But it's not. For an apocryphal story about this read "Strategic Planning, Systems Analysis, & Database Design, the continuous flow approach: Mark L. Gillenson & Robert Goldberg; Published by John Wiley and Sons, 1984; ISBN 0-471-89066-9. Where there is a story of two developers who apparently developed some customer system right the first time with no obvious bugs or requirement or design changes, on time and on budget. When asked how they ever did this, apparently the response was something like "It never occurred to us that bugs were acceptable..." or less poetically, the quality was engineered-in from the beginning.

> I'm sure that programmers here will claim that their huge intelligences are responsible for their constant need to change the task they're doing and their
> complete lack of focus, but it means that out of every hour they're present, only half (if you're lucky!) of it will be spent working. The rest will be spent
> browsing the net, checking emails, getting drinks, going to the toilet, scratching their armpits and any other activities that can help them avoid doing what
> they're begin paid for for another minute.

Programmers are creative types, a fact which makes the following words (paraphrased from memory) of Frederic Pohl (a Science Fiction writer of the old school) relevant.

It's hard to tell when a writer is actually writing. Sometimes even he is not sure, & can't say whether reading the Sunday classifieds is actually work towards the book, or just screwing off.

Abuses in the tech industry are getting fairly common, but I wouldn't get too worried - already there are changes taking place. Firstly, as the land-grab on the web comes to an end, there is going to be less of a mad-rush to get things up in a hurry - there's no point now - no one is going to win marketshare with a quick solution at this point, and their are diminishing rewards to new companies joining the fray now. Added to which, at most large companies, you can already see an entrenched 8-hour cycle taking place.

I've worked in a place where *some* of the programmers had access to syntax highlighting
editors and others did not. That made for terrible looking code. The problem is that code
that looks like it has plenty of white space in color mode doesn't really when you turn off the color syntax - things are run together and badly
indented because the color highlighting made things look like they were still easily discernable and hid this fact. This is especially bad in printouts.

The whole point of engineering is to create solutions that are simple, flexible, and effective - and that can be *understood*.

Simplicity is a critical value in software development. But there are two aspects to consider: simplicity of concepts, and simplicity of their manifestation in design and code. For many problems, deep and subtle concepts allow top programmers to address the problem faster. Some problems require them. The implementation is necessarily at least as complex as the concepts. One should always avoid making it more complex. One should also always consider whether simpler concepts would do, as many good programmers tend to overcomplexify (as Greenspun attests). But that is not always the right answer.

Furthermore, it is sometimes a simple matter of volume. In a fast-moving project, lots of ideas and designs are constantly being generated, and these take time to comprehend even if they are simple. A top programmer can pick up many simple ideas faster than an average programmer, just as he can comprehend one deep idea faster.

If you don't think programmers should spend a significant amount of their time understanding others' code, I think it's likely the programers in your team don't have adequate understanding of issues global to the project.

It's not often that a management philosophy actually makes me mad, but this article is really getting under my skin. Why? He's making a bunch of wrong assumptions:

He claims that it takes 25 hours a week to get coordinated with other programmers and to understand the systems they're working on. So, he immediately writes this off as unproductive time. If someone really spends 25 hours a week doing overhead tasks, then the system is broken. If, on the other hand, researching the system and understanding how it works produces better code (or at least working code, as compared to broken hacks), then that research time is indispensable.

He claims that 70-hour workweeks are the key to profitability. Everyone else has already criticized this idea, so I'll just poke at it a little bit. I worked 70-hour workweeks once on a project because it was grossly underestimated and because we had a drop-dead date. Nobody in management anticipated the challenges of this project, and it had taken a long time to get designs finalized in the first place. Also, for most of us it was our first major project in C++ (this was back in 1991). Maybe it's possible to motivate programmers to do things this way for a few weeks, when they know the consequences. But to do this all the time, as a normal course of business? Any programmer with half a brain will see right through this.

He doesn't realize that programmers are going to have lives outside of work. Sure, it'd be nice to have a really cool office that has nice comfy chairs and entertainment facilities. But unless your developers are complete hermits, sooner or later they'll find hobbies, friends, and families outside of work. And they'll start to resent having a heavy workload that keeps them away from those things.

Cheap American managers are likely to read this article, think, "Hmm. Let's get those programmers in here 70 hours a week," and consider Greenspun's perks to be expensive frills that can be ignored, scaled back, or purchased and then eliminated when the stock price falls.

Software projects collapse. Companies fail. What would the legion of ArsDigita programmers think if the company suddenly went bankrupt, and all of their 70-hour workweeks were a waste?

I've been there before: The company I worked for in 1991 spun off a division which became part of a joint venture with Amdahl in 1993. Several months later, they announced that the joint venture company was killing the project that I had been working on. They assured us that they needed all the people to stay with the company, and the CEO said, "And if anyone leaves the company, I'll be personally hurt." Well, with no product and nothing to work on, morale sunk like a rock, and several people left -- including me. And, just last year at this time, my previous employer was laying off developers left and right because our product didn't sell. For the people who weren't laid off, management wanted everyone to take a 10% pay cut until January, to be made up with stock options. I left the company soon after that, even though they wanted to keep me there.

As a software engineer, I'm motivated by knowing I'm working on a quality product that people will find useful. I know I'm not going to be writing quality code if I'm on a 70-hour per week death march and resenting being overworked by an employer -- especially if there's a chance the company may go belly-up next year. My current company respects and rewards its employees' contributions, and that's worth a lot more than having a big-screen TV, a pinball machine, and comfy chairs.

It's simply not true that older workers can't get jobs. I'm 42. I visited a job fair here in Richardson, TX. Mostly telecommunications companies. My previous telecommunications experience is extremely limited, but within a week I had two interviews and two very attractive job offers with equity. And no, I don't plan or expect to work 80-hour weeks.
Why was I able to get these jobs? Because I have a handle on OO and real-time development, and I can present that in an interview.
I've interviewed dozens of developers over the past five years, some old and some young. An amazing number obtained a degree withoug mastering the basics of Computer Science.
Another large set hasn't read anything since leaving school. These are the people who are whining about the unfair competition due to H1-B visas.
Developers who have mastered the basics of the field, and who have kept up with new technologies have no trouble finding work.

Microsoft is actually a good example of small teams, each person individually strong and working hard. For example, Netscape had nearly unlimited resources in terms of bodies. Microsoft crushed them and built a much better browser (IE) with a team of only about 30 developers.

They want to do something that will impress their classmates from MIT or UCLA or Caltech or wherever.

MIT and Caltech must be really overrated if all it takes to impress the students who graduate from there is a job doing web scripting and 3 tier applications that any high schooler can do with PHP, ASP or Perl.
Then again, maybe you guys simply hired the bottom of the barrel.

If they get sick of it they can always join a slacker company and work 40 hours/week.

The more I read about Ars Digita, the less impressed I am. From the trivial bootcamps and gross overpayment for monkey work (web scripting, pah) to the fact that some of you think using fuck in code is a mark of professionalism [arsdigita.com], I had mentally filed Ars Digita as yet another hotshit startup that won't last the next half decade.

From the descriptions I've gotten of ArsDigita both from employees and boot camp attendees, the place is a hackers playground where and software engineering and computer science practices are paid lip service. Particularly amusing is the fact that you guys think that your online degree program [aduni.org]which is merely a glorified course in Web Development is equivalent to a degree from MIT *LOL*

Where did the 40 hour work week come from in the first place? Back in the early part of the twentieth century the question was asked: "what is the most efficient amount of time to work people at a job?" I believe it was the US government who funded a study of the question.

What they discovered was that up to 40 hours a week the amount of output was proportional to the number of hours worked. Beyond 40 hours that was true only for about 2 weeks. After two weeks the amount of work being done fell back to the 40 hour level - no matter how many hours were worked. All of the people working over time in the study thought they were doing more work - but when their production was measured it turned out that they were not.

Granted the study was of clerical workers - not programmers - but people are people. There may be statistical variation from one person to the next - but on the average 40 hours is the optimum time for most people. Yin and Yang qualification: mostly the results are true - but for some people they may be false.

In general most people working longer than 40 hour weeks are just kidding themselves - they really aren't getting much more useful work done than they would in a concentrated 40 hour week.

Work is more like a marathon than a 100 meter dash; it is not about brief sprints - it is about setting a pace than you can maintain for a long time. You can only sprint for so long - then you have to slow down to a long distance pace.

I would like to point out the the US was on the winning side in W.W.II and beat the Soviet Union to the moon - all on 40 hour work weeks. If you honestly believe your project is more pressing than either of those I suggest that maybe you are suffering from a lack of perspective.

1x 70 hours at $70k costs the same per man hour as 40 hours at $40k, if the amount of work that neads to be done exceeds what can be done by the available staff in the available time then they nead more time or more staff.

If Greenspun advocates pushing his staff into doing more hours over hiring more staff this implys that overworked staff are more productive than more staff.

The effectiveness of programmers is reduced when they work long hours (this has been proved by independant research.)

Therfore, this implys that his organisation cannot cope with larger numbers of staff, that is, the managament can't do their jobs and are failing to co-ordinate their staff effectivly.

Phil wasn't talking about how to satisfy the programmer who just wants to pay the bills so that he can fulfill himself with family or other interestes. They shouldn't work for Phil. Nor should anyone force them to.

Phil was talking about how to get the best software out of top programmers. The answer is to motivate them, make them comfortable, and encourage them to work intensely. How many hours per week do you think the top 10 Linux developers work? How about OpenBSD or Perl hackers? Do you hear them complaining?

Perhaps it's not possible to motivate programmers to work hard on some tasks. Maybe some software (or the companies that write it) is just too boring, and will inevitably be done by 9-5'ers, who may not get as much done, but are lower risk and easier to manage. Those of you protesting should take consolation: there will always be a place for you. However, you may never realize how fast good software can be written by small teams of top programmers working intensely--and how exhilarating is the experience.

PS. If you really find this hard to believe, find some people working for ArsDigita and ask them how they like it. I have a friend there who describes the experience as "addictive".

the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers

If the project was being run correctly, the average programmer wouldn't be reading the good programmers code at all. Ever heard of code-by-contract? How about object-oriented code? I don't have to dig down and understand the code in glibc, because it is in a fucking library. All I need to know is the function name and its parameters. If I'm having to read code in order to use it, it wasn't written be a very good programmer at all.

It is easy for an office to beat the home on the social dimension,...

Not unless the company is hiring some freaky women to come in a couple times a week to provide certain services that are illegal to be provide for pay in most of these united states. Playing pinball just doesn't compare the games me and my woman play.

One of the main points of the ad was to ridicule the cheap open-plan offices in which programmers were traditionally housed and promote the fact that at Microsoft each developer gets a plush personal office.
.
.
.
An open office plan contributes to making the work environment stronger on the social dimension.

This lack of internal consistency amplifies another one of his points.

In the long run it is impossible for an organization to be excellent in one area and mediocre in all others.

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. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.

This is beyond the pale. I'm up at 6am exercising. I drop the kids off at 8am and arrive at work by 8:30. Put in my 8 hours and leave at 5. If I am to be rested the next day, I need to be in bed by 10pm. This leaves a total of 4 hours a day to devote to the next generation of programmers, let my wife know that she isn't a single mother, and maybe play at one of my many hobbies that are generally ignored. Greenspun can kiss my ass. Excuse the french, but that is as polite as I can put it. If my company (which is realistic, BTW) installed a pool table, rock wall, garden, grand piano, etc, they would all be summarily IGNORED. This is work. I do it to make a living so that I can spend time with what is truly important.

If my manager challenged me for walking out after having been at the office for 10 hours, then he won't have to ask himself anything. I will ask him to kiss my ass. I've done it before and I'll do it again.

And just in case it wasn't clear before, Greenspun and all of you "keep 'em entertained while we work them to death" managers can KISS MY ASS!!

Frankly, some of us get our twelve hours of work in in eight hours. When I'm up to speed, I can't work useful overtime. I will work seven or eight hours, because that's how long it takes me to get mentally exhausted. Working longer is a waste of my time and their money.

This adds up to 84 hours/week. Even before you've spent any time at all at work, you've used up half the week. Think you don't need that much sleep? Read the book I mentioned. Sleep deprived people literally murder patients on the operating table and blew up the Challenger. Think you don't need exercise? Ask your doctor. Spend time with friends and family, routine errands, etc. and more time is gone.

Consider now what the various work weeks really mean:

40 hours -- This leaves about 3.5 hours/day during the week for other activities than work and two full days away from work.

60 hours -- only 1.5 hours/day for "other" and one day off. Doable if you have a full time servant (the "wife" back in the 50s) to take care of you and all the other pesky things in life (like children, grocery shopping, etc.).

80 hours -- essentially no time left for anything else but work. No days off.

The long work hours phenomenon is a relatively recent phenomenon. Two centuries ago (not long in the span of human civilization) people did not have electric light. Pratically all human activity was limited to daylight hours. Back then people did accomplish some very remarkable things. For example, starting the United States, learning much about the universe, creating great art.

A final note: people have incredible abilities for self deception. When I hear people bragging about how much they've accomplished by working long hours, I wonder if it's true or they're just deluding themselves. Remember, people in the Soviet Union also deluded themselves about their accomplishments for literally decades.

I have a social life, and I would still appreciate having a more entertaining and person-friendly work environment.

For example, I live more than an hour's commute from my workplace. I often have social activities near work in the evening. It doesn't make sense for me to go home in the interval, and I'd love to have a couch to nap on or a video game or pool table to play with until my dance lesson or date begins. I might also get some more work done if I could relax for a bit and get refreshed instead of burning out and just working through like a zombie until normal quittin' time.

I also consider the people I work with to be my friends and think tha you should be able to work in an environment where you LIKE going to work. Not that you should do it to the exclusion of family or other things, but liking your job and considering your coworkers your friends doesn't make you a loser. Work is a part of my life, not something I do so I can have a life. Making it more pleasant and fufulling isn't a ploy to steal from the other things I do, it's making that eight hours a day away from my family, friends and hobbies worthwhile in and of itself.

I did set up ArsDigita so that every employee got 5 weeks of vacation annually (enough for a 3-week break in the summer plus two one-week breaks). Maybe I should add that to the article.

Compare this against a "normal" 40 hour/week job. Most employers give at least 2 weeks of vacation. If we ignore holidays and the odd extra days beyond an even 52 weeks, that give about 50 weeks, or 2000 hours/year. If you're expecting your employees to work 70 hours/week for 47 weeks, that's 3290 hours/year, 64.5% more total hours. You should aim for the same 2000 hours/year total, if you really want to be fair. Of course, at 70 hours/week, that would mean giving each employee 23-24 weeks of vacation per year (yes, that's over 5 months). The fact that you give them only 5 weeks indicates that you really prefer exploiting your employees. Sure, you may pay well, but there's more to life than work, and time is an irreplacable resource that money cannot truly compensate for.

As long as you employ people who don't have a life outside of work, you may be able to get away with this sort of exploitation. Lucky for you, they'll have a very hard time developing a life outside of work when they're working 70 hours. However, most of them will eventually determine that living only to work isn't much of a life, and they'll find a better job someplace where they won't be exploited so much. At that point, your only hope is to keep finding new youngsters with no life, and try to indoctrinate them into your culture of indentured servitude.

As long as there remains a ready supply of people willing to be exploited, you can probably get away with this for a long time, and you're in the majority with this approach. But don't lie to yourself; you're exploiting your workers for the sake of profits. It's a widespread problem, and much of the industry is equally guilty of the same thing, but it remains exploitation, albeit well-paid exploitation.

This sort of exploitation in the past has fueled the creation of unions in other industries. If employers aren't willing to stop, don't be surprised if programmers start unionizing someday... (And then you'll regret your shortsightedness.)

I agree with the lot, the only one is the number of hours. The myth that more hours = more top quality code. Brook's says it, Peopleware says it, almost every study made says it. Reduce the communication between teams so teams are more productive so can work lower hours and thus be able to concentrate more and create better code.

Everyone thinks that they are more productive in 4 x 100 hour weeks than 4 x 40 hour weeks. But the fact is that in week 4 you are destroying the project with your lack of concentration, and in the other you are still productive.

I guess it depends what programmers you are talking about. Some people love programming for 70 hours a week. Ok, I wouldn't do 70 hours a week, I have a life. But for people that can code for that long, and produce good software a high salary is and should be given.
There are some programmers who do a 9-5 and write shitty code, and they get paid a hell of a lot more for programming in VB than the people that code in C/C++ on worthwhile projects, like enterprise solutions and not a frontend to allow someone to print a document in Win95.

Kary Mullis won a Nobel Prize for a non-trivial
accomplishment (PCR, a common molecular
biology technique) and worked 40-50 hour weeks
at a biotech company during the entire project.
And its interesting to note that in the case of
PCR, it was a problem domain that was pounded
by many 70-hour-weekers without success.

I've been watching this thread unfold throughout the day, and I think that many people are getting the wrong impression of the way programmers work at ArsDigita.

I handle developer relations for
ArsDigita, both internally and externally, and thus am in the position to monitor the culture that's evolving here quite closely.

The scenario that Philip describes in his paper closely resembled the way that ArsDigita ran during its "startup phase". Insane hours, put
in by a small core of individuals. Were these people putting in 70+ hours a week? Absolutely. Is this an unbalanced lifestyle? In my opinion,
Yes.

ArsDigita has now cracked the 230 employee mark, and I can assure you that we _don't_ force people to work 70 hour weeks. Many people will put in a significant amount of time here at work, because they _love_ their jobs. It's their choice.

Our CEO stresses a healthy mix of work + play. I have yet to receive any bad reviews or cat-calls for walking out of the office at 6:00pm, nor have I seen anyone tagged as "lazy" who does the same. It's not about the time you spend at the office, it's about results. Period.

G.H Hardy, the brilliant English mathematician, was fond of claiming that

four hours of creative work is about the limit for a mathematician.

...And Hardy was creative. Much modern computer science rests his work[1]. So I think we can easily conclude that the folks Greenspun manages are not doing much creative (fun) work. If you are thinking of taking Greenspun's management suggestions, take heed....

[1] Major contributions to topics including Diophantine analysis, summation of divergent series, Fourier series, the Riemann zeta function, and the distribution of primes.

Greespun writes: "... the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers."

Something is very wrong if this happens in Greenspun's hypothetical workplace. Either programmers are rewarded for *writing* complex code, or what Greenspun assumes to be good programmers are, in fact, hackers who are incapable of creating and designing maintainable code.

The whole point of engineering is to create solutions that are simple, flexible, and effective - and that can be *understood*.

Writing code that the average programmer cannot *understand* is not what classifies a good programmer. A good programmer will write code that is elegant, simple, straight-forward, can be understood *and maintained* by the average programmer. It is the initial coding *solution* that discriminates the good programmer from the coder.

How many programmers do you know that fart around their
desk all morning, get ramped up around 2:30 PM and end up staying at their
desk till 7 or 8 to get their job done.

At a job I had, I got in around 9:30-10:00 and tried to work while
the other programmer in our department was whining about the boss not being
there.

At 11:00, the boss came in, and spent the next hour fixing the
other programmer's problems.

At 12:00, we (my boss and I) went out to lunch, then went around
bookstores and universities libraries, and sometimes went out of the way
to look at an interesting building (my boss was trained as an engineer,
and was totally inept at history and architecture, and thus enjoyed the
"private lessons").

We would get back between 14:30 and 15:30, where we'd
sit for the next hour listening to the other programmer's problems.

At 16:30-17:00, the other programmer would leave either
for his home or his aerobic classes.

At 17:00, when everybody else left, we started working, coding
until 20:30 or 21:00 or inspiration left us. In that amount
of time, we'd do 2-3 days worth of work. And after, most of the times we'd
go out for a beer and/or cruise for chicks...

We were three (two after the other programmer was fired for gross unproductivity)
guys supporting a whole crew of 14 people (including secretaries, executives,
accountants and other departments which weren't profitable). After 9-10
months of this, my boss told the company to screw itself and left...

You misunderstand me. I wasn't talking about inconsistent coding style, but style that assumes a color highlighter is available - for example, only indenting 2 spaces is ugly even if you do it universally, and having no whitespace in expressions is ugly even if you do it universally.

I think Greenspun is talking about product companies, not software body shops. Most companies that hire hotshot programmers to do a software product give them a fair equity stake in the company or royalties. So the "master/servant" relationship isn't as strong here. Instead of being pedantic about how many how much you're getting per hour, you're just trying to figure out the best way to get the product shipped, cash in your options, and retire. The mathematics is different than if you were just billing hours.

A difference in perspective occurs when two different people view the same thing; they both can't be in the same place at the same time so they both have a different perspective.

Thus in order for there to be a perspective difference we have to both be talking about the same thing. We are not talking about the same thing.

I am talking about forests you're trying to discredit my comments about forests by saying something about individual trees . I am discussing principles you're talking about concrete examples; which are two very different things. That is not a perspective difference - that is a difference in level of understanding.

How silly would the president of a company look saying "Ask not what your company can do for you - ask what you can do for your company"?

You are the one demonstrating perspective illusions: things in your life look big and important to you because they are near to you. Hold a quarter at arms length and it appears to be bigger than the moon - put them at the same distance and the quarter is invisible. Your job might look as important as the moon shot to you, but that is because you view your work from a very close perspective; to humanity as a whole your job is invisible. If you think that your job is as important as the Apollo project you have a distorted perspective.

More hours definitely does not always equal better code. I believe it was Microsoft who planned to have world-wide programming on a project going 24/7, with each group of programmers ending their work day by sending the code they had written to the next group of programmers who were just starting their work day. It failed horribly, obviously, because so much time was spent dealing with understanding the code the other guys had written, dealing with differing programming styles, and of course, having to deal with the MS proprietary code, which must be horrid to begin with...

It is far easier to get good code by not over-working your people. If they want to work 70 hours a week, that's fine for them. But more and more businesses are insisting that their programmers have a social life so they don't get burned out and move on. It's pretty savvy of the businesses, as they look better in the eyes of their employees and can retain their workers. Because as we all know, nothing tanks the productivity of a project like having to hire people to fill the group up. Mmm... re-training in the middle of a deadline... such fun...

Flame away, but I've never been impressed with
Phillip Greenspun. From Travels with Samantha to
this latest misuse/understanding of Brooks'
excellent book, he's had a knack for missing the
important points and not letting us know how
great he is. (even when he's humble, he's always
got something to be humble about, and mentions it)

For starters: The 10/1 productivity ratio wasn't
a "good/average programmer" stat--it was a "very
best/very worst" stat. Furthermore, although the
book was reprinted in 1995, that figure comes
from the original, published in 1975, from a
study carried out before that. Nearly 30 years
ago, in other words! Somehow that number jumps to
100 times in the article, but I'll chalk that up
to another typo.

The 70-hour idea is silly. It doesn't address
the _accuracy_ of the work done, and the fact
that it goes down after a while. Check out this
article:
http://www.fastcompany.com/online/06/writestuff. html

Also, FORCING (i.e. "encouraging") people to work
hours like that is just going to get you a bunch
of uber-nerds who will generate tons of brilliant
code that pisses off end users, because they
never talk to or deal with end users, or life for
that matter.

"Your business success will depend on the extent
to which programmers essentially live at your
office." Makes it perfectly clear who I DON'T
want to work for!!! Furthermore, he then goes on
to say, "Programmers don't have the same need for
wood-paneled expensive plushness that, say,
corporate lawyers or investment bankers might."
My question is why the hell not? As much as the
lawyers and investment bankers have a "need" for
these things, so do I!

All in all, the article didn't end up saying
much. Some people are better than others at their
jobs, and most of the bad ones don't realise it.
Big fat deal! The best programmers tend to get
pushed into management. Well, guess what? It
happens in almost every field, and is just as bad
there as it is in software engineering.

Wow! I caught the attention of Phillip himself. Thanks for the reply. Yeah, there are alot of factors I left out in the interest of simplicity. I read over the job information on your site several months ago and my memory is a little sketchy. There's the $10k signing bonus, weekly massage (is that for real?), and several other things that made it sound like a cool place to work. Hell, if I thought I qualified, I'd apply for a job, so I'm not knocking it.

I see alot of people comparing salaries on the web without taking into consideration the cost of living. Its an important factor and can't be overlooked. That was the primary reason for my post. I do consider 70 hours per week excessive though. I'm not saying I would never work that much, but if I do it, I want it to be because I want to, not because its required (explicitly or implicitly).

I think "Phillip and Alex's Guide to Web Publishing" is great by the way. I read the online version but I plan to buy the hard copy eventually. Thanks for making all of that information available.

I used to work those 80-100 hour weeks. What I've found over time is that you do not have to do that at all to be really successful.

Consider this - if a really good programmer is 10x more productive than an OK programmer, then why not work half as much? The company still gets a worker who can produce at 5x the rate of other programmers. The worker gets a lot more free time to work on side projects or train themselves.

What I've noticed over time is not so much that older workers have trouble finding work - it's that most older workers do not take the time to keep themselves trained in technological developments. That's what really kills you in the long term, not so much the fact that you are older. If you're an older worker with a lot of good projects under your belt and a strong grasp of the latest in technology, I don't think you'll have trouble finding a job.

I currently work about 40 hour weeks, and have never been more productive and creative. I'm not only architecting some interesting systems, but working within the company to help develop small and USEFUL corperate wide components. The shorter hours have never been a problem, and I'm encouraging my whole team to do the same.

It's all up to you. Take control of your career. Do not fold to the temptation to work longer hours, and make sure you try to keep innovative in the work you are doing.

Recently I moved into what you might call a "management" role - a Program Manager at Microsoft. Despite the title, my work lies much closer to the realm of Negotiator than to Boss. A PM has many responsibilities and deadlines, but s/he has no official authority to execute them. If I want something done by a certain date, I need to convince the other teams (dev, test, ops) that my way is the best way. If I can't convince them, which is often the case, then my job is to discover a compromise.

Greenspun has hit the nail on the head about management by consensus. When friends of mine regale me with tales of old-school management I try to show them the superiority of a system where the leaders are the actual workers, and the titular bosses are nothing more than organizers of the group's talent.

In tech it makes sense to follow a more democratic model. If the workers aren't intelligent enough to contribute to design decisions, why were they hired in the first place? And if they are intelligent enough, why squander that ability with petty micromanagement?

Evaluation system, forced curve on a scale of 1,2,3. 3 being deadwood that floats and 1 being raise the freakin dead, smote the rock, etc. etc. But the VAST middle area which has a range of RIP (retirement in place) to just saved the company 25 million dollars which translates to a $250 million revenue stream.....

Ones, twos threes are relevant because they are the ONLY factor in determining the difference between what could be a 0% and a 20% bonus. Given that MegaTelCo-Blue doesn't reward its employees any other way and the options they hand out are about 35% under water.

By making people work 60+ hrs/week or hell even 50 you are mostly creating burnout. First of all most people can't do that forever, one week every few months sure, every week, no. And we are responsable for it as for years we have been willing to work 70 hr weeks without complaint or extra money.

This is *very* true. I am a sysadmin type trying to get into programming. I know Perl ok and am just getting started with C/C++. With that background I can set down with the Linux kernel and read a bit and understand many parts. This is because it was designed to be understood and used by more than one person. I'm far from average at this point (a rank novice)and yet I can understand the kernel for a very complex and powerfull OS a true testament to those who have written and maintained it. So based on what I've done and seen I have to agree that a good or great programmer will write code that is obvious to even a novice, once it is written. Just like with you human language you can always read more than you could have written. Think of all the really great inventions all of them are brian dead obvious, once you see the solution. The ones that don't make sense don't get used. I think Greenspun likes the "hacker" myth just a little too much.

Americans are way behind the power curve on working these ridiculous hours. Europeans have known for quite a while that productivity beyond about 40 hours a week (36 in Germany) goes down. For every hour you spend in the office past 5 PM, productivity doesn't really go up.

How many programmers do you know that fart around their desk all morning, get ramped up around 2:30 PM and end up staying at their desk till 7 or 8 to get their job done.

I'm guilty as charged.

When you know that your boss EXPECTS you to leave by 5PM, you tend to manage your time better to ensure that your job is done by then.

I tell all the folks who work for me that if they're staying past 5, they're not managing their time. Its a sign of weakness, not dedication. They're happier, more productive, and the divorce rate went down;-)

I've managed teams of programmers before, and lived to regret it as well. I'd rather face an angry customer complaining about how their Linux box got hacked again than try and get a team of unwashed, unmotivated programmers to put out a working product built to spec within the amount of time allocated.

I'm sure that programmers here will claim that their huge intelligences are responsible for their constant need to change the task they're doing and their complete lack of focus, but it means that out of every hour they're present, only half (if you're lucky!) of it will be spent working. The rest will be spent browsing the net, checking emails, getting drinks, going to the toilet, scratching their armpits and any other activities that can help them avoid doing what they're begin paid for for another minute.

And when they get in in the morning then you can write off the first couple of hours totally, as they're still shambling zombies from an all- night pizza, BO and coding session that only ended three hours ago. In fact there have been two occasions I had to send someone home just to shower, because we had clients coming in. Not that clients get to see the programmers if possible, you need to give the right impression after all.

No, after a frustrating year of dealing with programmers I have the greatest of respect for product managers and the like, because they are the ones that have to try and get work from people not used or willing to getting a job done. It's like squeezing blood from a stone.

Those of you protesting should take consolation: there will always be a place for you. However, you may never realize how fast good software can be written by small teams of top programmers working intensely--and how exhilarating is the experience.

A flat-out run down a double-diamond slope is exhilarating, too. Even with a break to go back up the lift, though, you either take time out for lunch or you're going to be one of my (ski patrol) customers.

Hardware is more my field, despite the CS degree, but we spend our share of wild creative rushes and there's nothing new about the pressure-cooker style of project management (read Tracy Kidder.) Until very recently the Wisdom was that those of us over (30-35-40-45; you pick one) were past our prime and due for replacement by those younger, childless, and more willing to put in the hours.

A funny thing happened. The industry seems to have woken up one morning and realized that after 30 years of steering projects through rocks (and all too often running into them) we Old Farts just might know some things that the fresh faces don't. Such as that the biggest risks to a project aren't technological, they're human and that the people on your project are the same version 1.0 types who built the Pyramids.

PG might want to seriously consider that his software-management style absolutely depends not on taking time to do things right but always being able to do them over. When your production is bits that might sound reasonable, but when it's measured in kilotonnes of steel or requires a half-million in mask tooling you had damn well better get it right the first try more often than not. For that, I want people who are rested, awake, and not already 95% gone on to their next Artistic Creation.

I've learned a bunch of things from this discussion. Let me say that I did not intend "Managing Software Engineers" to be the last word on the subject. That's why there is an "add a comment" link at the bottom of the page. My experience is limited to the handful of commercial and open-source software products that I've built plus some dozens of Web-based systems built on top of ACS in which I've been peripherally involved. My thoughts are intended to be useful for people who find themselves similarly situated and to be a magnet for contributed thoughts from people with better expertise than my own (see Chapter 1 of _Philip and Alex's Guide_).

The other day a Sloan MBA student asked me if being an entrepreneur was worth it. By that he meant the long hours, the risk, the pain of seeing one's baby disfigured by new management, venture capitalists, etc. I reflected for a moment and said that "Yes, it is still worth it. Being an entrepreneur means that you get to pick the people with whom you work."

So I guess that's what it boils down to for me. I never enjoyed working inside organizations built by others, even if I got to go out to the opera every week and spend long evenings at friends' houses. But it has always been fun for me to work at my own companies because I love the people that were pulled in (in the case of ArsDigita, there are my co-founders Jin Choi, Tracy Adams, Eve Andersson (also my girlfriend!), Bruce Keilin, and Aure Prochazka, plus a lot of really great people that joined just after the protoplasmic stage). Did it ever upset me to spend long hours with these guys? No! We were getting a lot done and being positive reinforced by the reaction from programmers worldwide, end users, and by our own growth in skills. Would we have been happier in the long run if we'd gone to work for Ciitbank in the IT department, married and had kids? Probably! I wrote about that in Travels with Samantha.

Anyway, I'm glad that my article spurred this lively debate! 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.

Mathematics is a whole other kettle of yarn. It requires a far greater level of abstract thought than programming. A mathematician working on a problem is exercising a very narrow mental facility to its utmost limits. Programming typically requires less concentration and offers more variety. Maybe it approaches mathematics for really deep algorithms and really subtle bugs, but that's the exception in most programmers' lives.

I'm not dissing programming. But it's well known from anecdotal evidence at least that the all-night hack session, in which a programmer remains intently focused on a problem, is entirely feasible given the right challenge and environment. This is barely imaginable in abstract math. Abstract math is deeper by far than what most people think of as mathematics.

Writing code that the average programmer cannot *understand* is not what classifies a good programmer. A good programmer will write code that is
elegant, simple, straight-forward, can be understood *and maintained* by the average programmer. It is the initial coding *solution* that discriminates
the good programmer from the coder.

The above is very true, but the point you argue against is not the point the author made. He didn't say the less skilled programmers could not understand the better programmers' code. He said they could not understand it much faster than it was being written. Code's quality is not the only issue in how quickly it can be understood.

For example, a programmer with a strong CS background can write code based on standard concepts that a programmer with a similar background could quickly understand, but that a programmer without that background would take much longer to understand. The time is really spent learning the concepts.

Also, a lot of code, especially web related code, uses technologies that only some readers are familiar with. Database access, CGI/Servlet APIs, sockets, etc. can be transparent or hours-with-a-manual difficult, depending on the reader's background. This applys to languages too. I can read Java at a decent speed, because I use it every day. JavaScipt takes longer, because I only use it every few months, and because I never wrote it full time. (And I won't even start on VBScript/ASP.;-) Many programmers don't have the luxury of limiting themselves to a single environment-of-choice, and learning is becoming a larger and larger part of the average programmer's day. And the difference between the productivity of learning-while-doing and just doing is always going to be huge.

I know well that if I don't take lunch, my turns are going to get sloppy at the end of the day. But human physical limits are much easier to reckon than mental limits.

A study that says "programmers are less productive past 40 hours" is probably talking about a random assortment of programmers working on projects in which they have little personal interest, in an environment where they don't feel especially valued. Phil is talking about starting with people who have demonstrated strong mental capacity, and handing them a challenge and a sense of ownership. My direct experience tells me that many of them will want, and be able, to work 70 hours a week without ill effect. No pressure-cooking, whip-cracking management involved.

It's not for everyone, every project, every situation. If you (as a project leader) have mediocre or unenthusiastic programmers, or are not willing and able to inspire, empower, and accept some risk, forget it--go back to defensive projecting, long design cycles, and 40 hour weeks. These get the job done. But when you assemble the elements that make bright hackers want to throw themselves into the project, it's like a powder day versus New Hampshire ice.

If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.

I am not sure I get this. Is this a 3-7x improvement over the generally pathetic grad assistant salary? It surely can not be a 3x-7x improvement over a programmer with a similar age with no Ph.D who has chosen to work in industry instead of grad school.

Even then, I have yet to see a Ph.D that makes 7x his grad assistant salary, unless his grad assistant salary was in the 10K-12K range. Heck, if one can live with that salary for 4-5 years, then perhaps he really deserves a 7x increase.

The problem is that managers get misled into thinking that this works because it does, for a month or two. For the first couple months, you can bang out eighty hours weeks producing top quality code. Then your productivity falls until you have to stay there eighty hours just to do what you normally could do in forty. And then it keeps falling.

The average person can only work 40-60 hours a week without burning out. It is very bad to plan otherwise. And I suspect that in a lot of cases distributing lots of cool toys means that the coders are there for eighty hours but perhaps working for only sixty. That's not a bad thing...

Hell weeks with long hours should be saved for important deadlines. You want people relatively rested so that when emergencies hit, you can throw things into overdrive and become a hero. Otherwise, you'll find that when crunch time comes, you've got nothing left. Never sprint in the first mile of a marathon!

Don't wanna haul around radioactive waste in cardboard boxes? Or carry ebola samples in ziploc bags? Or work in mines with no wall or celing supports? Or work 16 hours a day and live in soot covered housing on company grounds? Well, we're paying you $150K/yr, so shut the fuck up, whiny mama's boy.

Is "high pay" the latest excuse to justify crap treatment?

It gets worse. Get married? Have a kid? Need to cut back the work hours to "only 40-50 hrs/wk" as a responsibility to your family. Then you get fired. And no IT company will hire older workers that have a life because they won't work 80 hours weeks (like recent college grads and H1B visa workers can), even though their contract never mentions more than 40 hours, or mentions overtime pay or days off for additional work hours, which employees get fired if they actually try to claim that pay/time. And of course having the company cell phone 24/7 on weekends or at night is never considered to be so much as one working hour.

If companies don't start treating IT workers better, tech unions WILL form. Think they're a bad idea? Hate untions? Hate the corruption? Hate the politics? Hate the strongarming? Well, hey Mr. Employer, then this is your lucky day, because you have a chance to FIX THINGS NOW, before the union forms. Otherwise, don't start whining when some union has your business upsidedown by the balls down the road, because you had your chance to fix things now. Why are you wasting time reading this while your IT staff is 6 braincells short of pulling triggers from overwork? Go and make their lives more pleasant. Yes, it'll even boost productivity. Happy workers are productive workers.

Netcraft says [netcraft.com] arsdigita.com is running AOLserver 3.0+ad5 on Solaris. If the OpenACS on a dual-processor P400 has no load impact when a Slashdot article linked to it, then how can a site running Solaris be slashdotted off the map all day? I assume that most Solaris servers are at least as capable as a P400.

Greenspun's right on except for the hours. Maybe he's right that good programmers are more productive pulling exceedingly long hours, but it's an awful way to treat workers. Sure, we get paid buttloads more than 19th century factory workers, but the social consensus that developed while union members were getting their skulls bashed in by private corporate armies and federal thugs in the first part of the 20th century was that some conditions are unreasonable no matter what the pay. If you have a spouse and children, to work 70+ hour weeks is to be neglectful, period. Unless we are collectively planning to continue the popular practice of riding young programmers like cheap whores and discarding them as soon as they turn 35, this sort of thinking must be met with the derision it deserves.

Past a certain point, productivity has to give way to the well-being of the worker. Antebellum slaves were more productive working from before dawn until after nightfall, but their life expectancy wasn't very high. The Japanese, who pioneered this sort of thing in the white-collar world, are finding that the heart-attack rate for men in their 40's and 50's is alarmingly high. There is nothing anyone is doing in the business world, <sneer>"dotcom"</sneer> or not, that is worth grinding people into the ground like that.

"put out a working product built to spec within the amount of time allocated. " You have complete specs? How unusual. As a programmer I have found that the customers desires, and therefore specs, change during the course of a project. One of the hardest things to do is to get a customer to agree that "That feature needs to be in the next version." Because of this, the spec is never complete, therefore the project never is.

It depends on what is being worked on. Take example of a code for a complex database system, cryptography, tcp/ip stack or some complex program. Even when implemented in a simple clear elegant solution, the average program will be lost, simply because he does not have the right background, so he will spend time catching up. But I still agree with you that something is wrong with Greenspun's hypoehetical workplace. In a good project, programmer's don't need to be reading each other's code, except during code review and when hunting for bugs. That is why we have modules, The very good programmers work on important part of the program, the average programmers work on the other parts, the newbies, work on perhaps the installation and simple parts.
Nevertheless, the article is a good article.

I agree with your statements, and I am at a loss to see why he is so often quoted and treated as an authority.

Most of the oh-so-highly regarded advice on his photo.net site is typically useless drivel. Use Oracle?? Gee thanks Philip! I would've never have thought of that. Use TCL? Gee thanks Philip, but no thanks! Keep my html simple and clean? Gee no one ever thought of that before!! [yahoo.com].

What a lot of people don't realize is that programming is hard work. Brain work. People don't realize that the brain is just like a muscle. It gets tired. It needs to be stretched. Most of what is called "play" here is the same as stretching muscles. You've got to do it, or you'll get a brain cramp. And that's not fun, if you've ever experienced it. After a long coding session, your brain locks and suddenly a trained monkey could do better than you could.

Anyone who has coded a long time has had the experience of having a hugely frustrating problem, going off for a movie or a nap or whatever, coming back, and fixing the problem in a few minutes of coming back.

Of course, you've got to make sure you do real work too. Twenty minutes playing videogames can boost productivity tremendously after a long session. Three hours of videogames is obviously just slacking.

This is one reason like coders like visceral twitch games like Quake. They allow us to turn off part of the brain and limber up for a while.

The economy is good right now--very, very good. So good that We The Programmers can often dictate the terms of our employment.

Being human, we get greedy. We willingly work unhealthy hours at the promise of scrumptiously high wages. To help us along with being in the office 70 hours/week, employers give us cushy toys and comfy offices.

What happens, though, when the golden days end?

What happens when you wake up one day, find that you don't have the comfy office environment you once did, that there aren't fifty gazillion companies who'd hire you in a second, and, because you've done it so willingly for so long, you're still expected to work the same 70-hour week as before (or stand to lose the job you can't replace in a heartbeat anymore)?

The companies are only your friends now because it's the only way they can keep talent. What do you do when the tech cup no longer runneth over, and you've already willingly committed yourself to a dangerously unhealthy work week?

We're taking the work of generations' worth of workers' rights activists and throwing it all out the window because of a sudden, unexpected, and extremely volatile explosion in the amount of leverage the common tech worker has. We're willingly launching ourselves back into indentured servitude, and it's only going to be to our benefit for as long as the boom lasts...

...as practiced in most shops it is not engineering. Can you accurately predict what the code will do before you run it? Betcha most of us cannot. Real engineers can predict the properties of the most complex product they are working on before implementing it, be it buildings, circuits, mechanical structures, etc. (Or even complex large automated computer systems.) For this to happen, they have models that accurately and completely represent the contemplated system. I have met few people in the software industry that even realize this.

If we built bridges the way most people build software, we'd all be dead because the testing (and problem discovery) would happen in production.

One of the paradoxes of software engineering is that people with
bad ideas and low productivity often think of themselves as supremely capable.

Actually, this isn't unique to software engineering.
I recently read a fascinating paper on that very subject,
which shows that the least capable are not only unable to
perform a given task, but they lack the ability to judge their
competence at that task, and hence grossly overestimate their abilities.
See http://www.apa.org/journals/psp/ psp 7761121.html [apa.org].

...but I'm not sure I agree with his concept that it is necessary to work 70-hour weeks (though for unreasonably long hours, they do pay unreasonably large salaries).

What do you consider to be an ureasonably large salary? Are you talking about the $70k they (ARSDigita) pay their entry level programmers? Let's think about that for a minute. $70k for 70 hours per week, that would be $40k for for a 40 hour per week job. Mmmm, not looking so good now, but wait, there's more. Let's consider the location of the job, Mass. What's the cost of living there compared to your current location (hint: its pretty high). According to this site [homefair.com] $40k in cambridge is equal to about $24k where I live. That just plain sucks. Remember, big numbers don't always mean big quality of life!

One way to stop pathetic arguments like this one is to unionize. The current bargaining system for negotiating salary and terms of employment are slanted too heavily in the corporations' favor. This has happened in a number of industries over a long period of time. One way to effectively deal with it is to unionize.

Comments? I'm an independant contractor, so I have less to gain from unionization. That said, I'd be glad to take a leadership role in the effort. Anyone else?

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.

Maybe your best people have a life. Maybe they are married, have kids, or have hobbies. Maybe they work on a really cool open source project outside work. Maybe they have better things to do than dedicate every waking hour to your ever so important project... maybe they are smarter than you think!

And finally, maybe they are good enough or smart enough to accomplish more than what's required from 8 am - 6 pm. And you just want to extract every last ounce of servitude you can. Not a nice way to treat people.

Agreed. Some programmers are putting themselves in a dangerous position - to themselves, and to feeding the delusion some (not all) companies have.

We *DO* have the talent to broker deals, to make a difference. But to do that we need to be willing to change, to find the right jobs, and to sometime take that lower paycheck in exchange for sanity.

It's also important that companies get realistic views of programmers and programmer needs now. Otherwise they will make plans based on inaccurate information. Taking a job that gives you time and sanity is one small way to contribute to this.

And these jobs are out there. I'm employeed at a consulting firm with training, bench time, and a reasonable support-the-employee attitude. I even make more money than where I used to be. Best of all for them, I WILL work those long weeks when they're really necessary, because I won't be burnt out.

This is true all too often, but well managed projects may not be as rare as you think. I can tell you exactly what new features will exist in the next releases of my applications and how they will look and feel to the user. In a well run project, you can write the app's user documentation before coding even begins. That's one difference between a programmer and a developer/engineer. Unless development is done what I call cowboy-style (come into down, get the dirty work done, then get out asap, leaving a mess behind), any good developer should be doing pseudo-engineering.

No, it is Yin and Yang; for the most part when people state truths there are exceptional conditions which violate those truths.

What you are doing is hoping to discredit the truth of what I said by pointing out those Yin and Yang exceptions.

That sort of tactic only works if the people reading these comments believe that we live in a black and white non Yin and Yang world. In the past such techniques were successful: people didn't realize that Yin and Yang is how the universe works - but as Western minds wake up to reality - tactics like yours will be less and less successful.

Where to start? This is the biggest piece of pseudo- management crap I've seen in ages. Outside of a few well-worn chestnuts ("Positive reinforcement is better than negative reinforcement. People do what you reward them for doing." Duh, and duh.) this is a recipe for disaster.

Rather than do a point-by-point commentary on this piece of fertilizer, I'll just say that, Once Upon A Time, I was part of a proposal effort where our competition followed Greenspun's philosophy. Our group used the classic software- engineering management style. We not only won the bid, we humiliated the other group. The client rated our system superior in every category, including price.

Yes, we had our superprogrammers. Yes, most programmers were average. The main thing that made this project such a success was talented management and adequate funding.

Over here we don't get wicked huge salaries (excellent lifestyle by NL standards), but we do get perks from hell.

-28 days/yr vacation, off the bat. I started here June 1 and have already burned my 16.5 days for the year.
-hella perks. I went for an all expense paid corp vacation to South Africa. Spent the whole week drinking corp beer and eating like a king. Oh, and there was the whole safari aspect
-decent working hours. I slog 45 hrs usually. no more, not much less.

I don't get to drive a hot new car as I would back in the US. I also miss my truck, but living is good.

Well, the ArsDigita link is slashdotted. Strange contrast to their claims of the reliability of their server/software architecture that they hype up to high heaven on their site. Perhaps overpaying programmers/sysdamins to crank out Tcl code or set up AOLserver boxes for 70 hours does not necessarily work for designing stable Web sites.

A neighbor of mine was a single guy who owned his own house, has a nice boat, nice car, and over a million dollars (if he sold his investments) He had a stroke at 39, and will spend the rest of his life in a nursing home unable to enjoy any of that money. Well, unless you call paying a nurse to help you to the bathroom enjoying. Personally I respect my fellow humans too much to want someone else wiping my rear end.

Point is, if you live a healthy life to 75 or more, retiring at 38 is great and worth the years of working too long of hours. If your health disappears what good is all that money.

Of those I graduated from high school with, several didn't live to their 5 year class reunion due to accidents. (I'm not even counting drugs or suicide which account for a couple more) Accidents happen, and there is nothing you can do about them.

therefore, I'm enjoying my life now. If I live to be 123 and am healthy all the time, great, but if not I've enjoyed what I had. Mind you, I am puttting a large sum of money into retirment funds so I can retire early, but I'm not working more then 50 hour weeks (and that much rarely) so I can enjoy what my health while I have it.

"It is easy to make an office more entertaining than the average person's home. Most people have a TV at home but they don't have friends with whom to watch it. "

Comments like this and obvious expectation to work 70 hour weeks seem rather condescending and also imply an expectation that work is more important than your life. In my experience, at 70 hrs/wk, work becomes your social life too. Sorry, but that's not acceptable to me anymore. I have and want a life outside work. I recently got engaged, and in my opinion, family comes first. Then friends. Work should have a lower priority than your happiness, and it shouldn't try to provide all those things (afterall, most employment that I've experienced in the US is "at will" and they will drop you with no compassion if they need to make cutbacks). I might love my job, but not over other aspects of my life. I work to live, not live to work.

If other people want to work that hard and enjoy it... fine, but don't be resentful of those who want to work 40hr weeks, and don't try to make them feel guilty for that. I've seen too many examples of managers trying to manipulate people with families, outside interests, etc, by telling them that a load of other people in the office are working twice as many hours. That's not fair: most of those other people are either single, or slowly destroying their personal relationships. What's the point of working 70+hr weeks on a project if you wind up with a divorce? You've lost somebody from your life who should be there long after you've left your employer. You might have earnt a lot of money (assuming that the project succeeded), but it's no good if you have nobody to share it with, and enjoy life with.

Having thus been rewarded for doing nothing, the programmer tries it again the next month

is absurd, factually incorrect, and, when you think about it, contrary to what is known by every open source contributor! I recommend Kohn's book highly to anyone planning going into management, in part because what he has to say about why people do difficult intellectual work dovetails perfectly with what people have observed in the open source movement -- only he was writing back in like 1994.

In fact a lot of what Greenspun talks about as "obviously" true has no actual support in research. He talks about how overtime is such a wonderful thing, and how it makes companies so wealthy. I have in other places [slashdot.org] noted the mathematics of wages and resources which are so advantageous -- to the company. After all, if you donate 20 hrs beyond a 40hr work week without further compensation, your manager gets a project done for half the money (and possibly in half the time, if there is no exhaustion penulty). Very efficient that.

What of merit there is in Greenspun's article was long ago written by Orson Scott Card in his famous essay "How Software Companies Die [carolyn.org]" -- the one which originated the metaphor that managing programmers was more like keeping bees than planting crops.

Frankly, Greenspun comes off as manipulative and exploitative and pretty skanky. And superstitious: it sounds like his explanations of his company's success are post hoc, and reflect more what he'd like to believe that his actual practice.