Comment by zavulon | Hacker News Reader

Comment by zavulon | Hacker News Reader

I believe this is a response to some comments to their previous post http://37signals.com/svn/posts/3162-the-on-call-programmer?

I think they're completely missing the point of those comments, but regardless of that, I think there's a bigger point to be made here.

Over the years, I've noticed there are two types of developers: the ones who only want to work on interesting code/new projects/etc, and the ones who get shit done.

The first guy does NOT want to do any maintenance, only wants to work on new projects so he can get things "his own way", throws a hissy fit or refuses to do it outright when he has to dig through tons of horrible legacy code, etc.

And the second guy just gets shit done. No matter what it is, he understands that it just NEEDS to be done, and does it. He will not take it silently - sometimes, just like the first guy, he will be loud and obnoxious in voicing his opinion that this code totally sucks, what moron wrote this, and we should totally rewrite it, etc.. but then he sits down, rolls up his sleeves and does it (and then works on re-writing it in the right way, if there's time).

The first guy might be a much better programmer than the second. He will pass a technical interview with flying colors, he's usually up to date on all the latest technology, he's good and he knows it.

But after a few years of doing this, I will hire the second guy EVERY TIME.

I think that's possibly too simplistic. If the reason there's so much shit that needs doing is because the second guy didn't do it right first time then hiring the second guy might have been a mistake.

Maybe the first guy is just pissed that he has to put up with so much shit written by the second guy and is vocalising his desire to be free from it.

I prefer to think in terms of 'mean change turnaround' time; how quickly can your organisation or individual go from a problem or change request to functioning production system? If nothing ever breaks but new reports take 6 months, that's probably worse for business than the occasional outage and new reports taking 2 weeks.

You seem to think it's an intrinsic quality in a person that never changes. How long until the guy #2 turns into guy #1? I'm guessing it's not long after he notices it isn't rewarded by management, and/or isn't worth it relative to being guy #1. Just one of many ways bad management turns gold into crap, if not loses employees of type #1.

This is all well and good, but unfortunately #2 type of work is much less rewarding. Unless the #2 programmer has immense fortitude, he will burn out more quickly and either become much less productive or switch to #1 type of work. You might be able to get some of the benefits of each by mixing up the two types of work.

Thanks for pointing this out - of course I didn't mean that #2 guy will do the shit work exclusively. If that was the case, all the good people would leave - everybody has their breaking point.

It's a manager's responsibility to balance this out - but my point was SOMETIMES there's shit work - it's just unavoidable, and someone has to do it. And at that stage, there are people who do it, and people who don't ...

Just curious: How would you differentiate between the first type and the second type of programmer when you hire him/her?

Good question. That's what I'm struggling with right now. There really is no way to determine this accurately at interview stage - a smart person will always figure what kind of answer you're looking for. One way is to have them describe in detail what they're doing at their current/previous positions - if they mention legacy code/doing support or maintenance, ask for more details. See how they're describing it - matter-of-factly, or in a negative way.

However, there really is no good way to do this, other than to hire somebody for a trial period and have them do actual real world tasks. That's what I try to do most of the time, but unfortunately it's not always possible. If someone has better ideas, I would love to hear them.

If you interview a guy/girl very good technically buy seems to work on shitty, boring and otherwise inane projects more often than not, you might still have found it. For a lot of corporations that's where you send the programmers that eat it up and just do their job...

Personally, I've found a sense of humour to be a reasonable indication - person 2 is more likely to be able to step back, smile, and say "okay, this is horrible and it's going to go badly for these reasons. But if I had to do it, I'd X the Y with Z". If they can do that and laugh about it, I get a sense of levity and perspective.

I look for signs of overcoming general hardships in life. Sometimes those signs show up in a resume, sometimes I have to talk to someone for a couple of hours to find them.

It is usually possible to do for any type of position [not only developers] if you make a deep-dive interview, asking a lot of open questions (how? why? etc) to understand the operating motto of a person. Drawback - it may take up to 1.5-2.5 hours of one-on-one conversation.

I have never failed to separate doers from other types.

The only issue I had is that sometimes, after interviwing 20-30 people, I could not find a 100% doer, and therefore I had to make a comromise.

Reply on news.ycombinator.com