Managing Software Engineers(philip.greenspun.com)
philip.greenspun.com
Managing Software Engineers
http://philip.greenspun.com/ancient-history/managing-software-engineers
Yes, it's from 2002, but still surprisingly pertinent.
8 comments
I just can't understand the attitude that good programmers should be expected to voluntarily always spend 10+ hours a day, just because they love the work.
I genuinely enjoy my programming job, and it provides me interesting challenges. I think I am at least an average programmer, depending on where you're putting the "average" bar. But I enjoy many other things, too. I want time to read, play chess, go out places, study other fields, and spend time with friends -- and I don't even have a family and kids, like many professionals!
Given that I'm programming a minimum of 8 hours a day, why would it be a red flag that I usually prefer to spend the other 8 doing something else? I'm already spending as much time programming as all the other things I also love, combined!
I genuinely enjoy my programming job, and it provides me interesting challenges. I think I am at least an average programmer, depending on where you're putting the "average" bar. But I enjoy many other things, too. I want time to read, play chess, go out places, study other fields, and spend time with friends -- and I don't even have a family and kids, like many professionals!
Given that I'm programming a minimum of 8 hours a day, why would it be a red flag that I usually prefer to spend the other 8 doing something else? I'm already spending as much time programming as all the other things I also love, combined!
I just can't understand the attitude that good programmers should be expected to voluntarily always spend 10+ hours a day, just because they love the work.
It's easy. The author of that piece, at the time he wrote it, was making a shit-tonne of money hiring out programmers to large corporations on an hourly basis. He had a huge vested interest in persuading his employees that this is how they ought to be. Did/does he really believe it himself? That's another question. We only have the material that he chooses to make public to go on.
It's easy. The author of that piece, at the time he wrote it, was making a shit-tonne of money hiring out programmers to large corporations on an hourly basis. He had a huge vested interest in persuading his employees that this is how they ought to be. Did/does he really believe it himself? That's another question. We only have the material that he chooses to make public to go on.
I agree... what he's describing is a sweatshop, and honestly I've never seen code from someone who was working 70+ hour weeks actually work. Every time I've worked with someone like that, I've had to waste a lot of MY time fixing it, making me extremely unproductive... but I was still able to get my work done, because I did it right -- I avoided unnecessary complexity.
And did anyone else notice that he equated "productive" with "works long hours?"
And did anyone else notice that he equated "productive" with "works long hours?"
I'm not sure I agree with programmers working long hours making good business sense. Maybe if developers could work long hours without making stupid mistakes that would be true. But software developers are human and need to limit themselves. It is possible to do negative work (ie screw stuff up that has to be fixed later) after all.
The kind of work Ars Digita were doing wasn't algorithmically complex tho' - one template-driven corporate website is much like another. They certainly weren't debugging race conditions or anything mentally exhausting like that. You can just grind this stuff out 12 hours a day if you have to/are being paid enough.
I've done the grind work - used to work in an auto parts plant actually. 12 hour days are exhausting, and your output decreases dramatically after you go past the 8 hour mark. Repeatedly doing this over multiple days results in dramatically reduced productivity.
Read up on the studies yourself - the 40 hour work week was established based on output studies of factory workers - people who, like you say, aren't doing anything complex. They still suffer from performance penalties just like everyone else, and they also eventually go into negative output mode, just like programmers.
Having done the grind work while strapped for cash, I can tell you that the allure of money and the desperation of making rent will only make you productive for so long. Everyone has different limits, but at the end of the day someone who is overworked will likely give up large sums of money just to work less.
As an employer, why can't you give your guys normal 8 hour days? It's more economical for everyone - you are getting sustainable, high output, as opposed to the illusion of working hard, while getting very little out of your employees in reality.
Read up on the studies yourself - the 40 hour work week was established based on output studies of factory workers - people who, like you say, aren't doing anything complex. They still suffer from performance penalties just like everyone else, and they also eventually go into negative output mode, just like programmers.
Having done the grind work while strapped for cash, I can tell you that the allure of money and the desperation of making rent will only make you productive for so long. Everyone has different limits, but at the end of the day someone who is overworked will likely give up large sums of money just to work less.
As an employer, why can't you give your guys normal 8 hour days? It's more economical for everyone - you are getting sustainable, high output, as opposed to the illusion of working hard, while getting very little out of your employees in reality.
You have misunderstood the consulting business model. The metric is billable hours. Been there, done that.
That's a pretty good argument for not paying by the hour and/or not using consultants.
You're not wrong.
Of course, I would argue that it would come back to bite you in the end. You want clients to send you more billable hours in the future. And that can't happen if you screw stuff up. :-)
But then again, I don't run a successful consulting firm.
But then again, I don't run a successful consulting firm.
You say that, but research the history of EDS and Accenture... Repeated fuckups haven't cost them any business with the UK govt.
[deleted]
In general, you'll hire people who,
* are smart/productive enough to automate the drudgery,
* are smart enough to get by, but whom the drudgery provides some lasting challenge, or
* are screwing around and will likely screw around more as you keep them on for more hours.
So, even assuming that simple work will allow you to get a significant long-term productivity boost working people 8 hours instead of 12, in the long run, you're going to be working with a set of people who'll likely be challenged by the work, so fatigue will cause problems if they're challenged at 8 hours/day, or you could be getting smarter work out of them if they challenged at 12 hours/day.
Of course, building the tools to automate drudgery does take some time, and considering Ars Digita apparently operated during the first .com boom, time-to-market was critical, so some of this logic doesn't apply to the original example.
So, even assuming that simple work will allow you to get a significant long-term productivity boost working people 8 hours instead of 12, in the long run, you're going to be working with a set of people who'll likely be challenged by the work, so fatigue will cause problems if they're challenged at 8 hours/day, or you could be getting smarter work out of them if they challenged at 12 hours/day.
Of course, building the tools to automate drudgery does take some time, and considering Ars Digita apparently operated during the first .com boom, time-to-market was critical, so some of this logic doesn't apply to the original example.
Successful companies such as Oracle Corporation burden their marketing departments with overlapping products rather than stifle programmer initiative. For example, during most of the late 1990s there were at least three different Web servers that you could buy from Oracle, each one backed up by a document explaining why it was the one true path toward database-backed Web site glory.
Otherwise a good article, but what does this mean? That because Marketing often makes life difficult for developers, you should instead make life difficult for Marketing?
The average home cannot have a grand piano but almost any office can.
This as well. The article seems to be making good point after good point, then throws out curveballs like this.
Otherwise a good article, but what does this mean? That because Marketing often makes life difficult for developers, you should instead make life difficult for Marketing?
The average home cannot have a grand piano but almost any office can.
This as well. The article seems to be making good point after good point, then throws out curveballs like this.
Re: grand piano, I'd guess this is hard to understand for someone who doesn't play piano. It might be that of 200 engineers, there's a high chance that about a dozen of them will love playing on a grand piano enough to make it worthwhile for them to come in on weekends every once in awhile, just to be able to "get away" and play a bit.
Re: marketing, I'd imagine a lot of the time, marketing happiness verus engineer happiness is a tradeoff. Either you stick to very concrete business deadlines imposed by perceived market, making lots of engineering sacrifices along the way, or you build things at the pace set by engineering. You can certainly over-do it in either direction, but there's also a lot of workable gray area.
Re: marketing, I'd imagine a lot of the time, marketing happiness verus engineer happiness is a tradeoff. Either you stick to very concrete business deadlines imposed by perceived market, making lots of engineering sacrifices along the way, or you build things at the pace set by engineering. You can certainly over-do it in either direction, but there's also a lot of workable gray area.
My office has a gorgeous view of the city (and I'm a hobbyist photographer) - but I've yet to come in on a weekend with my camera to take any pictures.
Most people desire a separation between work and play, and I think one ought to respect that. It's unreasonable to expect your employees to embody their job at all hours of the day - including weekends! At some point they will leave the office, and chasing them and trying to reel them back in with perks or goodies is just going to generate antagonism. You expect happy engineers yet you clearly have no respect for their personal time, how does that work out?
Most people desire a separation between work and play, and I think one ought to respect that. It's unreasonable to expect your employees to embody their job at all hours of the day - including weekends! At some point they will leave the office, and chasing them and trying to reel them back in with perks or goodies is just going to generate antagonism. You expect happy engineers yet you clearly have no respect for their personal time, how does that work out?
The camera is a poor analogy because it invites you to explore many different places. A better analogy might be a theater room with cushy chairs, big screen, and great sound. That would make you want to go to the office to use it. Your camera does the opposite.
I have lived in places where pianos were present, and my quality of live went up considerably when someone who knew what they were doing took a moment to play during the day.
Even a little bit provides a huge lift to the spirits.
Even a little bit provides a huge lift to the spirits.
I'm of the firm opinion 'software' should never appear in the same sentence as 'manage' or 'engineer'.
Any good survival books on 'Hacking your Manager' for those passing temporarily through the corporate underworld towards their first startup?
Any good survival books on 'Hacking your Manager' for those passing temporarily through the corporate underworld towards their first startup?
As I was reading I though I could just replace software engineer with knowledge worker and it would stay valid. Then I remembered Peter Drucker wrote an article for Forbes in 98 called "Management's New Paradigms" basically covering the same thing. Software engineers are knowledge workers much like marketing specialists and must be managed as such.
http://www.forbes.com/forbes/1998/1005/6207152a.html
http://www.forbes.com/forbes/1998/1005/6207152a.html
I believe you either lead or administer software engineers. Not manage them.
Yes, it's from 2002, but still surprisingly pertinent, in my opinion.