程序员的精益成长指南（二）
点击上方“做工程师不做码农”，并“置顶公众号”
第一时间接收精彩文章
如何学会时间管理？关于兴趣和投入、学习和工作你有什么困扰吗？故障处理最佳实践是什么样的？
时间管理
主动管理
告诉大家，我们什么时间段在做什么事，请大家不要打扰我;要求你的同事，重要的事情不要发微信而是邮件；做好信息管理。
学会说“不”
当你面对做不到的需求时，不要马上说做不到，你先想一下，给出另一种做得到的方案。
当你面对过于复杂的需求时，不说我不能完全满足你，但我说我可以部分满足你。
当你面对时间完全不够的需求时，你要想办法把这个压力还回去，或是让对方来和你一同分担压力。
给回三个选：
我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我1个月的时间还债。
我可以加班加点，还能保证质量，但我没办法完成这么多需求，能不能减少一点？
我可以保质保量地完成所有需求，但是，能不能多给我 2 周时间？
加班和开会
开会不是讨论问题，而是讨论方案，作为与会者，如果你发现没有提案，大家海了去了，那么你有两种选择
跳出来帮大家理一理
可以说一下：如果会上讨论不清，要不先线下讨论，有了方案再来评审
投资自己的时间
把时间花在正确的地方：
花时间学习基础知识，花时间读文档，不要把时间都浪费早查错上
花时间在解放自己的生产力的事上
花时间在让自己成长的事情上，晋升并不代表成长，成长不应该只看一个公司内，在行业内的成长才是真正的成长
花时间在建立高效的环境上，工欲善其事，必先利其器。
规划自己的时间
定义好优先级
最短作业优先
想清楚再做
关注长期利益规划
用好自己的时间
专注的把时间投入到有价值的事上，知道哪些是更有效的路径，是花时间改变别人，还是花时间去寻找志同道合的人。
形成习惯，如何将这些时间管理方法形成习惯？
形成正反馈，也就是成就感，这有助于你完成一些看似难以完成的事儿
反思和举一反三，复盘
“做”比“做好”更重要
识别表现和本质
关于兴趣和投入
兴趣是学习的助燃剂，对一件事有兴趣是是否愿意对这件事投入更多的前提条件
一方面，兴趣是需要保持的
另一方面，兴趣是可以培养的
对一件事情的兴趣只是表象，而内在更多的是你做这件事情的成就感是否可以持续。
关于学习和工作
学好一项技术和是否找到与之相匹配的工作有关联，但不是强关联，通过工作才让我们学习和成长的更快
工作中能为我们带来相应的场景和实际的问题，而不是空泛的学习
在工作中有同事和高手帮助，和他们的交互讨论可以让你更快的学习和成长
本质上来说，并不是只有找到了相应的工作我们才可以学好一项技术，有时间在工作中你反而学不到东西，工作提供的场景不够丰富，需要解决的实际问题太过简单，以及你的同事对你的帮助不大。
找工作不只是找到这个技术的工作，更是要找场景，找实际问题，找团队，这些才是本质。
不要完全把自己的学习寄托于找一份工作才会学的更好。
关于技术和价值
技术无贵贱，我们应该关注的是：
要用技术解决什么样的问题，场景非常重要
如何降低技术的学习成本，提高易用性，从而可以让技术更为普及
一项有价值的技术并不在于这项技术是否有技术含量，而是在于：
能否低成本高效率地解决实际问题
是不是众多产品的基础技术
是不是可以支持规模化的技术
对我们技术人来说，也可以找到相对应的技术点：
低成本高效率的解决问题的技术，一定是自动化的技术
基础技术总是枯燥和有价值的
支持规模化的技术也是很有价值的
关于趋势和未来
这个世界的技术趋势和未来其实是被人控制的，就是被那些有权有势的公司或国家来控制的。技术的未来要去哪里，主要是看这个世界的投入回到哪里，基本上就是这个世界上有钱有权有势的人把财富偷到哪个领域，也就是这个世界的大公司或大国们的规划。
对于我们这些人来说，只能默默的跟随这些大公司所引领的趋势和未来，能够做的也许只有两条路：
用更低的成本来提供和大公司相应的技术
在细分垂直市场上做得比大公司更专更精
故障处理最佳实践，故障改进
对于故障，复盘是一件非常重要的事情，因为我们的成长基本上就是从故障中总结各种经验教训从而能获得最大的提升。
亚马逊的复盘过程（COE文档）
故障处理的整个过程（log）,把故障从发生到解决的所有细节过程都记录下来。
故障原因分析，需要说明故障的原因和分析报告。
Ask 5 Whys，需要反思并至少 5 个为什么，并为这些“为什么”找到答案。
故障后续整个计划，需要对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。
然后这个文档要提交到高层管理层，向公司的VP级别进行汇报，并由他们来审查。
阿里的故障复盘会
把所有相关的人员都叫到现场进行复盘，这样的好处：一方面信息是透明的；另一方面也是对大家的一次教育。
确定故障等级和责任人，对于比较大的故障，责任人基本上都是由P9/M4的人来承担，并且会惩罚引发故障的直接工程师
为什么不要惩罚故障责任人？
首先，惩罚故障责任人对于解决故障完全没有任何帮助。因为他们之间没有因果关系，既不是充分条件也不是必要条件，更不是充要条件。这是逻辑上的错误。
其次，做的越多错的越多。会引发大家都学会保守，开始推诿，营造一种恐怖的气氛。
故障整改方法
亚马逊方法：更多的是通过技术手段来解决问题，几乎没有增加更复杂的流程或是把现有的系统复杂化。
阿里方法：会有一些复杂化问题的整改项，比如加入检查过程、审批环节、加入新的系统看着原来的系统。
整改方法的大致逻辑。
第一，优化故障获知和故障定位的时间。
从故障发生到我们知道的时间是否可以优化得更短？
定位故障的时间是否可以更短？
有哪些地方可以做到自动化？
第二，优化故障的处理方式。
故障处理时的判断和章法是否科学和正确？
故障处理时的信息是否安全透明？
故障处理时人员是否安排得当？
第三，优化开发过程中的问题。
Code Review 和测试中的问题和优化点
软件架构和设计是否可以更好？
对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
第四，优化团队能力。
如何提高团队的技术能力？
如何让团队有严谨的工程意识？
根除问的本质
问题的本质：
一个技术问题后面隐藏的是工程师的能力问题；
工程师的能力问题后面隐藏的是管理者的问题；
管理问题后面隐藏的是一个公司的文化问题；
公司的文化问题则隐藏着创始人的问题….
一些原则：
举一反三解决当下的故障。为自己赢得更多的时间。
简化复杂、不合理的技术架构、流程和组织。你不可能在一个复杂的环境下根本地解决问题。
全面改善和优化整个系统，包括组织。
全文完
访问带链接版请点击阅读原文
聚焦大前端技术和成长的公众号
关注我的公众号，第一时间接收原创、精选干货文章
点个在看少个 bug👇
▼阅读原文排版更精美