在delicious上看到一篇去年的文章： How to recognise a good programmer。 正好这段时间一直在为面试发愁，看看这篇文章很有帮助。原文篇幅很长，这里就不逐字逐句地翻译了， 只把要点和看过之后的体会写出来，希望能给同样是为寻找程序员而头疼的同仁们提供帮助。
优秀程序的几个必要条件：
1. 要有热情
企业中有这样一种人：职业程序员。他们之所以做IT是因为IT是个好工作，而不是因为对技术充满热情。这些人回家后绝对不会写程序。 对于他们来说，编程是每天必须的工作，公司为他们提供技术培训也是理所应当的。 这种人缺乏热情，也不会是好的程序员。
其实这类人相当相当多，随手一抓就能抓出一大把。他们自己也有电脑，但那是用来上网看电影打游戏的，不是用来搞开发的。 开发环境、编辑器甚至连Office都没有。这样的人也很难期待他是优秀程序员。
2. 会自学，爱自学
大家都知道IT行业更新很快，不会主动学习的人很快就会被淘汰。有些人你要他们学习某项技术时他会说“公司给我培训我就学”。 当然，在找工作时他们有可能在家里学习必要的技术，但那不是主动的自学。好的程序员热爱学习新技术， 对于他们来说学技术纯粹是好玩，纯粹是个人兴趣。有些人还会制定出完善的学习计划。 这样的程序员根本不用培训。
3. 聪明
也许程序员都给人以不善交际的印象，但其实他们不是。好的程序员都是智商奇高的人， 不可能不善交际。而事实上的确在某些场合他们不善言辞，那是因为他们的兴趣不在那里。 一旦讨论到他们感兴趣的技术话题，他们就会扯开话匣子说个不停。
在招聘时可以试着去谈论一些他可能感兴趣的技术话题，看他能侃到什么程度。 如果问一句说一句或者说不出来什么，那就不用再抱希望了。
4. 隐藏的经验
优秀程序员或多或少都有些“课外活动”，如参加开源社区，为处理日常生活的事情而写的小程序， 个人网站，或者纯粹为了好玩而做的小东西。而面试时这些东西是不会写在简历上的， 因为他们觉得这些根本算不上简历要求的“经验”。
我经常看到有些应聘者的简历上把大学时做的小学期作业都写在上面。这种人就不必考虑了—— 连作业都自认为是“经验”的人可以想到他的水平有多高。
所以，优秀程序员的简历通常都很简短，不过你可以去问问他们，除了简历上写的东西之外， 工作之外有无技术经验，即使完全和工作无关也行。如果他答不出，那即使简历有20页长，他也不会是优秀程序员。
5. 广博的技术知识
这一点很简单，学得技术越多水平越高。不一定要完全精通，但了解许多毫不相关的知识对个人水平有很大帮助。 但同样，优秀程序员不会把他知道的东西全都写上，那些他不精通的东西会认为不值得一写。
不过有一点要注意。如果简历上写到“精通Java、J2EE、Ant、XML、SQL、Hibernate、Spring、Struts、EJB”， 就要小心了，这个人不一定优秀。因为这些技术都属同一个领域，关联性太强。 但当你对这些技术一无所知时，如何分辨呢？你可以让他讲讲这些技术有什么联系。 精通一个领域的技术的人经验丰富，但他很可能不是个优秀程序员。
为什么需要有广博的技术知识？我个人认为，即使是毫不相关的技术，其实也是能融会贯通的。 学得技术多了、杂了，看到不懂的问题自然而然地就能想出最合适的解决办法来。
不过有一点要注意，如果他关心的技术中有尖端技术，如今天的AIR、Flex之类， 那你就可以考虑录用他。
另外优秀的程序员对技术很敏感，他能判断出某项技术是否适合于完成工作。 如果被迫使用一种他认为不适合的技术去工作，他会觉得很不爽的。
6. 资格证书
资格证书、学位等不是优秀程序员的必要条件，但至少不是个反面信号。优秀程序员大都有计算机科学的学位。 也有很多人没有，但这并不能说明他不优秀。专业资格认证如MCSE、CCNA等也是， 这些只是用来证明这个人已经学会了相关知识，企业在招聘的时候就可以省去考核的麻烦， 并不能证明程序员有多么优秀。如果你的企业确确实实需要非常优秀的程序员， 那就别去理会这些认证，而是把精力花在实际能力的考察上吧。
总结
如果将优秀程序员的条件按条列出的话，可以得到如下内容：
正面信号
- 对技术有热情
- 以编程为乐
- 对感兴趣的技术话题会滔滔不绝
- 工作之外自己做过某些项目
- 主动自学技术，但不是为工作而学习
- 对技术的好坏、是否合适有自己的看法
- 使用自认为不合适的技术完成工作时会很不爽
- 聪明，很多话题都能侃侃而谈
- 在上大学或工作之前就写过程序
- 有许多简历上没写出来的经验
- 知道许多毫不相关的技术（一般不会写在简历上）
负面信号
- 把编程当作每天的工作
- 不喜欢谈论技术，即使受到鼓励也不会说
- 只通过公司的培训来学新技术
- 愿意使用你选择的任何技术来完成工作，认为“所有技术都是好的”
- 看起来不怎么聪明
- 在大学时才开始学编程
- 简历上写出自己的所有经验
- 仅专注于一个或两个领域
相信这张图大家一定见过，它描述了在软件开发各个阶段，发现并修改bug所需的相对费用。 例如，一个本应在设计阶段发现的bug，如果一直到部署并开展应用之后才被发现， 那么修改这个bug所花费的代价是设计时修改的代价的470倍-880倍。
设计阶段是在选定方向，而编程则是朝着目标前进，测试就是检查有没有达到目的地。 如果最初选择了错误的方向，那么无论如何努力前进也无法到达目的地， 事后走回头路会花费更多的时间。最近在开发中几次验证了这个事实。 一次是在详细设计审查时发现了设计中的一个重大方向性错误， 如果没发现并继续编程，测试阶段再去改代码就会使得代码、测试用例等完全重做， 浪费大量时间。另外一个例子就是以前开发的一个项目， 当时没有做详细设计而直接开始编程，就等于放弃了修改bug效率最高的设计阶段， 增大了项目风险。
因此在软件开发中，最重要的阶段不是测试，而是设计（概要设计和详细设计）。 做好设计文档并严格审查，就能大幅度地减少开发风险，降低开发费用。
我曾经做过一个失败的项目。那时我对项目管理一知半解， 对于风险管理、进度管理等更是一无所知， 以致最后花费了当初几倍的人力来挽救它造成的损失。
项目概况
这个项目的策划是在11月开始的，是对现有的一个Web应用程序进行改造。 客户写了一份简单的需求说明，希望能在12/25圣诞节之前投入使用。 根据这份需求说明，我们整理出了一份功能列表， 然后估算每个功能的代码规模，发现规模大大超出期限，于是跟客户交涉， 删减了一些功能，并将发布日期定为1/26。 最后结果为服务器端3KL，客户端3KL，按照1KL/人月的保守估计， 需要6个人月，投入两个人，正好能在1月底完工。 于是项目就开始了。
阅读全文 »今天在《水煮三国》P65上看到了这张图：
这张图的意思是说，激励员工不一定要使用金钱， 而只需要依次满足他们各个阶段的需求。 而在中小型软件企业中如何使用者张图呢？ 按时发工资基本上都能保证，饮料这种小恩小惠或许员工们并不稀罕， 而与领导见面的机会也是家常便饭一样， 那么员工真正的需求，就是得到赏识和获得特别授权去完成一项艰巨任务了， 而这两者正是分权的体现。
上面这张图让我没想到的是，加薪居然位于最顶层。 其实这也暗含了“在其位谋其政”的道理， 在渴望加薪之前，自己得先拥有让人信服的能力和成绩， 因此获得权力则成了比加薪更为基本的需求。
分权的作用我深有体会。最近我将一个不算太大的项目全权交给了一名下属。 结果那名下属每天主动自愿加班到深夜10点多，去做预算、分配任务、制定规则。 我并不赞成她加班；但她的这些行动不仅使我颇受感动， 更让我明白了一个道理：分权，不仅是让管理者解脱，更是满足员工需要的一个重要途径。
诸葛亮就不是个好领导，事必躬亲，不仅自己没有从繁重的政务中解脱出来， 更使得下属因得不到权力而心生不满（后来魏延造反则缘于此。）
想起前一阵子看过的雅尼卫城音乐会，印象最深的是那些独奏。 雅尼的独特之处就是他不仅让小提琴这种大众化乐器出风头， 也让定音鼓、贝斯、手鼓这些平日的幕后角色有机会抛头露面， 在音乐会上展示个人技巧。 这正是雅尼作为团队领导者的风范，将权力分给下属， 满足他们的精神需要，让他们有机会自我发展。
