在此，无关技术，只是从效能上探讨下，如何提升工作效率，结合了大量研究，分析，实践证明。
同一时间最好只做一个任务
温伯格提出一个经验法则，用以计算由于切换项目而引起的浪费。
即使你只做一个项目，这种情况也可能会发生，你会被邮件、聊天所打扰。
这里的奥秘是：在你管理程序员的时候，你会发现切换任务会花费很长时间，那是因为编程这类任务需要你在大脑记住很多东西。你同时记住的东西越多，编程效率就越高，一个程序员在全力编程的时候，脑袋里面同时记着数不胜数的东西（程序里的一切），包括变量名称、数据结构、重要的编程接口、他们自己写的常用工具函数的名字，甚至是他们存放源代码的子目录的名称。如果你送那个程序员休假三周，他会把这些东西忘得一干二净，人类的大脑似乎把这些东西移除了短期的随机存储器（RAM），然后把他们备份到了磁盘上；但再想通过磁盘恢复那些记忆，也许要花上一辈子的时间。
可是我们在工作的过程中很难做到只做一个项目，在开发的过程中被别人的问题打扰，以前的代码出了bug，别人过来找你，等等，在办公室想安心写代码，不存在的。下面我介绍下我的处理方式：
- 工作中我一般都会带着耳机，但未必会放歌曲，以此来避免外界打扰
- 当有测试、前端来找我问问题的时候，我一般都是能马上回答的我回回答一下，如果不能，我会回复说等几分钟，我写完这段东西去找你
- 对于钉钉发送的消息，除非有人钉我，在桌面弹出，否则我都会过一段时间才会看一次，把钉钉消息的声音提示关掉很重要
性能的重要性
根据谷歌的真实测试，请求时间消耗每增加100ms，损失的性能都是巨大的，所有在压测环境使用链路请求时间监控工具，并极力优化性能，是非常重要的。
如果自己写的代码想要优化性能，就需要知道，数组、链表、栈、队列、散列表、二叉树、堆、跳跃表、图、树的操作原理和算法：递归、排序、二分查找、搜索、哈希、贪心算法、分治算法、回朔算法、动态规划、字符串匹配算法，以及“算法复杂度大O”的基本原理。
关于算法复杂度的文章，博主找到一篇说明的比较清晰的：算法时间复杂度、空间复杂度
领导团队适得其法
Dennis Forbes曾经发表过一篇文章，名为“有效地融入软件开发团队”。我觉得他很出色地概括了关于有效领导方面的策略。他用一封假想的电子邮件开头，描述了被人当做强制执行着的弊端：
我最近被拉取帮助一个软件开发团队完成一款产品的开发，具体的要求是协助一些web程序的编码，我尽了自己最大的努力去融入这个团队，热心地帮助他们以赢得一些信誉和尊敬。
我时长转发“Joel on Software”上的各种小文章给大家，还建议公司里摆上一堆像《代码大全》类的书籍。任何事情，只要我觉得可以做的更好，我都会尽力给大家指出来，我经常浏览源代码库，以找出可以让其他成员工作的更好的方法。
当其他开发者来向我寻求帮助的时候，我不仅帮他们解决实际的问题，还举一反三——指出他们在开发上的问题，教他们怎样改进打字形式，告诉他们该使用哪种命名规范，提倡一种更好的代码编辑工具。
然而这些努力似乎都没起到作用，我还是会常常受到他们的抵制，而且我觉得整个团队不是很喜欢我。我的很多建议都没有被采纳，并且我觉得有些人给我的回应是毫不掩饰的讽刺。
我到底哪里错了？
相信我们都曾和这样的人一起工作过。也许我们自己就是这样的人。即使你有最好的意图，并且已经熟读我给大家推荐的优秀书籍，你最终还是会落得跟枪炮士官哈特曼一样的下场：被你自己的团队“枪杀”了。
在文章最后 Dennis对如何避免被自己的团队“枪杀”，做了一个很有想法的总结：
保持谦虚：总是先假定你是错的。虽然开发者的确是会犯错误的，并且作为一个新人，你理所当然应该帮助其他人发现和修正错误，但是在你骄傲地宣布你的发现之前，你应该努力确保你的观察结果是正确的。如果你总是喊着“狼来了”，你的信誉将受到巨大的打击。
提出建设性的批评时要小心：开发者更容易接受非正式的建议和具有巧妙引导性的问题，而不是把同样的内容以电子邮件的形式发送给整个开发组。扩大受众面可能会引起开发者的防御和逆反。团队总是会去猜测你的动机。如果你贬低他们的工作是为了提升你自己，你会因此被投诉而流芳的。
要想赢得信誉和尊敬，最好的方法就是努力工作并且取得实实在在的成绩：廉价而肤浅的替代品——例如群发关于最佳实践的邮件，或者转发别人鼓吹某种关于“银弹”的评论——它们不会产生同样的效果，到头来你可能也只是枉费心机。
百说不如一干：实施一种新的代码控制机制，或者实现一种新技术——这些事情说起来都很容易。所有人都知道，你只是在声明这些主意是你想出来的，而实现他们所需付出的艰苦努力却最终会落在别人的头上——他们会因此而讨厌你。如果你想建议些什么，你应该为此付出实际的行动、做好充分的准备。例如，解决技术接入的难点。这并不能保证团队你的倡议会一呼百应，而且你还可能徒劳无功，但团队会意识到：你付出了努力，你再积极的推动它，而不是在试图捡便宜。
真的关心那些你所领导的人：有的架构师领导为了让程序员快速开发，当看到员工在学习一些开发过程中有疑问的知识的时候，他会阻止你，当你加班在公司学习的时候，他们换个说法让你回家，因为有些人虽身为领导，但他看到你提高便心生妒意，而且这种领导还会美其名曰“为你好”，其实人都不是傻子，如果你真的为别人好，别人感受得到。我想说遇到这种领导就离职把，没有提升空间，没有创新空间，更没有发展空间。
最有效的一种技术领导就是以身作则
程序员的高效工作场所
符合人体工程学的设施
如果有时候会在家里办公的话，花比较高的金额购买一把在家用的舒适椅子是很重要的。
加强代码测试
测试先行的优点
- 单元测试可以证明你的代码是能真正解决问题的
- 你可以获得一个底层模块的回归测试工具
- 你可以在不破坏现有功能的基础上持续改进设计
- 一边写单元测试，一边写实现代码，这种工作方式更有乐趣
- 它们可以被用来真实地展示开发进度
- 单元测试可以被用作示例代码
- 它逼着你在写代码之前做好计划
- 它可以降低bug修复的成本
- 单元测试甚至比代码审查的效果还要好
- 它实际上为程序员消除了工作上的障碍
- 单元测试可以催生更好的设计
- 它比不写单元测试而直接写代码的效率更高
程序员，你幸福吗？
《哈佛幸福课》的作者概括了幸福的真谛
- 经历胜过物质：我的理解是，一个人更应该在意自己做过什么，而不是得到了什么
- 助人为乐：帮助别人的时候也是在帮助自己，任何可以帮助别人的事情都可以加深你和别人的关系，但是有条准则，这个人，这件事值不值得你出手，以为无底限地去帮助别人反而让自己跟傻子没有区别
- 让幸福细水长流：人是最能适应变化的，因此，最有效的花钱方式是经常买来一些小变化，而不是花大钱一下买来一个大惊喜，然后坐等新鲜劲很快过去。就拿幸福来说吧，频率比强度更重要。大家需要改变一下观念，记住很多次小的，愉快地购买能比一次巨额的购买带更能有效的给你幸福感
- 少买保险：关于为什么有这条，我也不太明白
- 为将来买单：即刻的喜悦可能会让你冲动买下承受不起的东西。它无情地扼杀了你期待的感觉，而期待恰恰是幸福的源泉。
- 三思而后行
- 小心比较购物的陷阱：比如，花2元钱买到一块巧克力（不错的买卖），跟这块巧克力好不好吃其实没什么关系。
- 随大流：不要高估你的能力，别以为你能预测你会有多喜欢某样东西。从科学的角度讲，我们在这方面及其不擅长！但如果某些东西可靠地给其他很多人带来了幸福，那它很可能也会给你带来幸福。在你做出购买决定之前，请认真考量一下别人的看法和用户评论。
赚钱不容易。幸福更不容易，请记住上面8点。
最后，是我想说的，也是所有程序员都要思考的，你选择做程序员是为了什么？喜欢么，热爱么？还是为了这个行业还不错的报酬？
我从事这个行业已经有些年头，但是我称不上喜欢或者热爱，期初只是让自己有资本在世界上活下去，其实如果我大学不是被调剂到了相关专业，我是一定不会去做计算机相关工作的，对我来说，这只是我的一份工作，我要靠此养家糊口，仅此而已，但是这就像是一个江湖，进入之后就再也无法退出，因为没人会想让自己多年付出的努力，做出的积累付诸东流，我的路只有砥砺前行。
但是我再过一年就30了，随着年龄的增长，身体会越来越差，脑子反应会越来越慢，这是一个需要体力去加班的行业，没有人能逃脱的了岁月的摧残，终究我们会被时代所淘汰，未来还是属于那些年轻人的，我们将何去何从，是选择通过惊人的自律来延长职业生涯，还是等到年纪不行的时候，放弃在第一线的工作而另谋出路，是每一个程序员都必经的选择。
同时这个行业有无止尽的工作与加班，你会丧失与妻子相聚，陪伴孩子，养育父母的时间，这些时间都是一去不复返，失去这些去换一份还不错的工作究竟值不值得，你从事程序员的目的是什么，你想通过你的职业得到什么，你所得到的与你所失去的是否值得，也是每一个程序员需要去权衡的问题。你做此行业的目的是什么？