絕對不會有偉大的軟體會在平庸的程式員手下實現

招聘一個程式員，唯一對你有意義的是他能寫出好程式的能力。 很少人像這樣去招人，他們更喜歡去挑剔程式員的個人癖好和性格缺點。

我一說出這樣的話，人們大量的評論就會批評道：你錯了，錯了，完全的錯了。 好的程式員需要具備溝通交流的技能，他們要有跟他人一起合作的能力。團隊裡不止你一個人! 事實上，人們會說：最好折中一下對技術上的要求，這樣可以找出更能適應企業文化的人。

你不如這樣說更合適：找不到那種技術上又好、又能適應企業文化的人，我就等著，一直找到為止。

我們很少有敢這樣奢侈的公司，也許Google可以這樣，就是Google這樣的公司也一直處於一個“對招聘程式員感到絕望”的狀態中。如果你決定去等，我可以預見到每招到一個程式員你都要等待一個漫長的時期，同時業務會因為缺乏程式員而崩潰，火燒眉毛。

那麼，那種更好呢？

讓我們來考慮要那些中等或下等的程式員，他們和藹可親，而且努力工作。 他們的程式寫的不好–他們的程式根本不是按照他們想的那樣工作，即使他們做到了，那也是爛程式，很難去維護。他們在基本的功能上掙紮探索，根本解決不了複雜的問題。但是他們卻能跟上團隊，項目進度每天點都在更新，可以看見他們每天都在座位上奮鬥。一切都很好，你的經理會很高興，因為整個團隊看起來在平穩的向前推進。

當發布日期不得不往後延遲，產品Bug多的沒法使用，人們會哀歎說軟體本來就是很難做，於是投入更多的和藹可親的平庸的程式員去修複問題。 事情的結果我想大家都知道。

對於程式員，沒有太多的事情可以用和藹來解決。一個友善的平庸的程式員可以成為商務分析師，技術性的銷售人員，或著其它的能夠利用他的和藹和他的一點點的技術知識來工作的職位。這樣的工作他們會很滿意，但這都是在茶話會工作上的，可不是去找出有效辦法做出好的軟體。

另外一個選擇是，找個程式員，他能做出好的程式，但也許不善於和他人相處，或者老是遲到，或其他。他能開發出按照設計運轉的軟體，他能把複雜的問題抽象成一個簡單的問題。軟體好使，可維護，你隨時可以按要求修改。

這個世界很真實，有太多的方式都會讓我們把事情搞砸，但至少我們是有機會的。人可以給人留下不錯的印象。團隊可以建設的不錯。員工在長時間的為你工作，不錯。大量的業務沒有按照預定的設計工作，但還是成功了，不錯。但是絕對不會有偉大的軟體會在平庸的程式員手下實現。.

 

When hiring a programmer, the only thing that really matters is their ability to write good code. Finding people who can do this are so rare that it’s generally preferable to excuse any personality quirk or deficiency they have.
As soon as I say that, a huge number of people will comment that it’s wrong, wrong, WRONG.Good programmers need to have communication skills and be able to work with others.  There is no I in TEAM! In fact, they would argue that it’s better to compromise your skill requirements in order to find the right culture fit.
It would be nice if we could say: don’t hire until you find someone with both great technical skill AND great culture fit.  Except very few of us have that luxury, except maybe Google, and even they are in a constant state of desperate-to-hire-programmers.  If you decide to wait, expect to wait for a very long for each hire, even while your businesses crashes and burns in need of a programmer.

So, which is it?
Let’s consider the mediocre to poor programmer who is amiable and works hard. His code isn’t good – it doesn’t really do what it’s supposed to do and even when it does, it’s sloppy and hard to maintain.  He struggles with basic functionality and is not able to tackle complex problems at all.  But he does get along with the team and the project tracking tool is always up to date and he gives plenty of butt in seat time.  You’ll be alright for a while because your managers will be happy to see such a smooth-running team.
When releases are slipping and the product is too buggy to use, people will lament that software is just so hard and throw more mild-mannered mediocre programmers at the problem. And we all know how this story ends.
For programmers, there is no amount of nice that makes up for getting things done.  A friendly mediocre programmer can become a business analyst or a technical salesperson or some other thing where he can leverage his friendliness and his bit of technical knowledge.  Working with them may be pleasant but it is a tea party, not a smart way to build good software.
The other option is a programmer who delivers great code and maybe doesn’t get along so well with others or comes in late or whatever. He builds an application that does what it is supposed to do and abstracts complex problems into simpler ones.  The software works and is maintainable enough to change it when needed.
This is the real world and there are plenty of ways that things may still get all screwed up, but at least you have a chance.  Good presentation skills are nice.  Team building is nice.  Employees working long hours for you is nice.  Plenty of businesses don’t do these things and still succeed, but no one succeeds at building great software with crappy programmers.
The proof is in the code. That is all.