Program? Me?
February 27th, 2011
这也不是新鲜事。这也不是中国特色。从前听的版本有几个：
- 业务分析师是不会写程序的。（所以 Cucumber 写出来要像自然语言。）
- 测试人员是不会写程序的。（所以 Selenium要有IDE 。）
- 界面设计人员是不会写程序的。（所以我们还得有个叫“前端程序员”的人用HTML+CSS把图片做成页面。）
- 项目经理是不会写程序的。（这个，大家都习以为常了…）
现在最新的版本是：系统管理员是不会写程序的，所以 Puppet 比 Chef 要好那么一点点（TWers请看这两天twswdev上的讨论），因为Puppet是声明性的DSL而Chef直接就是Ruby代码。Ruby代码会把笨笨的系统管理员吓倒云云。
扯淡。
所有这些人，只要还在从事软件开发相关的工作，他们都需要描述抽象的概念、把概念分别组织、用合适的词汇使概念描述可懂、关注概念中易变的部分和不变的部分、抽取概念中的共性、消除概念描述的重复。这个，就是编程。你可以逃避它，你可以拒绝学习它，但当你认真对待它，当你把它做好了，这就是编程。那时候你就会发现，Ruby是一种具有强大表现力因此更贴心的编程语言，HTML+CSS是比Photoshop更适合描述界面的语言 。
重点在于：如果你一直在用一种并非设计用于描述大量复杂抽象信息的表达方式来描述大量复杂抽象信息，你为什么不去学会一种本来就设计用来干这个的工具呢──那就是编程语言；另一方面，如果你并没有在描述大量复杂抽象信息，很可能你的工作可以被一个脚本取代。
毕竟，从前的系统管理员都是Perl和Shell的高手。现在突然说他们不会编程，这个对我来说实在太突兀了。
三人成众
November 13th, 2009
一个人是孤单的，就像“人”字，只能自己支撑自己。
两个人的团队，如果不是互相对立的话，就难免有一人比较强势。如同一个“从”字，主从关系往往确定下来就不易改变。
四个人或更多人的团队，就常会分裂成小帮派。
三个人的团队是个绝配。三人成“众”，既互相支撑，又互相平衡，均势来回变，难有某一人永远强势。一起出现，三人不显太多；分开行动，一人两人可以灵活配置。
而且争吵能得到有效控制。一旦两人出现争执，另一人便可客观评判，居中调停。而且这次的旁观者下次就可能成了争执的一方，这次的争执者下次又换了调停的角色。于是每个人在身涉争执时大可各执一端畅所欲言，因为信任旁观者已有准备平息战火。于是争执也常被带往健康的方向。
所以如果去陌生而紧张的环境工作，三个人的团队是很好的选择。
Tech Lead的三重人格（完整版）
August 17th, 2009
很多团队都有tech lead这个角色的存在，但同时很多团队对这个角色都缺乏明确的定义。大多数时候，团队只是指派其中经验最丰富、技术最精熟的开发者来担当tech lead。但除了“tech”的成分之外，这个角色还有“lead”的成分，这就决定了他不仅需要技术上的能力，还要眼观六路耳听八方，才能带领团队── 至少是开发者们──取得成功。Tech lead需要关注的事情可谓纷繁芜杂。把这些事情分门别类，我们可以看到，这个角色大致有三方面的职责：技术决策者、流程监督人、干扰过滤器。
InfoQ中文站：Tech Lead的三重人格
Tech Lead的三重人格
July 15th, 2009
ThoughtWorks项目中tech lead的三顶帽子
- 技术决策者
- 流程监督人
- 干扰过滤器
温伯格定义技术领导者的三种功能
- 定义问题
- 管理思想的交流
- 保证质量
