7. 撰写文档 任务:创建一份文档来解释自己的代码有何作用或者应用程序如何工作。这项工作当中可能包含创建多个独立文档以及代码注释。任务的目标受众范围非常广泛，从终端用户到其他开发人员都可能涉入。 挑战:这很可能是一项费时费力的任务，甚至有些浪费青春——毕竟愿意认真阅读说明文档的用户实在没多少。程序员通常更乐于通过编写代码来直接生成说明文档。 群众观点：“撰写这种根本没人会看或者会用的垃圾文档，只是因为这是‘流程’的一部分。” “不能处理代码，反而需要撰写一份能清晰解释当前工作的文档。” “撰写文档时，需要同时满足良好、解释清晰以及简洁三大要求！”
6.被迫实现那些自己无法认同的功能 任务:有时候我们认为某些特性或者功能根本不应包含在应用当中，但客户或者某些职级更高的家伙却坚持要这么干。 挑战:抛开我们的个人感受或者意见，花费时间和精力来实现（并支持）那些尚存疑问的功能。 群众观点：“……我们只有两种选择——要么忍气吞声、要么趁早滚蛋。”
5. 处理别人的代码 任务:不得不为由其他开发人员编写的应用程序或者代码片段进行维护、调试或者强化。 挑战:尝试理解某些遗留代码片段的工作方式并揣测原始开发者的真实意图本身已经很不容易，如果无法跟那家伙取得联系或者其人的编程水平、注释说明或者历史记录特别糟糕，这项工作就会变得更难。 群众观点：“尝试处理那些语焉不详的代码。” “有些人根本没资格编写代码，可有时候我却得处理他们抛出来的东西……” “尝试破译成千上万行未加注释的代码。”
4. 和其他人打交道 任务:收集来自客户的需求信息、向管理层提交状态报告、与测试人员们共事以及向其他工程师交代项目内容等。 挑战:向非技术人员解释技术内容，工作主动权落在他人手中，与品质保证人员或者其他开发人员发生分歧。 群众观点： “与某些人比起来，我更喜欢跟处理器交流——这样更方便。” “来自非技术人员的阻碍……还有那些来自其他技术人员的代码编写指导……” “……对于技术行业一无所知的家伙实在很难沟通。” “其他团队的成员进度滞后，而我们只能坐着干等……” |
