In honor of the fact that this discussion board is hosted by Phil Greenspun, I read one of his recent articles on management of programmers.

Greenspun writes: "Software engineering is different because people at all levels of the organization perceive themselves to be equally intelligent."

-- Anonymous, November 06, 2000

Answers

There are two different kinds of 70 hour weeks; for the sake of argument here I'll call them the "microsoft kind" and the "netscape kind".

The Microsoft kind is where you're a new grad, fresh out of college, and you don't know anyone in Seattle. So when you start working at Microsoft, and the halls are full of interesting fun geeks and you have unlimited geek toys to play with, and there's nothing better to do with your evenings, so you hang out at the office a lot, but you're happy as a pig in mud.

The Netscape kind is where the company uses "management by death march", every project is so ambitiously scheduled and overstaffed (yes, overstaffed, not understaffed) that you have no choice but to code for 70 hours nonstop if you want to meet the ridiculous deadlines. Your college friends who went into Management Consulting and Investment Banking work in this kind of environment, too; the work is hard and not so fun and the hours are ridiculous.

Remember that Phil is talking about creating a stimulating, fun environment of the type where programmers want to spend their days. That's the Microsoft version, not the Netscape version. Eventually, when you Get A Life(TM), Microsoft won't look at you askance if you start going home at 6, because you're still getting just as much work done.

When Phil wrote: "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," he was, sadly, right. You can be the least productive person on my team, after all, there has to be one such person, and you can be the first person to go home (there has to be one of those, too) but you can't be both.

-- Anonymous, November 07, 2000

i've always admired greenspun's writing (own the alex book), but this was quite difficult to read. when i saw the following:

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.

... all i could think was, 'what a complete jerk.' i was baffled when he said of the landmark work 'peopleware' that:

Peopleware was probably written to help ensure success for internal corporate IT projects where there isn't any competition and delivering three months late won't change much.

of course, i'm not a programmer. perhaps great programmers don't have personal lives, and the best way to lure the best programmers to a given organization is to write treatises urging them to work 70 hours per week. i'm curious as to what joel, a software CEO, thinks of prof. greenspun's thoughts on programming.

(i also couldn't help but think it was a bit telling that arsdigita.com went down after this piece was 'slashdotted.')

-- Anonymous, November 06, 2000

I like Philip's writing, so I followed the uproar over this pretty closely today.

I think a lot of people missed the point of the article, and focused on the "work 70 hours a week" statement. The Slashdot discussion didn't get beyond that (though, considering /.'ers unwillingness to read linked articles combined with the summary mentioning the 70 hours/week deal, that's not surprising). Over on Hack the Planet, David McCusker chides Philip, saying "It's a sorry thing the computing industry is run so badly that long hours are needed to get anything done. This is partly because the tools are such that busywork is necessary to make progress. This makes folks think that busywork is productive when it's not."

I think these people missed the point in four ways. First, the article was about more than the hours. Second, Philip is not suggesting forcing employees to work this many hours, he's trying to encourage them to do so. Third, working in the company of greatness inspires you to be great. It's part of the draw of companies like ArsDigita and Fogcreek. ArsDigita has people beating down their doors to work there. Finally, the point is: all things being equal, a group of people working more hours will accomplish more than the same group of people working less hours. This means when the tools have advanced far enough that programmers are saved from busywork, those programmers working more hours are still going to get things done faster. Greenspun says this is because of the problems with communication described by Brooks.

Is he right? I'm not sure. Certainly, you don't want people working that much all the time, they'd kill themselves. But, in the business ArsDigita is in, speed means survival. Programmers who don't want that don't go to work for ArsDigita.

P.S.: To those of you who think I read too many websites: I do. I'm trying to avoid doing my boring homework . :)

-- Anonymous, November 07, 2000

I think the article is a crock of ummm...stew, yeah thats it. Implying that good programmers MUST work 70 hours a week, or should be convinced to work that much is bloody ridiculous. Also saying that if the programmer doesn't comply with this 70 hour per week schedule that management should find a way to terminate that person.

Well...I am a programmer, and I refuse to work more than 40 hours a week unless the something very radically important comes along. Why? Because I have a family. My wife, and my personal life is more important. Why am I working? To support to personal life. I love programming and I love what I do, but that doesn't mean that my work should become my life. That goes for me and any other programmer.

Also, being a human being and not a machine, I know that after 10 hours per day of programming, i become less and less productive, and more mistakes creep in. I find these mistakes and fixe them the next day....mistake that would not have happened on a fresh mind. So making a workplace as fab as possible to 'convince' a programmer to give up everything for the company is bull. For a programmer to be truly productive, (s)he must have the tools, the know-how and a productive environment. Included in this is good rest and a clear mind. People do not have this working 70 hours a week. Performance degrades in everyone. Simple as fact.

I would really hate to be branded as unproductive etc because I don't put in an extra 30 hours per week...the key to being a good programmer is quality not quantity

-- Anonymous, November 07, 2000

just a quick followup, it is important to note that phil is not talking about a choice or about a direction to encourage his programmers. he says he will fire people who do not come around. i'll quote again:

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.

it seemed like some of the previous posters missed this point, as did i the first time i read through prof. greenspun's piece.

i'll also take the cheap shot and pick the low-hanging fruit, albiet with tongue at least half in cheek: if greenspun is such a good manager, why did he move over to the chairman position, why not remain CEO?

-- Anonymous, November 07, 2000

Amendment to previous message: This article however, does proprose some good ideas however. Keeping a 'better than home' workplace is good. No one wants to dread going to the cubicle farm, or the dungeon. I am still in the fence about bonus's. While it is still just a carrot on the pole, it does give concrete evidence that the hard work had paid off. Positive reinforcement is definitely spot on. Also methods of raising average programmers to good programmers and good programmers to great programmers is definitely spot on as well. Invest in the help and it will pay for itself in productivity and quality. (But the Netscape deathmarches won't do that). I am not one hundred in agreement on the ownership. Psychologically if I own part of the company I will work harder, but 5% of nothing is still nothing. And most of the time that is what it will work out too...its too much of another carrot on a pole.

-- Anonymous, November 07, 2000

Unfortunately it boils down to just another sweatshop. They have better chairs, but it's still a sweatshop.

-- Anonymous, November 07, 2000

--Remember that Phil is talking about creating a stimulating, fun environment of the type where programmers want to spend their days.--

Not really, Philip is just trying to make sure everyone else in the company is behaving like he is, i.e. sitting in front of a terminal as much as possible (whether or not they are actually doing work.)

I don't usually like to make ad homimeim comments about the author of an article in response to an article, but I thought I should say a few things, since people are confused about Philip's real intentions when writing.

Philip's writings on software and software management should be read with caution, because he is neither a skilled software engineer nor has he ever "managed" a group of programmers. He is a decent "hacker" style programmer; i.e. he can get stuff done, but it is ugly and sub-optimal. In his own software, the ACS, nearly everything aside from the first few revisions of the bboard software was written by someone else. The bboard was certainly no masterpeice. I guess since he has made a good amount of money hacking, his inclination to write about software engineering can be excused.

The management piece is different, though. It seems extremely odd that he thought that writing this piece was necessary, and that he thought himself qualified to do so. To my knowledge, Philip has never managed a group of programmers, unless he was hired as a manager at HP fresh out of MIT. ArsDigita has pretty much been a free-form "management" situation until the middle of 2000. All the toys are also a relatively new development, and are being phased out because the new management is missing their numbers. The 70 hour + work weeks are mostly a remnant of when there were too few people and too much work to do. There are people at the office 70 hours a week, sure...but no one really programs 70 hours a week, if they did, when would they have time to play foosball, nintendo, read slashdot, eat frozen pizza and drink gallons of diet coke?

Mostly Philip writes this stuff because he has some very real, yet very bizarre need to be perceived as academically valid by... some group of people...I'm not sure who. Judging from the highly strange photos of himself decked out in a PhD gown at www.arsdigita.org, I would guess the academic computer science community. I guess that is the fate of children raised by MIT.

-- Anonymous, November 07, 2000

Haven't had time to read /.'s page on this (I was working on homework and refreshing my favorite CNN election page) but here's what I took away from Phil's remark (and Joel's comment on it).

Phil doesn't like AVERAGE programmers who leave "early". I think if you're one of the STARS who is a hundred times more productive than the average, you probably have flexible hours. (In my experience those folks work around 50 but not too much more except in crunches.) If you're AVERAGE and failing to work hard (including long hours) to get better, then he wants to move you out because you're guilty of complacency.

I was much more interested in Phil's remark, "Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality..." I am going to look for the research on this. Do others agree?

For many years my rule was that I would not return to work less than 8 hours after leaving it. (1 hour each way for commute, 30 minutes for a shower etc., 5-1/2 for sleep.) During serious crunches it was sometimes more effective to sleep at the office but I insisted on one of the couches (not the floor) or the hotel in the industrial park nearby. Now after many years of crunches and death marches I am working on improving my health by adding some time for swimming and cooking my own food occasionally (and ordering myself a better chair) so I've increased this to 10 hours. I hope I'm not guilty of complacency but maybe I just have to leave the industry...

-- Anonymous, November 08, 2000

Jeez, I dunno, it seems to me that the point isn't so much a hard and fast rule of working 70 hr weeks, or if you're going home at 6. (well, then net goes fastest from 3-4 am until around 9 ;) My take on the point seemed to be that if you're going to get the maximum return on your investment in bodies, you'd better bloody well look after them.

I also think that this means if your bod's have lives, then those lives ought to be welcomed into your establishment. For those of us like me who have kiddies, wives, puppies etc would really appreciate being able to have the family come in & mix with the other ppls families, have dinner, then have them go home, do a couple more hrs work. (sounds kind of like the in-house big screen cinima example really).

Now what this really does is provide support for the entire lifestyle of your bod's, not just the 'good mornings' and the 'screw you guys, I'm going homes' that typify most working environments.

I think the organisations that can support & help balance the family/work lifestyles are the ones that will truely get the dedication that's required to maximise the ROI and speed to market.

P.s. my organisation has recently picked up my entire family & temporarily relocated us to the other side of the country, providing a fantastic resort style appartment in the middle of the city etc, on secondment to help out with a project we're working on. Now, all I need is a bloody key so I don't keep getting kicked out at 6 *grin*, but that's next week when we move to a new building. I'll let you know how it goes if you like :)

-- Anonymous, November 08, 2000

I believe I'm a good engineer, and I work a 30-35 hour week. Less in some weeks. The reason? One of my children has a life-threatening illness. He's OK, but anyone who thinks I should be at work in the evenings, at weekends, or on clinic days has some pretty weird priorities. If Phil thinks I should be terminated, fine. Happily I don't work for Phil.

Before my son got ill, I used to work 35-40 hour weeks. Sometimes 45. I haven't worked evenings or weekends since the birth of my first child. Work is (mostly) fun and interesting, but being with my family is more fun, and much more interesting, and always will be.

Are there really mothers and fathers out there who find a work environment more interesting than playing with their kids? What kind of sick people are they?

-- Anonymous, November 10, 2000

One of the most interesting things about the whole article is this: Phil trashes Peopleware, but all his examples on "Managing Software Engineers" in the article are based aroun the work habits of MIT undergrads. On /. he adds expereince working with the original seven founders of Ars Digita.

Wake up call: of course undergrads have bad work habits, for crissake. One of the things that University/College is supposed to teach undergrads is how to move from the highly-directed high scool environment to more self-directed study. I'm not especially old, but I've been working for nearly a decade now, and I would have no time at all for anyone trying to manage men based on their observations of a bunch of late teen students. Older, wiser people than me would probably be even less keen on the notion.

And people who start companies have fundamentally different motivations to people who join later. Managers who can't recognise that there's a fundamental difference between the motivations, and hence behaviour, of one of the first dozen employees of a startup, high on excitement and equity, and the hundredth employee, shouldn't be in charge of a company.

The /. comments by philg only undermined the article: talking about wanting to have a company that changes the world is all well and good, but let's be honest; the next Linus or rms will not come into being using ACS to cobble together web sites. Moreover, a strategy allegedlt for managing the top thousandth? millionth? of people should be represented as one, not a strategy for managing software engineers in general.

-- Anonymous, November 17, 2000

What sort of lasting principles of IT management came out of this whole spark of a discussion?

-- Anonymous, November 20, 2000

Well, one lasting principle is how many people loathe the assumption that they should work 70 hour weeks. It's interesting to me on a number of fronts. There's already ample research to suggest that for the overwhelming majority of people, long hours are counterproductive. Anyone who's been involved with trying to retain and recruit staff knows what a painful and expensive business churn in a company is, especially in IT.

Yet many companies still blindly insist of preparing schedules that require death marches, as though staff who've signed up for a 40 hour week should be expected, as of right, to work absurd hours. To me, that suggests that:

a/ Too many companies have perverse attitudes about how to treat staff (perverse in the sense that said treatment in self-harming).

b/ Too many companies have poor planning processes for development and roll-out schedules. Hiring people to work 40 hours and asking more indicates mistakes have been made with staffing levels, or planning, hiring people with appropriate talents, or what have you.

c/ Too many people assume that programming is like shovelling dirt, building fences, or milking cows - a straightfoward task where accomplishment over time is a fairly linear chart. Programming is thinking, and thinking isn't amenable to a linear view of accomplishment.

-- Anonymous, November 23, 2000

One thought I forgeot to include in my earlier note: Computer science, like, say, Linguistics, is still a young science. Software engineering is like pre-Newtonian civil engineering. People erected cathederals all over Europe (and, having jusk visited Ely and York Minster in the last few weeks, impressive catherderals) without a rigorous science to back them up, but the engineering of cathederals was actually a pretty haphazard affair - collapses and delays were not uncommon, since everyne was just proceeding of a bunch of rules of thumb.

I think it's wise to remember when managing software projects that we're building cathederals. Some work wonderfully, some don't, and we don't actually have a rigorous set of rules to explain why.

-- Anonymous, November 23, 2000

The truth is, programming is labor intensive and management is very interested in long hours. One cannot possibly have a decent life while working 70hr weeks, especially because most of this kind of work is mental effort. It's just against the human nature. So, whatever highly enlightening Mr Greenspun proposes, the truth is, they'll bring in millions of H1B Hindus with requisitioned visas and set up sweatshops all over the place. Get real, you idiots. You're not the ones who's making money there, you're there to produce something they can sell, and when you get burnt out, they'll excuse you the hell out and replace with a new batch of either young-fresh-out-of-college or H1B indentured labor (or, maybe, the two combined.)

-- Anonymous, November 24, 2000

I believe that a _great_ employee should work 70 hours a week, but only when he's on project. I also believe an employee should work an average of around 40 hours a week. Say for example:

bob works 40 hours a week for 6 months becasue he doesnèt want to work more hours.

bill works 70 hours a week for 2 months to get a project done and and when he is done he gets a long holiday.

as phil said bill is three times as productive, so he is done in 2 months. not only does the product ship four months earlier, but he could have a 4 month vacation and still be a better employee than bob. not to say that there is no place for bobs. there is a place for every programer that can be mustered. I would just prefer a few awsome employees to a hundred good ones.

-- Anonymous, February 21, 2001

"bob works 40 hours a week for 6 months becasue he doesnèt want to work more hours.

bill works 70 hours a week for 2 months to get a project done and and when he is done he gets a long holiday. "

Absolute bullshit.

It never happens like that. A more likely scenerio is:

Bob works 40 hour weeks, gets his sleep, has a life, comes into the office rested and awake. He writes solid code, keeps it documented, and doesn't make dumb ass time estimates that depend on being awake 72 hours straight before deadlines.

Bill works 70 hour weeks cause he's such an ubergeek. Stirs crystal meth into his coffee and hasn't seen daylight in months. His sight goes bad, he gets carpal tunnel and burns out by 30. But hey, he'll vest by then! In the meantime, he writes ever so pure and readable code (at 4am) and of course is bright eyed and bushy tailed all day at the cubicle farm.

The whole idea of being able to work 70 hours/week of anything as mentally intensive as programming for any reasonable ammount of time is an HR manager's wet dream.

-- Anonymous, February 25, 2001

Wow, this guy is so full of unsubstantiated knowledge and lacking in broad-based experience that it is amazing he has the gall to write an essay like that. I couldn't even read the thing -- it was so poorly structured and full of proof-by-assertion.

One item of particular interest, though, was at the beginning -- his fundamental premise. To paraphrase: The difference in productivity between the best and worst developers is 10 to 100 times. Further, an "average" developer might take all day to understand the code written by a "good" developer.

Here is a classic problem of defining your terms.

I would not base productivity measurements on raw LOC. I know the study he is referring to, but really he paints to broad a picture with a very meager brush. Also, if it took an "average" developer an entire day to understand what someone else took a day to write, that other developer did not properly encapsulate, test, and document their code. I certainly wouldn't label them "good".

I think we set the bar too low in identifying "good" programmers. Good programmers produce code, yes. They also produce easy to understand APIs, easy to read documentation, and thorough unit tests. Good programmers work in a team -- communicating and participating in discussions and decision-making. In a word, they go to meetings. Good programmers mentor "average" programmers, they don't sequester themselves in an insulated world of their own making and churn out copious amounts of crap that no one else in the world can maintain.

Software engineering IS NOT different from other engineering. The practitioners have just cultivated a wrong-headed mystique over the years that prevents the industry from maturing.

-- Anonymous, February 26, 2001