Comment by plinkplonk | Hacker News Reader

Comment by plinkplonk | Hacker News Reader

The blogger explicitly quotes PG as saying

"In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?”

And then goes on to say he disagrees with PG and then provides some "indicators" that business guys can use to guide their search .

The thing is, a "business guy" is in no shape to judge any of these "indicators" accurately even if we grant that these are valid (which I don't).

. How would this hypothetical business guy recognize "passion for programming" (one of the "indicators" for recognizing programming excellence the author mentions)?

Let us see what he says

"Good programmers will have a tendency to talk your ear off about some technical detail of what they’re working on (but while clearly believing, sincerely, that what they’re talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they’re doing at the expense of social smoothness is a very strong indicator. Can you get this guy to excitedly chat up a technology that he’s using, for a whole half hour, without losing steam? Then you might be onto a winner."

Yeah right!!! This reminds me of some managers I know who'd make these kinds of judgments and reward the most technically inept members of the team because they "excitedly talk your ears off". Most of the talk would be technically incoherent but how would they know? all they detect is the "passion".

The rest of the "indicators" are similarly flawed.

PS the comments are hilarious too. I particularly liked "The above list is excellent (and it describes me perfectly). " :-D

None of those indicators were meant to be taken in isolation. Each of them, by itself, means nothing.

Taken altogether, they are helpful because they allow someone with little technical expertise to at least have a snowflake's chance in hell of recognising programing talent. If someone is enthusiastic, has a broad technical skill set, has been programming since before uni, loves to talk about the latest bit of technology he's picked up, is articulate, smart, learns technical stuff by himself, and has a tendency to work on side projects (rather than having all his experience on the CV), then they're far more likely to be a good programmer than not.

Remember, a business guy is effectively flying blind. I can sit with someone for 15 minutes and tell you whether they're a good hacker or not without having asked a single technical question, but someone with no technical skills cannot do that - nor can they figure out how to recognise someone like me to ask me to do it for them. They'll get fooled by certification-laden "software architects" who haven't written a line of code in years and will happily help them hire a football team's worth of mediocre programming talent.

I put together this list over a year ago to help non-technical people in this situation, and others must have found it useful, since over time it's accrued some 300'000 visitors and been linked to from pretty much everywhere.

If you feel you can come up with a better list of indicators, please do so, I'll be the first to vote you up.

"at least have a snowflake's chance in hell of recognising programing talent" is a good frame for the article. Unfortunately the article, as written, seems to promise much more.

"If you feel you can come up with a better list of indicators, please do so, I'll be the first to vote you up."

I think the counter point maybe that there may not be any valid "indicators" at all that a completely "programming blind" business guy can use. At least this is how I read PG's original essay. I agree with that viewpoint based on my experience.

Personally I found the essay (and the comments) amusing. It is just that I don't feel that this list of so called "indicators" have any practical utility, not because you didn't try your level best to come up with good indicators, but because the successful use of such indicators needs some programming experience (or trusted programmers for the business guy to delegate the decision to, who happen to be good at programming).

In other words I completely agree with your assessment that "Remember, a business guy is effectively flying blind. I can sit with someone for 15 minutes and tell you whether they're a good hacker or not without having asked a single technical question, but someone with no technical skills cannot do that - nor can they figure out how to recognise someone like me to ask me to do it for them. They'll get fooled by certification-laden "software architects" who haven't written a line of code in years and will happily help them hire a football team's worth of mediocre programming talent."

We disagree on what (if anything) can be done without a competent programmer in the loop somewhere, by a business guy with no programming experience using these(and possibly other) "indicators".

peace,

Unfortunately the article, as written, seems to promise much more

Well, I'll be sure to make the next version better. :-) This was posted 18 months ago (and it's the third time it makes the front page of HN).

We disagree on what (if anything) can be done without a competent programmer in the loop somewhere

I think these indicators can at least be used to whittle down the technical people that a business person knows down to a shortlist that is more likely to be good (rather than just have fancy titles). I'll grant you that the list can be improved, but I can't agree that the list is useless.

"I can't agree that the list is useless."

Fair Enough :-). As I said earlier, I think your intent (of finding these or potentially better indicators) is a noble one. I am not convinced of the efficiacy of such indicators in practice, when weilded by a business guy with no programming experience. But hey, I could be wrong and you could be right ! I'll be glad to change my viewpoint if I see this approach work in a consistent fashion!

How do you think "Has released something publicly." would be as another criterion?

That's kind of like the "hidden project" criteria, except public. Back when I wrote this article, I was only just starting to get to grips with the open source community (after using its products for a long time).

I think phrased as "has released things publicly", it's a bit too restrictive, because some people will be excellent programmers but just not have gotten into the whole open source community thing.

That said, from the point of view of helping narrow it down for someone who doesn't know programming much, then yes - if a programmer has released public libraries/applications that are in use, that's a great form of "extra-curricular" not-so-hidden project, so it could well be used as an additional indicator.

You are trying to measure how hot a fire is by how much smoke it's producing. While on average smoke and fire are related it's not a great indicator. A simple solution would be to get 10 programmers into the same room and talk about a technical problem and ask them to privatly evalutate eachother afterward. But, that's not "fast" and "cheep" so most people go for guessing games.

Real life is all about trade-offs. "Slow" and "expensive" is not an option if you want ot be competitive, and others can do it fast and cheap. If all you have to go on is smoke, then learn to recognise different kinds of smoke is pretty handy.

In hindsight, more than a year after writing this article, I would say that this list might be most useful for the business guy to recognise someone who will help him hire good programmers, rather than as a direct hiring tool.

My worst hire was a java guy that I took a gamble on because we were short staff and could have used some help with mobile stuff. He was fired within two weeks, so I totally understand where this guy is coming from. I've also done interviews where I've asked candidates why they became interested in programming and they replied, "I don't really like computers, I just do this for the money." One guy actually said exactly that.

When 95% of the people you see coming through the door are like this I could see a non-programmer not being in a position to figure out that these people simply aren't worth hiring.... the solution I don't see addressed is more rapid and iterative trial and error in the development hiring process: bringing people on in a limited capacity or throwing them at smaller and contained technical projects before giving them responsibility for more important stuff. I'm a big fan of finding good people for part-time work and then growing them into full time positions if the business model starts supporting it and they want more work. This has worked well for non-programming stuff too.

I don't 'just do this for money' but an employer that explicitly requires passion and 'not doing it for money' looks like trying to get off paying less and have me working for 'the big idea'.

The list is interesting and mostly true (IMHO). There is just one point where I differ with you:

"Formal Qualifications This is more a of non-indicator than a counter-indicator. The key point to outline here is that formal qualifications don’t mean squat when you’re trying to recognise a good programmer."

Qualifications is an effective way to limit at least some of the people. Most 4 year university degrees require at least a basic level of intelligence and commitment. It is true that there are a lot of professional Comp. Science bullshitters out there with degrees (I know quite a few) but on the average you will be luckier with a university guy. This does not just mean that you should look for Computer Science – applied mathematicians are also a good bet (based on other qualifications). (Of course there are also excellent programmers without degrees – but it is extremely difficult to find).

Another thing – something as simple as a typing test may help you. There are people out there that claim to be programmers (esp. freshly out of college) but do not really program (further than the task at hand). People who programs a lot for a long time will generally type faster than people who do not really program.

Also I think that to hire someone is fairly expensive (at least $50,000 a year in the states). If you make a bad decision it is a lot of money down the drain and one bad guy can ruin the atmosphere of a whole company. Why not hire a programmer (that you know to be competent) to help you with the interview? I am sure that a $1000 expense is less than the risk of wasting $50,000.

Wow - the typing thing seems to be popping up here a bit lately.

You'd seriously give a someway qualified programmer a typing test?

I don't think qualifications are a great hurdle requirement, but they are one of the indicators that are useful. Pretty much the best indication of how someone will do is past performance - and a degree contributes to that.

As for trade qualifications - e.g. Certified CompanyXYZ Professional. I've often found them to be neutral or counter-indicators -- quite often they are (1) even though you know this stuff inside out to do this work we mandate this qualification or (2) I heard XYZ professionals get paid a lot so I'll buy a "get your XYZ professional cert in 15 days" book and qualify.

In my experience anyway -- I've not done a massive amount of hiring really, but the # of positions would be in the 30's or 40's.

Both of these suggestions seem bogus.

I suspect people with a degree in computer science or applied mathematics tend to be on average better programmers than people who claim to be programmers who don't have those degrees. But the bar set by simply having a degree is so incredibly far from the level that you'd want out of your technical lead that it's not much of a useful metric.

Typing seems even odder. Doubly so where I live as they don't teach folks in school here to touch-type. These days I'd suspect that typing speed is probably more correlated to the speed with which one sends IMs than how fast they code.

Really, if your hiring requirements are "a guy with a degree that types quickly" you're going to find yourself pretty quickly up shit creek.

> average better programmers than people who claim to be programmers who don't have those degrees.

I doubt that. Further more a person with a degree has on the average a higher intelligence than a person without. Also, most degrees have language requirements and subjects that at least ensures that the person has a basic grasp of grammar and spelling.

> Typing seems even odder. Doubly so where I live as they don't teach folks in school here to touch-type.

You should at least check if a person can type. There are a lot of so called "programmers" that can not even type properly.

> Really, if your hiring requirements are "a guy with a degree that types quickly" you're going to find yourself pretty quickly up shit creek.

You constructed a straw man – no where did I suggest you should only use these metrics – my suggestion was that it made sense to hire/contract a programmer to help you make the hiring decision.

Reply on news.ycombinator.com