[david_shaw]

These are some great insights, and well worth the read.

I think that at a core level, many of us -- especially in the managerial world -- understand that working people to death, especially technical people, never works out well.

The adage of "work smarter, not harder" is absolutely correct. Just like it's better to write five lines of algorithmically beautiful code than a hundred lines of obfuscated spaghetti, it's also better to work reasonable hours in an atmosphere that is comfortable and enjoyable. Working less is often exponentially more productive. Will there be a crunch time, especially in the world of startups? Of course there will, and anyone who would promise otherwise is just plain wrong. That said, it shouldn't be crunch time all the time.

There needs to be a balance. Everyone needs to take their job seriously, and needs to get their work done in an acceptable amount of time... but stressing people out to the point of misery is counter-productive. My engineering team, for example, allows flexible work hours. I lead the team, and usually get into the office around 9:45am. I am rarely in the office before 9:30am, and I'm only in before 9 if I have an important call or meeting. I usually stay until six or six-thirty at night, because that's when I start to feel my productivity slipping. Some of my guys are early risers, and work 7am - 3pm. Some of them sleep later than me, but then go home and work until 3am. As long as their work is getting submitted on time, I don't mind at all: I want people to be comfortable, and not sit in a desk chair for the sake of keeping it warm.

Different companies work in different ways, but I agree with the points that Doug is putting forward in his post. The trend of "we work 18 hours a day to get anything done!" might sound super enthusiastic to a potential investor, but think about the message you're sending your potential talent. Founding a company is one thing, and it's going to require longer days than working on the codebase (unless that's what the founder does at your organization...), but there needs to be a balance. Hopefully, we'll get there soon.

[dclapp]

What you call crunch time is what I call poor project management. I started out as the managing editor of a daily newspaper. We shipped an entire product every day. We never slipped, we never missed a daily deadline… Just like every other daily newspaper. And there was never a OMG OMG crunch time as the daily deadline neared. If you manage a project correctly, when the deadline arrives you'll be sitting around telling jokes and admiring your work. I've done it many times. It can be done and it is not that difficult.

[katravax]

To be fair, making the average daily newspaper is a different kind of project than how most software is made. Print is mostly a fixed process with few creative unknowns. You know how long it takes for something to get through editorial or advertising, how long it takes to lay it out or drop in a replacement, what time the printer needs the layouts to be able to get the final papers to distribution, and what price and time are involved in special features or changes, like spot color or losing some number of copy inches at the last minute. But much of software is something new, the automation of some process or creation of efficiency. Software projects, almost by definition, have some of the players doing something they've never done before. Parts of the processes are similar, but software and daily print projects aren't really comparable for most of the cycle.

[dclapp]

I have been a manager in both businesses. of course there are differences; but there are also many similarities. the big idea is that if there is a firm, inflexible deadline, you will meet it. You may not ship the product that you really wish to ship, but you will ship. and, to be honest, feature X that has to be in the product, probably can just as easily go in the next release. Don't let the best be the enemy of the good. Be realistic about your capabilities.

[katravax]

Then yes, if you limit it to the subset of software projects that can cut features and still be considered to have met the deadline, then you can meet inflexible deadlines in software projects. You've defeated technical unknowns and external dependencies with the escape hatch of "Feature x, or whatever ship-worthy part of that you can have done by date y".

In that scenario, I think you're implying that meeting a deadline is the most important metric. I consider that far more likely in periodicals than software. For the common varieties like commercial software, contract development, and in-house development, the only one likely to permit that idea is the commercial product. Contracting and in-house projects will adjust the ship date or renegotiate requirements.

[taocoyote]

Totally agree and yet I still expect there will be periods of crunch time. I hope that employers will be tolerant of my shortcomings and so I tolerate theirs.

[dclapp]

I love your words "...five lines of algorithmically beautiful code..."; this beautiful functional minimalism is what engineering is really all about; and it solves problems not only in the present but also in the future. And code that isn't there runs really fast and never has any bugs...

[hasenj]

> code that isn't there runs really fast and never has any bugs...

love this quote! :D

[jslvk]

Do developers need to start being even more selective about working for these kinds of companies? Venture capitalists love software because the risk is astronomically low compared to other industries; is it more troubling that there are programmers that are willing to be underpaid, overworked, and screwed out of equity in the long run? Also, anytime someone has made an attempt to over-work me, I shut down and ignore them until I feel productive again (I'm a university student, so I think sometimes employers assume I am "really grateful to be getting paid anything," while ignoring my time preference and investment in education and work experience. I fear that trying to manage my employers expectations will simply be an excuse for them to hire someone else (assuming ability and credentials are the same).

[omgsean]

>Some of my guys are early risers, and work 7am - 3pm. Some of them sleep later than me, but then go home and work until 3am. As long as their work is getting submitted on time, I don't mind at all: I want people to be comfortable, and not sit in a desk chair for the sake of keeping it warm.

Not that I've ever managed anyone but I think this is the crux of good management for creative/technical teams.