The proof is in the code. That is all.

http://www.codeanthem.com/blog/2010/08/the-proof-is-in-the-code-that-is-all/

by AmberShah • 16 years ago

55 34 16 years ago

liuliu• 16 years ago

That's the merit of working in good companies such as Google or Facebook. You don't struggle for the drain of talent. Great programmers just fade in the scene and work on proud project. It is also the merit of starting a company with your tech friends because you don't have to worry about good hiring for a relatively long time.

thenbrent• 16 years ago

Something not mentioned here is that you also get an idea of someone's "cultural fit" by looking at their code. I think code can provide an insight into personality, especially into work related character traits.

natrius• 16 years ago

Have fun spending eight hours a day with abrasive people. Life is about more than productivity.

fookyong• 16 years ago

Good code is not really a hiring criteria. It's just the price of entry.

Hiring criteria for startup programmers:

1) can you work with others

...or are you the comic book expert from the Simpsons

2) can you ship

...can you be happy with a duct-tape solution, even if it's not perfect

3) do you care about customers

...everyone in a startup needs to be hyper-aware of customers and obsessed with getting more. the last thing a startup needs is a "tell me what needs to be built" programmer.

AmberShah4• 16 years ago

I don't disagree, but if that's truly all of your hiring critera, then you need to be willing to wait a long time and pay a lot of money. And that's personally the way I'd go.

What I find is that a lot of people say they want all that, and then when they can't find it, or can't find it for the amount of money they want to pay, coding requirements is one of the first thing that gets lowered, instead of the other areas.

awa• 16 years ago

The author forgets a point that if you hire a mediocre programmer who works hard he will probably get better but if you hire a programmer with a bad attitude that's going to harm the whole team's productivity

tallanvor• 16 years ago

Exactly. A mediocre programmer may have the ability to become a great programmer, especially if he or she has the people skills that allow him or her to learn quickly, and if your other programmers are willing/able to answer questions and mentor the person.

Nobody becomes a great programmer overnight. The key is to find the people who will grow into the position and then help others do the same.

grogers• 16 years ago

After having worked at the company I'm at for several years, I've seen quite a few mediocre programmers flounder at the same level for quite a while, none of them particularly improving.

I think the same things that keep someone from improving their skills are the same thing that make them a mediocre programmer in the first place. There is a difference between working hard at your job, and working hard to hone your craft.

generalk• 16 years ago

I've known fantastic coders who were absolute assholes. The software probably benefit from them being on the team, but the rest of us were ready to resign.

I'd rather have someone who fits the culture really well and who is a good enough coder that we can use them now and build on their strengths.

dbz• 16 years ago

I referred a client, and his project, to one of the best coders I've personally met.

His social skills are fine, but his patients are not. That's what I learned.

The proof is not in the code. The proof lies in the question:

"How happy is the client (post-project)?"

swombat3• 16 years ago

That works in a contractor/freelancer setting. I think the article is talking about hiring for your company that develops its own products.

InclinedPlane2• 16 years ago

Yeah, that question is a bit hard to answer, especially down to the granularity of an individual coder, when you're on a 3 year ship cycle and there are 2,000 other devs contributing to the project as well.

AlexC042• 16 years ago

Honestly, I kinda feel like this is one of those sweeping generalizations that gets cranked out by a content mill in order to attract attention & hits to their adsense.

Notice the Author (Amber) is the same as the submitter (Amber)?

This article is a total over-simplification and the reality is much more complex... unfortunately it takes a lot longer to write an actual, well thought out & balanced article on hiring.

What's worse: it will get fewer hits (and by that extension, a lower ad revenue).

Something perhaps about finding the sweet spot on the bell curve between a number of factors? TLDR.

No, a far better solution is to word-vomit tripe onto your keyboard and post without thinking.

Which seems to be exactly what Amber has done.

THAT my dear friends, is all.

palish• 16 years ago

Notice the Author (Amber) is the same as the submitter (Amber)?

That's kind of a cheap point to make. There's absolutely nothing wrong with an author submitting their own blog post to the site to get feedback.

swombat3• 16 years ago

Or even to get attention, if it's a relevant blog post. It's not like submitting your blog post is gaming the system or something. If anybody can understand the need for a basic level of self-promotion, it must be the HN crowd.

Jach• 16 years ago

You can't succeed with crappy software or programmers? Funny, I can think of a certain OS that wasn't at all very stellar compared to alternatives at the time yet nevertheless went on to dominate...

The whole article reads like a troll. Though perhaps we're using different definitions of 'mediocre programmer'. Is a mediocre programmer one who is mostly self taught, hasn't coded a lot of personal things, and only knows one or two languages at a reasonable depth to get things done? Or is it one who struggles with FizzBuzz? Bah, I'm taking too much time with this. If the proof is in the code, show us some examples of code from sizable open source projects that succeeded and code that didn't! I'd bet the quality is roughly the same.

swombat3• 16 years ago

You can't succeed with crappy software or programmers? Funny, I can think of a certain OS that wasn't at all very stellar compared to alternatives at the time yet nevertheless went on to dominate...

Which OS are you talking about? Windows? MS-DOS and Windows had some of the best programmers of the time working on them. Bill Gates himself is renowned for his programming skills. Microsoft interviews practically set the standard for uber-difficult interviews that filter out all but the best programmers.

Linux? What, because Linus Torvalds (who wrote the kernel) and Richard M Stallman (who wrote emacs) aren't good enough for you?

Mac OS X? Ok, that one, I don't know the names of any stellar programmers on there, but somehow I doubt that's the one you were referring to (and the fact that they keep quiet doesn't mean there aren't some awesome hackers working on OS X).

InclinedPlane2• 16 years ago

To put a finer point on it, pre OS X the Mac OS was an engineering disaster. It's fundamentals were more on par with Win 3.1, let alone Windows 9x or NT or Unix. Without OS X it's questionable whether Apple would have had the capability to keep up with the industry.

j_baker• 16 years ago

I really appreciate where code anthem is coming from, but the past few posts I've seen from them have been little more than meaningless platitudes much like this one.

dagw2• 16 years ago

Missing the obvious point that an asshole programmer can and will have a negative effect on the productivity of everybody else in the company and quite possibly make many of your other good programmers quit.

Missing the second obvious point that if you hire an asshole you end up having to (try to) manage an asshole. Assholes, almost per definition, don't take orders well and at the end of the day it doesn't matter how awesome a programmer he is if he isn't programming on what you need him to program on.

AmberShah4• 16 years ago

And everyone who's ever said that skill isn't everything, you need people skills is missing the much more important point that without good coders, you have 0% of building good software. The friendly, super-competent coder is the golden ticket, but barring that, the asshole programmer is your second best shot.

dagw2• 16 years ago

I disagree. A team of good but not great coders who work well together will probably produce better code in the long run than a team with a great asshole programmers who poisons the team.

dmoney• 16 years ago

There could be a business opportunity in interfacing between asshole genius programmers and normal people. I wouldn't want to be that person though.

tincholio• 16 years ago

The whole article seems based on a false dichotomy, namely that coders are either good and anti-social or sucky and nice to work with. In reality, both dimensions are orthogonal, and vary in a continuum. Hence, you'll find super-coder assholes, nice incompetent people, and everything in between. Furthermore, both dimensions have an impact on the working of a team, and that impact is also related to the complexity of the project in question.

tl;dr: the author oversimplified reality to come to her conclusion.

blacksmythe• 16 years ago

  >> In reality, both dimensions are orthogonal, and vary in a continuum. Hence, you'll find super-coder assholes, nice incompetent people, and everything in between.

That is definitely true, but you don't get a uniform statistical sample responding to job postings.

The super-coders who work well with people don't come on the market as often.

  >> the author oversimplified reality to come to her conclusion.

The author's conclusion is that you should ignore one axis (I don't agree).

ryanelkins• 16 years ago

I don't think the point was that you HAVE to choose between coding skills and social skills. The point was when the two come into conflict you should choose coding skills. They are making the point that coding skills are more important and should weigh more in the equation. The other option is to just keep looking but there is a cost associated with that as well. It's a generalization of a very complex HR calculus. At least that's how I took it.

balding_n_tired• 16 years ago

Not enough bold type and all caps.

j5eb6ach• 16 years ago

tl;dr: When hiring a programmer, choose substance over style

gfodor• 16 years ago

Nothing like a fresh blog article making sweeping generalizations with no facts, evidence, or even anecdotes in the morning.

That said it is interesting because I gather the people who voted up this article may very well be the folks mentioned therein who'd benefit from people taking his advice :)

aero142• 16 years ago

I look for code over personality but I have learned that there are intolerable people who you just can't hire. Some people are literally crazy. They come in flavors of "don't touch my code", screaming rage fits, and crying emotional breakdowns.

AmberShah4• 16 years ago

Oh, there are definitely crazies. Was not advocating hiring them whatsoever.

lmkg• 16 years ago

The purpose of anybody on your team is to raise the productivity of your team as a whole. That's really the beginning and end of it: does your team do more with this hire than without it? Individual contributions are part of answering that question, but they're not the whole picture. In one limit case, some recluse locks themself in a broom closet and programs a well-defined isolated chunk of code by themselves, and delivers it as a library. In this case there's nothing except their individual contribution. In the other case, you have managers which don't touch the code at all but greatly affect everyone else's productivity (for better or worse--and it is possible to have good managers!).

Outside of management, mentoring, morale, and architecting (which are important), someone's individual contribution is usually an upper-bound on their effect on team productivity. For some individuals, this is very far from a tight upper bound. Drama llamas, prima donas, and assholes create dysfunctional teams, and poor communication will in general increase the amount of work that needs to be done due to people working with incomplete information and needing to re-write things more often. Argumentative perfectionists will get caught up in arguing the design goals, and changing requirements will result in a lot of lost work for the whole team. Egotistical programmers are more prone to large re-writes of other people's code rather than small additions, which dumps a large portion of their contribution into changing style with little or no functional gain.

There are plenty of ways where someone with a large individual contribution may have a small, or negative, increase to your team's productivity. This doesn't mean you should hire the nice guy who can't code, though. Hiring decisions are possibly the most important decision you can make. Take your time to find the right person.

The proof is in the code. That is all.

Related Stories