不止一次的，我听到身边从事软件的朋友的抱怨：我已经从现在工作中无法获得成就感了；项目上的东西都会啦，有什么新的需求想法闭着眼睛也知道怎么实现；8小时期待完成的工作，6个小时就做完了；下班之后，工作上的事情也没什么好像的，似乎一切都顺水推舟那么轻松和容易。

一些不满足的程序员开始偷偷摸摸搞副业。学习新的语言，或者研究新的技术，自己设计一点小东西，乱七八糟的都来一点。从结果看来，居然还不错——工作没耽误，自己也能够与时俱进的与这个变化越来越快的技术世界保持同步。

我清楚的记得在公司的每一个项目。项目初始的时候一切都是未知，需要花费很多的时间去学习和了解：不同的业务领域，不同的技术体系等等。虽然难，但至少有张力驱使。这个阶段不长，很快，项目中边边角角的东西成为工作常态，工作本身变得不那么有趣起来。这时候，完成工作本身之后，研究相关的东西成为常态。很多有意思的东西都是在这个阶段完成的。例如04年做的Buffalo, 就是在做某个商业智能产品过程中抽取出来的；InWritingRoom(Python, GAE)是在新加坡做的；ycl0(NodeJS)则是在去年做Rails项目做的。这些当然谈不上出色，甚至都谈不上“产品”，但是对于保持对软件的热情和兴趣，以及适当分散主职工作直接注意力都有莫大的好处。当然你也可以发现无数其他的例子，Rework这本书是37Signals在自己运营过程中产生的副产物；Twitter Bootstrap则是自己做产品过程中的结晶；capybara则是一个很普通的商业公司在工作过程中的副产物。

为了验证这个想法是不是具备普遍的通用性，我尝试在自己的团队中进行这项尝试。在项目度过初始的混沌期后（一般是两到三个月），开始“不务正业”，例如让团队每周拿出2小时在一起来学习新的语言技术。我们做过用Scala/Javascript/Box2D的坦克大战，也“尝试”做过用Ruby/REST纯命令行的扑克牌游戏。无独有偶，当我将这些与别的公司朋友交流时，他的团队对此类活动也非常欢迎。没有数据证明这样做会带来多少的生产力损失或者能力提升，但直觉中，创造常规工作之外的共同挑战，对于自我的提升与团队凝聚力，都是有着明显的改善。

传统的管理者似乎妄图控制程序员的每一个脑细胞在工作时间、甚至工作时间之外为雇主做出贡献。最简单直接的做法是无休止的加班；或者相当饱和的工作量。殊不知，程序员自己都无法控制自己的思维，何况外力？另外，也见过一些传统的公司传统做法：将工作内容只是换了一种形式，例如“Find Bug Day”之类，能够激起一点兴趣，但长远看来，与工作关系不大的反而能获得更多的热情。