有人用是十年年才能领悟一个道理，因为他们是被动领悟，只有在现实撞到他脸上的时候才感到疼，疼完了之后还是不记得时时提醒自己。所以，只有通过思考总结自己的经历，才能转化成经验，才算是一定意义上的成长。不知不觉已在优特工作一年有余，就自身微薄的成长总结一些心得体会，也算是对自己一个提醒。
1. 减少打扰别人的次数，延迟为别人服务以避免中断思考。
一个程序员桌上放了一个计数器，上面显示的26。有人问，你这个是记录的什么呀？改的bug数吗？程序员回答说「不是，这是今天被傻叉打扰的次数，说罢又往计数器按了一下」。当然这只是一个笑话，也不是在讽刺同事是傻叉或者自己是傻叉，毕竟总是难免遇到互相打扰的情况。每个人都有自己的节奏，这个节奏被打断之后可能感到受到冒犯，可能要非常困难才能恢复状态，可能真的耽误正事。尤其当自己沉浸在深度思考的时候被打扰是挺苦恼的事情，尽管如此亲身体会，自己也有时候也犯同样的错误。没有什么更重要的、对方不能拒绝的事情要去中断他，最好耐心等好时机。如此我作了一些调整，比如对发现的问题做个文档记录，等待时机再沟通，或者通过腾讯通、邮件等工具沟通等，后面再找时间协商解决，总之可以缓的事情先缓，当然要是突发情况必须解决除外。换过来，当别人打扰你的时候，先分析对方的问题是否紧急重要，若是非紧要的就先暂时礼貌拒绝：「我在思考一个问题，我晚点再答复你」，然后尽快把思绪跳回刚刚的位置上，因为你的思绪离开得越久就越难找回刚刚的定位。
2. 达成共识的沟通才算是有效沟通。
我是做前端开发的，前阵子跟后端开发的同时合作做一个功能，后来发现接口的逻辑不是讨论时候的那回事，然后找到这位同事沟通，他就说当时不是说那个逻辑不要了么，然后仔细沟通发现他说的「那个」跟我说的「那个」不是同一个东西。后来我总结出行之有效的方法套路：1）明确沟通的主题和目的，时刻注意停下来想想我们有没有偏离主题，不要把讨论会议开成了头脑风暴；2）按照我们团队的习惯，一般会提前给大家一个思考任务，各自做好准备，这样一碰免就可以直奔主题，省时省力；3）达成共识阶段，注意简单明确，少用模糊的词汇，一般可以尝试用你自己的话复述一次，让对方确定你理解了对方是意思，或者要求对方复述一次以便确认对方理解的和你所表达的是一致的，毕竟表达和吸收的环节都可能存在偏差。4）最好是以向领导汇报、文件记录等方式结束，进一步明确。最后一条，多简单的事都可以通过以上的步骤实现，只是实现的方式可以简化。
3. 公司雇你来是为其创造价值的，不是让你学习编程的
大多数程序员都有着比较强烈的学习欲望和好奇心，尤其是对待新技术新发现很容易就「沉迷学习不能自拔」，对于学生这是好事，但是可惜我们是员工。学习更直接的目的是提高工作效率，以更好地为公司创造利润，归根到底商业公司毕竟不是学校，公司雇你来是为其创造价值的，不是让你学习编程的，学完修够了学分就跳槽到下一个关卡这等美事还是回学校找吧。优先完成工作任务，然后才是你的增值时间。前段时间我在编写一个代码生成器，很容易犯代码洁癖的问题，总是想着怎么把代码写得更美更易读，小队长山胖哥就经常提醒我「你要记住你编写这个生成器的目的是为了更快的完成系统平台的优化任务，而不是要把他做成一个产品（来满足你学习编程的需求）」，括号的字是我自己加上的，其实就是这个意思，公司的需求（你的工作任务）总是有限于你的需求，遗忘了这个定律就容易出乱子。
4. 解决问题的核心思路。
- 你的问题是什么？开始的时候把问题描述清楚，大多数情况下就已经解决了一半的问题。忙着讨论、忙着调试、忙着查资料的时候，别忘了时不时停下来明确你的问题是什么，以免陷入时间黑洞、迷失在细节上。问题解决了一部分的时候，停下来想一想到这个时候问题又演化成什么问题，如此顺藤摸瓜、抽丝剥茧才能更高效更彻底地解决问题。
2）你为谁解决问题？这样问是为了确定服务对象，弄清楚解决问题是为了让谁满意。例如，有时候领导要我写测试用例文档，我就会问清楚这个文档以后是做什么用的，如果是内部程序员使用的话我会写得步骤相对简练抽象，更加偏向于逻辑判断上，如果是作为项目文档对外提供，那我就会写得更加详细易懂，更加注重词句的严谨性。
3）任何解决问题的方法都不可避免有副作用，但不要因此否定这个方案，副作用尚能接受那它是一个可行的解决办法。
5. 不要只专注自己的事，尝试一下纵观全局
你是在修建一座大厦，而不是在砌一面墙。要了解其他同事在干什么，知道整个项目的运作，从整体去认识这个项目，而不是总是盯着自己负责的那一部分功能，总是低着头去编码。于是，在工作汇报的会议上不像从前那样汇报完自己的工作后就走神了，现在开始也认真听别的队员的工作汇报，记录下他们的要点，有时候感兴趣的问题会在会议后讨论交流一，也经常会因为不了解而听得一头雾水，不过也是试图从整体上去理解这个项目，假设他们是来向我汇报工作的，我会怎么去思考，然后我的领导实际上又是怎么做的，或许会有不一样的发现。总之保持谦卑的心态，有机会就多学习，尝试从整体的角度观察项目，毕竟大多数程序员的瓶颈都在于代码之外的知识技能。
6.汇报工作，真的不是形式主义
我们的组长多次强调汇报工作的重要性，时不时也会批评我们有些工作汇报得不及时，我总结了一下汇报工作的时机：
1）做好工作计划时尽快汇报。这样可以避免大方向上出现问题，让领导了解计划内容，提出合理化建议或意见，避免你在工作开始后做无用功，不然一开始方向就完全偏离领导要求，做了也是白做。
2）工作有一定进展时汇报进度。这个其实因人而异，有的领导只关心结果，其他尽管放权，但我想大多数领导都喜欢随时掌控情况，以便适当调整计划。
3）工作中出现意外情况时立即汇报。否则延误时机，有可能损失惨重，切忌报喜不报忧的心态，出了事这锅就只能你自己背了。
4）可能越权的操作前请示领导。凡是自己权限以外的事情必须请示领导。因为一来我们表示对上级的尊重，二来我们自己不必承担不必要的责任。
5）任务完成后及时汇报。至少要把完成的情况说明清楚，更进一步的是把总结感悟也说一下。
