在外行人眼里，软件开发工作就跟看天书一样难——但是程序员往往会一脸苦哈哈地表示“还有更难的呢！”
简直就是分分钟秒杀，精神分裂啊！！！
1. 设计解决方案
任务：给出一系列要求，设计出可实施的方案，包括设计数据和代码结构、功能算法和应用程序流程。
难点：确保你设计的解决方案得满足客户的要求，并且按时完成。
网友的话：
“如何始于此终于彼可谓是最难的部分了。”——misconfiguration
“过于臃肿的设计会崩溃，过于浅薄则没有用。”——nvteighen
“不去一个个试一试，就不知道什么样的方案才适用……。”——jpkotta
2. 写测试
任务：编写单元测试，以确保每一部分代码都能正常运作。这些测试不但有助于在开发早期找出 bug，还能方便后续的回归测试。很多开发方法论甚至鼓励我们在写代码之前就可以先写好测试程序。
难点：选择和编写测试的过程是既辛苦又繁重的，有时候会让人感觉是在做无用功。
网友的话：
“我就是不喜欢写测试，你能怎么滴。”——Anonymous
3. 编写文档
任务：创建用于解释代码和应用程序的文档，包括独立文档和代码注释。目标人群范围从终端用户乃至其他开发人员。
难点：很耗时间，甚至有时候你会觉得要是没人看的话那不就是在浪费时间。
网友的话：
“Shit！！！就因为这是“进程”的组成部分，我们就得写这些可能根本没人会去看的文档。”——Christian Dechery
“通过文档，我们不需要阅读代码就能知道其作用。”——Raghu Nandan
“简洁又能清晰阐述的文档，我的大爱啊！”——Ayush Goel
4. 实现自己并不认可的功能
任务：不管什么原因，如果你的客户或者上司坚持某个特性和功能，那么你就不应该将个人的感情因素带到工作中去。
难点：摒弃个人想法和意见，竭尽全力地实现或支持功能需求。
网友的话：
“……当然你也可以坚持己见然后提早退休，呵呵。”——Sabbir Asgar
5. 关于别人家的代码
任务：维护、调试或改善由其他开发人员写的应用程序或者代码片段。
难点：理解前任开发人员的代码是非常痛苦的一件事，特别是如果此人已经离开，而他的代码写得乱七八糟、缺少必要的注释和文档，那就更悲剧了。
网友的话：
“没文档的代码就像后妈。”——Omar Diab
“应该淘汰掉那些不会好好写代码的程序员……”——Nani Tatiana Isobel
“代码破万行，没有注释也不怕不怕了。”——Simon Zhu
6. 和其他人打交道
任务：收集客户需求，提供状态管理报告，配合测试人员，和其他工程师协作。
难点：需要向非技术人士解释技术问题，不得不依赖于其他人交接过来的任务，与 QA 或其他开发人员出现意见相左情况的处理方式。
网友的话：
“交代机器干事比交代人去做要来得容易得多。”——Marko Poutiainen
“三人行，必有我师焉……合作也是学习的机会。“——Anonymous
“……和外行人说话简直就像对牛弹琴。” ——lnostdal
“总是要等其他团队完成任务之后我们才能开工，太拖我们的后腿了。”——Anonymous
7. 预估项目工期
任务：项目一开始，就需要估算出完成所需要的时间。
难点：哪怕没有接触过项目，手头只有模糊的需求说明也得硬着头皮预估时间。
网友的话：
“在开工之前，真的很难估算出会出现多少乱七八糟的问题……”——Jan Christian Meyer
“我发现估算时间可能是最难的部分了，因为很多人会将其当做一个承诺，信守着一诺千金。” ——Samnang Chhun
“……每次碰到这个问题我就一个头十个大……”——Jack Menendez
8. 解释我的工作
任务：向非程序员——亲朋好友，解释自己的工作内容。
难点：亲人和爱人不了解我们是做什么的。总是被要求去解决任何与计算机有关的问题（比如修电脑）。
网友的话：
“总是要跟人解释——我，不是，修电脑的。”——Brandon P-Lost
“不止一遍地和我的家人说明，我到底是干什么的。”——Utsav Singh Rathour
“编程的世界，外行人不懂。”——Anand Safi
“为什么别人都认为我是给电脑安装盗版操作系统和其他盗版软件的家伙呢？我干什么了我，我只是程序员。”——Anbu Jey
9. 命名
任务：为变量、过程、函数、类、对象、数据库组件等命名。
难点：即使是一个小程序，也会有很多需要命名的东西。名字最好一贯又简洁，有内涵，能承载一些意思——这个是什么或者这是用来做什么的。
网友的话：
“想啊想啊想名字，想出一个好名字~”—— Aditya Muraletharan
“别烦我，我正在给函数命名呢。”—— Lakshman Siripurapu
“计算机科学中只有两座大山：缓存失效以及命名。”——Phil Karlton