The proof is in the code. That is all.(codeanthem.com)
codeanthem.com
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/
17 comments
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.
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.
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.
There could be a business opportunity in interfacing between asshole genius programmers and normal people. I wouldn't want to be that person though.
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.
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.
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.
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.
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.
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.
Or set up a series of shill accounts to... oh nevermind. Self submitting is probably better.
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.
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 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.
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.
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.
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.
tl;dr: the author oversimplified reality to come to her conclusion.
>> 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.
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.
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.
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 :)
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.
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
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
Oh, there are definitely crazies. Was not advocating hiring them whatsoever.
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)?"
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)?"
That works in a contractor/freelancer setting. I think the article is talking about hiring for your company that develops its own products.
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.
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
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.