本文是前天晚上的一个答案，稍作修订，放到这里。
下面的图表是我个人工作十年以来各项时间占用的大致变化情况。需要说明的是，这不是由精确的统计汇总而来，而只是大致估算；不是我认为理想的情况，而只是此期间实际发生的情况。
(设计和实现) 长期来看，你愿意花在设计和实现的时间，基本上取决于你对这项工作的热爱程度。我见过一些进入管理岗位的同事，这两项迅速地滑落至接近 0 的；也见过始终对编码本身情有独钟的——这并没有对错，只是不同个体的兴趣，权衡和选择。
(测试和调试) 总得来说，随着工程能力的提高，程序员的职业生涯里的测试和调试时间应该是稳步降低的。基本上你总是能把越来越多本来需要手动完成的事情交给机器去做，比如包括__运行某个游戏流程__和__查看渲染效果__这类本来需要人来做的事情，运用恰当的脚本和图像对比手段，在绝大部分情况下都能比人做得更快更好。
(沟通) 沟通需要单独拎出来说一下。随着时间推移，不管是否情愿，用于沟通的时间应该是逐渐增加的。但当接近或到达一个分水岭 (对我来说是 C 阶段的 50%) 时，我意识到如果不做点什么，很快会演变成做一整天沟通，只有晚上瞅着空写写代码的凄惨结局，于是学着不断地有意识地限制沟通的频率和长度，利用各种策略来避免无效的沟通，到现阶段能大致控制在工作时间的 1/3 左右。
关于几个阶段，简单补充说明一下，
阶段 A 时我刚刚毕业入行，在一家外企做普通程序员。由于需求相对比较固定，主导权和解释权一般都掌握在 Game Design 的手上。作为普通工程师，在引擎提供的框架内做有限的功能，大部分工作是不太需要架构设计的编码工作。
阶段 B 时，我在一家网游公司做客户端引擎组的组长，负责引擎技术和相关的人员管理。这是我成长最快的一个阶段，也是职业生涯前期里，安排相对均衡的一个阶段。由于三个原因：1. 需要在一穷二白的基础上建立完整的 3D 游戏工作流程 2. 缺乏有经验的 TA (那个时候国内还没这个概念) 3. 我本人缺乏管理的经验，因此在沟通 (尤其是跨部门沟通) 上投入了较多的时间。
阶段 C 时，我是一个初创公司的技术负责人，跟阶段 B 相比，更为艰巨和困难，而对于游戏的制作和流程有了一定认识和思考的基础之后，我希望能够有机会面对更大的挑战。虽然条件艰苦资源匮乏，但一年多的时间打造出来一个技术团队，个个能够独当一面，而我穿梭其中，铺路搭桥。在这个时间点上，我个人最缺乏的是对资本，市场和商业逻辑本身的理解，因此造成了一些先天和后天的限制。团队解散时和大家淡定作别，回到家时一个大老爷们在书房里关上门泣不成声。
阶段 D 和 E 就不多说了，我试着把自己的目光从一个接一个的移动靶上拉远，不再以“开宝箱”的心态面对项目，试着让自己沉静下来，试着不去用声名财富衡量自己的事业和人生，试着做到“宁静而致远”，试着让自己比以前更从容。随着年岁渐长，我也许不再能彻夜加班，但仍会去思考和提炼，投入地去做那些我认为有价值，有意义的事。
让我觉得踏实的是，我慢慢地知道了自己是谁。
(全文完)