Don't Be A Hero | Hacker News Reader

Don't Be A Hero

al3x.net

68 pointsicey20 comments

I agree with Alex here, but the reality is that companies LOVE heroes. I see it happen over, and over again (and usually with the same people). The manager asks the hero how long something will take, he underestimates the task, failing to account for testing, other inevitable issues, other priorites, etc. Manager loves the answer.

There will be inevitable issues, and things come up in limited testing, but the hero will work stupid hours on little sleep producing crap quality, just to get SOMETHING going, even though it's a strict subset of what was promised. Since SOMETHING is going, and the hero casually notes that it took them heroic effort... he gets a "spot award" or some other trinket.

Manager got the answer they wanted, the customer got SOMETHING, and the hero got his trinket. Everyone wins.

And it will cause headaches and issues untold for many months down the road.

Meanwhile, the non-hero estimates conservatively, management hates the answer, the customer gets a well (or at least less fragile) something later and hates that, and our non-hero gets the stink-eye.

A manager told me long ago that customers don't want it right; the want it broken and quickly. That way they have something to bitch about. From a producer's standpoint, they can then bring out the hero to fix what should never have made it out to begin with, sometimes charge for it, and look like they're "responsive". And the customer can feel all smug that they made the vendor/producer do their little dance.

Well, that sure seems to be a manager's point of view, rather popular. But is it always correct?

interesting, although for it to work out, you have to assume that in every case, the hero is merely acting as a crutch. and for that, you must assume that there will never be emergencies.

so there doesn't seem to be much but a generalization. maybe it's true, but i'd agree and say that this sounds more like a manager's point of view (or rationalizations of an employee who doesn't want to look bad relative to a hero, although i'm not making that assumption).

In my limited experience customers bitch a pretty much constant amount unrelated to the quality of the product at that time. They want to get their "money's worth" out of you. So it's better to create a buggy program and let them bitch about that.

I'm not sure what you mean; is it "correct" in that what I described happens? Yes, it is. Not every time of course, but I've seen it happen quite a lot; probably more often than not.

If you mean, is it "correct" in that "Is this the way things should happen?" Then I would submit, no.

But, reality always wins.

My experience is that Heroes are problems because they're a) bottlenecks b) single points of failure. Using them as a crutch exacerbates both problems. However, having the most productive person on the team do as much as they can do is an easy trap to fall into. When one person is working on a totally different level from everyone else, it's probably in their interest to leave and find a different group that they're more peer-ish with. However, Heroes tend to become Heroes by being the self-sacrificing type, so they're not as likely to do so.

This also reminds me of Comparative Advantage[1] from basic economic theory. If you have to people X and Y and two tasks A and B, and X is better than Y and both A and B, should X do A and B for himself? Turns out no. X should only do the task they're more better at, and trade Y for the other; more gets produced, and there's a ratio of exchange such that X and Y both end up with more A and B than they would have otherwise (see [1] for rigorous definitions and simple maths). It's the same situation, you should be taking work away from the Hero so they can focus on what they're awesome at, rather than giving them more work.

[1] http://en.wikipedia.org/wiki/Comparative_advantage

Cool, I think I edited an early version of that page and added some tables with numbers and a small discription. It looks much improved from how I left it.

Yeah. Even with all the bureaucracy that we like to fret about --- Wikipedia still works for most pages.

I agree with a hero being "dangerous" but I would say you should be looking at the manager as the problem, not the employee. If one employee is doing all the work it is because the manager or his manager is letting it happen.

You usually need a "hero" to get an idea off the ground. At some point during discussions about a new project the time comes to buckle down and actually get some shit done. I've found it's often necessary for a small burst of Herculean effort in the beginning by one, maybe two, people.

Then, after the initial burst, you can start forking things off and spreading the knowledge around. The trick is finding these hero/wizards who care enough to perform the burst but have small enough egos to share the reigns later with others.

Those people who didn't want to do it in the first place are not going to be exactly jumping out of there seats to pitch in and firm whatever was created up and finish it out. Wish that were the case but I believe people want to see the hero fail. Eventually the hero gets tired of never ending uphill climb and leaves.

"... If you’re playing the hero, or if you have a hero on your team, it’s probably time for a serious talk with your coworkers and manager. ..."

Manager?

"... You shouldn’t be getting paged at all hours. Sure, you might need to do some occasional planned after-hours maintenance, or some very occasional unplanned-but-process-driven disaster recovery, but you shouldn’t need a hero. ..."

When you hear this you know your working in an established business or corporate land. I know this is what you should aim for, but I've yet to work or see a Startup that works so well it doesn't require this kind of intervention.

It should only require that kind of intervention once (per type of incident), and if it's a regular thing then it points to a more fundamental problem.

"... It should only require that kind of intervention once (per type of incident)... points to a more fundamental problem. ..."

That's a better way to phrase it. I'd agree with that.

Yes, it seems like some companies have a culture of emergency and heroism in a self-reinforcing loop.

It is terrifying to watch an imagined emergency be solved in such a way as to cause a proper emergency.

From another perspective, I left my last company because I felt the tension to become the hero.

What's interesting is that there was another person who was also kind of playing the hero role - but didn't quite have the development talent to make the big contributions. Man, it destroyed the team culture between the boss and the devs. It wasn't just that he "enabled mediocrity". He was seen as "being mature" and "really cared". And the other devs saw his flaws rather than his benefits. The devs began to roll their eyes when the boss talked about "caring". Once this happens, it's an awfully hard ship to turn around.

Given identical situations, average management will always take the cheapest/shortest option. regardless of quality.

The quick fix in the middle of the night just takes attention form a serious issue and delays it's repair till it later again becomes serious enough to need managements attention.

A real hero will be professional enough to stop the presses, call attention to the problem and assure it gets fixed once for all.

Using the "Technical Debt" analogy, a heroic solution is no more than borrowing money from a loan shark at horrendous interest to pay todays due mortgage.

Another negative aspect of a team relying on The Hero is the "knowledge black-hole" effect. The Hero writes a lot of code, often poorly documented, and builds these fragile cathedrals in his mind. Then suddenly he leaves the company/gets sick/etc. and the undocumented, full of scary TODO/FIXME codebase stays behind. The rest of the team is afraid of touching it and the cathedral eventually crashes.

Agree with Alex that heroism needs to be valued in the right way. When looking for a programming job, figuring out whether the manager values heroism in the right way is a great way of figuring whether they understand and value quality people and quality work. Many managers can't tell a good programmer from a bad one.

I think Alex just described someone who should start their own startup.

Founder: A motivated workhorse, eager to please the manager; of course, the manager being the customer.

Reply on news.ycombinator.com