我的时间分配变迁记：程序员工作时间管理指南

　　游戏观察9月14日消息，程序员工作中占时间最长的是哪个步骤?

　　下面的图表是我个人工作十年以来各项时间占用的大致变化情况。需要说明的是，这不是由精确的统计汇总而来，而只是大致估算;不是我认为理想的情况，而只是此期间实际发生的情况。

　　(设计和实现) 长期来看，你愿意花在设计和实现的时间，基本上取决于你对这项工作的热爱程度。我见过一些进入管理岗位的同事，这两项迅速地滑落至接近 0 的;也见过始终对编码本身情有独钟的——这并没有对错，只是不同个体的兴趣，权衡和选择。

　　(测试和调试) 总得来说，随着工程能力的提高，程序员的职业生涯里的测试和调试时间应该是稳步降低的。基本上你总是能把越来越多本来需要手动完成的事情交给机器去做，比如包括运行某个游戏流程和查看渲染效果这类本来需要人来做的事情，运用恰当的脚本和图像对比手段，在绝大部分情况下都能比人做得更快更好。

　　(沟通) 沟通需要单独拎出来说一下。随着时间推移，不管是否情愿，用于沟通的时间应该是逐渐增加的。但当接近或到达一个分水岭 (对我来说是 C 阶段的 50%) 时，我意识到如果不做点什么，很快会演变成做一整天沟通，只有晚上瞅着空写写代码的凄惨结局，于是学着不断地有意识地限制沟通的频率和长度，利用各种策略来避免无效的沟通，到现阶段能大致控制在工作时间的 1/3 左右。

　　关于几个阶段，简单补充说明一下，

　　阶段 A 时我刚刚毕业入行，在一家外企做普通程序员。由于需求相对比较固定，主导权和解释权一般都掌握在 Game Design 的手上。作为普通工程师，在引擎提供的框架内做有限的功能，大部分工作是不太需要架构设计的编码工作。

　　阶段 B 时，我在一家网游公司做客户端引擎组的组长，负责引擎技术和相关的人员管理。这是我成长最快的一个阶段，也是职业生涯前期里，安排相对均衡的一个阶段。由于三个原因：1. 需要在一穷二白的基础上建立完整的 3D 游戏工作流程 2. 缺乏有经验的 TA (那个时候国内还没这个概念) 3. 我本人缺乏管理的经验，因此在沟通 (尤其是跨部门沟通) 上投入了较多的时间。

　　阶段 C 时，我是一个初创公司的技术负责人，跟阶段 B 相比，更为艰巨和困难，而对于游戏的制作和流程有了一定认识和思考的基础之后，我希望能够有机会面对更大的挑战。虽然条件艰苦资源匮乏，但一年多的时间打造出来一个技术团队，个个能够独当一面，而我穿梭其中，铺路搭桥。在这个时间点上，我个人最缺乏的是对资本，市场和商业逻辑本身的理解，因此造成了一些先天和后天的限制。团队解散时和大家淡定作别，回到家时一个大老爷们在书房里关上门泣不成声。

　　阶段 D 和 E 就不多说了，我试着把自己的目光从一个接一个的移动靶上拉远，不再以“开宝箱”的心态面对项目，试着让自己沉静下来，试着不去用声名财富衡量自己的事业和人生，试着做到“宁静而致远”，试着让自己比以前更从容。随着年岁渐长，我也许不再能彻夜加班，但仍会去思考和提炼，投入地去做那些我认为有价值，有意义的事。