The proof is in the code. That is all.

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.

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.

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.

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.

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.

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 :)

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 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

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

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.

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.

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.

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.

Not enough bold type and all caps.

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)?"

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.

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