很多同学以为程序员一天到晚的工作就是写代码，写代码，写代码！
其实不是的。写代码只是很少很少的一部分工作，其实更多的时候，我们：
读别人的代码
通常我们进入公司以后，不会是重头开始一个项目，而是在已有代码的基础上进行维护或新功能的开发，所以必须“读代码”。
读有“泛读”，了解系统架构、功能模块，对系统有一个大致的认识，各个功能能找到相应代码实现的位置。
还有“精读”，通常就是调试了，在fix bug的时候使用。此外还包括审核：一些规范一点的公司，都会有code review，也是精读，但不用debug。
对于一个成熟的项目来说，读代码——而不是写代码——可能是最耗时间的工作了。
写注释文档
为了减少“读代码”的时间，我们不得不花时间“写注释”“写文档”——这个程序员最深恶痛绝的工作。所以现在“烂代码才需要注释”的声音变得越来越强，但无论如何，文档还是要写的。（注意：要能区分注释和文档）
了解需求
好了，终于到了“写代码”的时间了。
然而，在动手开始写代码之前，你必须花时间“了解需求”。和自己写个小程序玩玩不同，在公司，你是为别人写代码，所以你一定要了解别人究竟想实现什么功能。通常，这并没有你想像的那么简单，需要反复的沟通。
当然，也有一些团队和个人，不愿意在这上面“浪费时间”，通常他们的下场就是不断的写代码，然后不断的改代码，加班加点的做大量的无用功，整个公司怨气冲天一地鸡毛。
开发中的其他各种沟通
大家都恨产品经理。
但其实产品经理只是我们最恨的人之一，我们还恨前端、后端、DBA、测试……承认吧！因为我们是团队开发，说好的团队精神有没有我不知道，但各种摩擦扯皮是必须的。
比如前端要后台给一个接口，后台给不出来或者嫌麻烦；比如后台跪求DBA的权限，DBA优化数据库时说Developer都一群傻逼；比如测试一次又一次的报bug我特么像杀人的时候……
这些都需要沟通，也就是需要时间和精力。
其他无聊的办公室活动
比如写日报周报，应付各种KPI，这是所有工种都干的活，就不多说了。
总之，程序员真正写代码的时间其实不多。个人觉得，一天能有30%的时间安安静静的写代码，就算是不错的工作环境了。
不论是我们的大学教育也好，培训机构也罢，都只知道知识的灌输，而忽略了程序员工作能力的培养。这些能力，即只能在工作中“自学”获得，所以你看这些公司的招聘，都要求“两年以上工作经验”，意思就是：一般的新人，起码要两年的时间，才能“习得”这些起码的工作技能。
能不能有所改变呢？
我想试一试。
