

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

======
dagw
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.

~~~
AmberShah
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.

~~~
dagw
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.

~~~
AmberShah
We might just be quibbling over good vs great, but the number of professional
programmers producing code out in the real world that can't write a simple
fizzbuzz method is astounding.

------
AlexC04
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
_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.

~~~
swombat
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.

~~~
AlexC04
Yeah. You're both right. That's a really crappy point to make. On reflection,
I'd self submit too. While I still dislike the article, it is not only fine,
it's probably required that one self-submit their work around.

Or set up a series of shill accounts to... oh nevermind. Self submitting is
probably better.

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

~~~
AmberShah
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.

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

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

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

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

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

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

~~~
grogers
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.

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

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

~~~
swombat
_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).

~~~
InclinedPlane
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.

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

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

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

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

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

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

~~~
InclinedPlane
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.

------
balding_n_tired
Not enough bold type and all caps.

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

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

