梦想风暴

有人问我，在目前这个项目中，和外国同事一起工作的感觉如何，我答曰，他们更职业。

这里说的职业，并不是说他们写出的程序本身有多么神奇，恰恰相反，他们写出来的程序和我们写出来的程序，看上去并没有多大的差别。之所以，他们给我留下更职业的感觉，主要是日常工作的一些细节。

刚开始进入项目的时候，我们几个中国同事对项目完全是一头雾水，甚至Rails开发都很少，所以，在和他们一起工作的过程之中，就需要他们为我们做大量的解释，而这种时候，他们总是表现得非常耐心。有时候，语言上的障碍让我们不能一下子抓住他们说的重点，他们就会不厌其烦的一遍遍解释着，直到我们表示自己真正的理解了。

刚刚入门的人难免会问一些愚蠢的问题，他们并不会嘲笑，反而会认真的给你讲解，这会给人以极大的信心，不会因为问题的愚蠢而被打击了积极性。回顾自己之前在工作中的表现，在这一点上，我做得总是很不够，我愿意给人解释一些问题，但对于简单的问题，我有时会表现得不屑一顾。实际上，谁没有从笨笨的初学阶段走过来呢！对于初学者，鼓励的作用更大一些。最近一段时间，我会和几个新近加入项目的同事一起工作，自己刻意在这个方面注意了一下。

前些天，有一些来自产品环境的任务，要对产品数据做一些修改。这些外国同事对这种问题的想法是，写个脚本解决它，即便数量不是很大。所以，那几天几乎每天都是在写脚本。其实，对于数据量不大的一些修改，手工修改可能来更快，但是，每次都用脚本解决问题，一来可以锻炼一个用脚本解决问题的好习惯，二来可以避免做一些让自己头疼手工操作，将其转化为编程问题，解决起来更有乐趣，再有，以后遇到类似的问题，有之前的脚本可以参考。这里不得不说一下用Ruby写脚本还是很方便的，Rails项目的开发和维护都用Ruby，很大程度将二者统一起来。

项目进行性能测试，一个外国同事将测试结果放到了一个电子表格中，做成了动画效果，很高兴的给秀给我们看。因为在他看来，那是一件有乐趣的事，尤其是一群人乐呵呵的围绕在他身边看他的工作成果。

我们的开发平台是Mac，基本上就是一个Unix平台。所以，我们的外国同事经常会给我们展现他们良好的运用Unix命令的能力。他们经常将一些Unix命令组合起来，完成一些辅助开发的工作，很大程度的提高了工作效率。

在我们项目的Mingle里面，有一个Dev Standup的页面。在日常的开发中，一些解决起来会有些困难部分或者影响会比较大的部分，就会记录在这个页面里面。一方面，分布在中国和美国的同事都有机会知道对方做了些什么影响比较大的部分，另一方面，双方也可以协作解决一些对方觉得头疼的问题。

在ThoughtWorks做程序员，幽默感是不可缺少的一环。所以，经常会出现这样画面：“你能帮我一下吗？”，“不”，然后，一个人过去问什么事；“一个问题”，“一个答案”；两个人正在讨论，有一个人过来说“我觉得有道理”，另一个过来说“我不这样认为”……

今天到CSDN参加了一个关于开源的讨论，谈到了自己参加开源项目的感受，也谈到了公司的一些情况。关于自己的部分，前前后后在blog里提到了不少。这里稍微整理一下自己对公司开源情况的一些理解，不见得完全正确，只是基于自己看到的和理解的，如果哪位同事觉得不对或不足，不妨站出来纠正或补充我。

ThoughtWorks是一个咨询公司，这意味着我们有很多机会参与到不同领域的开发之中，也就让我们的经验可以得到不断丰富，更重要的是，我们有机会知道哪些经验是可以复用的。一些可以被复用的知识就在开发过程中被识别出来。ThoughtWorker们是一群愿意不断把事情做得更好的人，于是，就会有一些人把这些可以复用的部分提炼出来，将其开源，把这些知识分享到给社区。据说，CruiseControl、RubyWorks就是诞生自ThoughtWorks的实际项目。

ThoughtWorks最有价值的部分是人。和这样一群人一起工作，只要你把自己的想法抛出来，就会有人愿意与你讨论。相信大家都有类似的经验，很多时候，自己想一个问题很容易走进一个误区，而和别人稍微讨论一下，即便这个人的言论本身并不能给你带来太多的价值，但这个讨论的过程会让自己的思路逐渐清晰起来。ThoughtWorker们是一个巨大的思想来源，这样一群人之间的讨论经常会激荡出各种各样的火花。一个业余的例子是上周五下班之后，一群人玩编故事的游戏，其结果是包括周边的人在内，大家都已经乐得直不起腰了。

开源，需要一个环境。如果周围的人都在做开源，自己就会以为开源是一件理所当然的事情。列在公司开源网站上的项目，其实那只是一些比较知名的项目，也是冰山一角。平时，不经意间和某个人聊天，你就发现，原来身边的这个人正在做一个开源的东西。大家在一起讨论的时候，也经常可以听到这样的话，那就不妨开源一下试试。陶公子最近发起了一个关于Domain Model的讨论，我就对他说了类似的话。

公司内部有一个Innovation Community，也就是说，公司是鼓励大家进行创新的。经常会收到公司内部关于Innovation的邮件，介绍一些最近一段时间有人做的一些事情。其中很重要的一环就是一些ThoughtWorker新近发起的一些开源项目。gigix最近就在一次Innovation Community活动上，介绍了fluorida。

如果一些开源项目能够证明自身的价值，公司也是愿意投入一些精力将它完善。Selenium和CruiseControl就是这样在ThoughtWorks的协助下，得到了快速的成长。当然，不只是公司员工的项目，对于一些其它有价值的项目，公司也会投入一定精力去做，比如Ruby和JRuby。

有了这样的土壤，开源也就变得自然而然。

谁是最受程序员欢迎的雇主？

一篇关于最佳雇主的帖子，很高兴在里面看到了ThoughtWorks的名字。

很快，成为ThoughtWorker就要满一年了，这一年时间里，我一直享受着在ThoughtWorks工作的乐趣。确实，它和我之前工作的环境差别很大：开放的工作环境、没大没小的工作关系、不利于保持身材的零食、需要排队的游戏机等等。这段时间一直在考虑一个问题，对我而言，ThoughtWorks到底好在哪里。思来想去，我的答案是人文环境。

依然记得当年，我在当时的部门里发邮件尝试与大家讨论技术，应者寥寥；
依然记得当年，有人劝我放弃所谓新鲜想法，老老实实走在原来的道路上；
依然记得当年，有人对我说，只有做管理才有更大的价值，怎么你对管理一点兴趣都没有；
依然记得当年，我们把“以人为本”作为笑话来听；
……

我也依然记得，当年选择软件开发作为职业是因为热爱；
我也依然记得，当初遇到Darwin点燃了我对技术的热情；
我也依然记得，在本应完成一个功能的时间里完成整个系统重写的快感；
我也依然记得，修改别人留下的bug缠身的程序直至深夜；
……

用了自己职业发展的最初几年，我逐渐清晰了自己在职业发展路上的追求。我会努力走在自己预期的路上，如果环境不能再给予我所需要的，我会寻觅其它的环境。

在这里，我得以继续走在技术的路上；
在这里，身边有一群有想法的人，让讨论可以深入下去；
在这里，总有人能在不同的角度给你一些新鲜的东西，让我不得不偷偷去补各种各样的新知；
在这里，可以和有很多年的工作经验的人一起工作，学习他们解决问题的思路；
在这里，完成功能绝对不是开发的终点，大家总是竭尽所能让程序看上去更清晰；
在这里，关注用户价值会成为程序员也要思考的问题；
在这里，我有机会体验不同的角色；
在这里，我终于弄清楚了leadship和management不是一回事；
……

幸运的是，我坚持了自己的选择；幸运的是，我成为了ThoughtWorker。

周末没得闲，因为参加了一次CodeJam。

CodeJam，是公司组织的一个编程活动，就是要在周末两天时间内开发出一个东西，据说此类的活动在其他的办公室举办过。这是我第一次参加类似的活动，参加这次活动的Dev都是公司内比较优秀的程序员，平时很难把这些人都放到一个团队里面，有机会和这些人在一起工作，本身就是一件令人期待的事。

这次活动的目标是为一个支援乡村教育的组织开发一个分享平台。在活动开始之前，我们对需求一无所知，所以，几乎就是看两天内能够写出多少东西。因为这个项目要开发的是一个Web应用，从生产率的角度来看，我们当仁不让的选择了Rails作为开发工具，这也是我最近在学习Rails的原因之一。

万事开头难，这次CodeJam也不例外。在一群Dev准备甩开膀子大干一场的时候，我们发现了一个问题，没有需求。需求，是冰云（BA）和QQ（QA）在之前一天和我们的客户谈好的。QQ在离开办公室之前，把从需求整理出的Story卡片锁到了自己的抽屉里，结果，第二天，她闹肚子了。好在冰云临危不惧，顶着我们的巨大压力，把部分Story重写了出来。直到QQ重新归队，打开宝箱，需求问题才得到了彻底的解决。

正式开工，场面那是相当壮观。一群ThoughtWorker，一群快手，一帮人抢着提交代码。做用户登录部分的高喊着，他们应该是第一个提交数据库表的，结果，更新代码时，已经有了数据库版本已经到了3。那是我和WPC干的，因为我们俩负责搭建开发环境，所以，先下手为强了。不过，我们高兴得有些过，用scaffold生成的代码出现了一个拼写错误。这时我们才发现，修改这些生成代码是多么痛苦的一件事。

在这里，我们用的典型的ThoughtWorks工作方式，一对Pair，拿到一张Story卡，然后，小步前进：测试、编码、重构、提交。正是因为步幅很小，所以，就出现了大家争抢着提交代码，因为稍微慢一点，就会更新下来一片代码，这种时候，便要重新运行测试。运气不好的话，破坏了别人的测试，还要帮别人修复。其实，在一个大的开发团队中，这种现象很常见，尤其是测试多到不能很快运行完，比如有集成测试的时候，常常是运行测试之后，又来了新代码。

典型的ThoughtWorks工作方式，还有另外一个含义。一群人一边写着代码，一边互相开着玩笑。在我的印象中，ThoughtWorks开发团队从来就不缺少笑声。其实，这次参加CodeJam的人，有很多我并没有直接在一起工作过，所以，这也是一个很好的了解大家的机会。比如，在我的印象中，WPC一直是闷着头写代码的家伙，和他Pair才知道，他原来也是那么有才，可以让人笑得肚子疼。至于像徐X和gigix这种平日里就给大家很多欢乐的家伙（也许也包括我自己）就更不用说了。当然，也有比较安静的，亮亮和来自加拿大的Ricky被我评为“最安静的Pair“。

两天下来，从无到有，一个具备基本功能的网站就建立了起来。showcase的时候，看着这个小网站，心里还是很有一丝满足的。对我而言，这是我第一次做Rails项目，第一次尝试用TextMate去开发。

这次CodeJam，是在公司内部进行的，希望将来有机会把这个面扩大一些，让其他公司的人来和我们一起来做，一方面我们可以从其他人身上学习到一些东西，另一方面，也让别人了解一下ThoughtWorks是如何工作的。我相信在如何进行软件开发这个问题上，ThoughtWorks做得足够好。

UPDATE
其他的ThoughtWorker也有对这次活动发表了自己的看法。
冰云：Beijing Code Jam - 2 days agile development project
Ricky：CodeJam@Thoughtworks Beijing

第一次参加ThoughtWorks的Away Day。Away Day是公司给大家提供一个在一起交流放松的机会，一般会利用周末的两天，第一天有人各种各样的session，用以交流，第二天就是玩，用以放松。

Away Day，字面的意思是，一个离开办公室的日子，鉴于今年刚刚搬进新办公室，出于对新办公室的喜爱，今年Away Day第一天的活动就放在了办公室里。

Away Day，公司一下子变得很热闹。原来驻扎西安的大部队来到的北京办公室，原本分散在北京和西安两地的中国区员工终于团聚在一起。ThoughtWorks Studio的两个团队——CCE和Mingle也在北京扎根。此外，还有不少从其他办公室来参加Away Day的同事和已经签约明年准备加入公司的毕业生。当所有人坐到一起的时候，我才第一次觉得ThoughtWorks在中国已经有很多人了。依稀记得我当初面试时，二三十个人围坐在桌边的情景。不到一年，我们壮大了许多。老大在讲话中回顾了当年和黄亮谈offer时的情景，颇有些忆往昔的感觉。

第一天的session内容很丰富，技术、招聘、公司策略、创新等等，应有尽有，甚至有人还组织了一个世界发展的话题。虽然是一次内部活动，但内容一点都不含糊，而且，讲者与听众通常很熟悉，所以，常常会有一些精彩的问答。据说，Jon Tirsen在介绍Erlang的session上，问到讲演者不得不说自己还不是太熟悉。我也亲见了一个session里面，一个“why not”让讲演者沉默了半天。

我也同样做了一个session，话题是关于招聘中的code review。因为在ThoughtWorks工作这段时间，除了写代码，干得最多的就是招聘了，而code review做得尤其多，几百个总是有的，所以，略有心得。原本我考虑讲一个技术的话题，但后来一想，Away Day是一个轻松的日子，讲生涩的技术会让大多数头疼的。事实证明，在Away Day中，技术讲座的听众相对来说会少一些，比如，徐X那个关于用Ruby做interpreter的话题，只有为数不多的人在场。:)

对我而言，做session并不是一个最好的选择。因为当天我还是花了不少时间在准备上，所以，我只听了很少的内容，有些遗憾。我的session是当天的最后一个，因为前面人的超时，我不得不用绕口令的速度进行快速讲解，否则，耽误了大家的晚饭，后果会很严重。

结束了session，就彻底进入到一个交流的环节。无论是当天的晚饭，还是第二天的出游，感觉自己几乎一直在和不同的人说话。在ThoughtWorks，我们是鼓励和不熟悉的人进行交流的，因为指不定哪天大家可能就会在一起工作，即便是简短的交流，也会为未来奠定一个良好的基础。

虽然是第一次参加Away Day，感觉不错！