How to be Better

https://haseebq.com/10-principles-i-want-to-live-by/
7. Cultivate virtue—by force, if you have to.

You are a coward. You are fearful, you are lazy, you are selfish. Only once you know this can you begin the work of cultivating virtue.

You are principally what you do. So pledge. Show up. Keep coming back. And when you are too afraid to stay, sometimes you must lock yourself in the room and throw away the key.

9. Build your wings on the way down.

Be smart, be calculated, be careful. But when opportunity arises, steel your nerves and take the leap. If you don’t see any risks worth taking, you’re not paying attention.

It’s okay if you don’t know what you’re doing—trust that you’ll learn before you hit the floor. And if you crash: brush yourself off, forgive your errors, and try again. This is the only way progress has ever happened.

https://tech.meituan.com/10_principles_for_engineers.html

原则一：Owner意识

“Owner意识”主要体现在两个层面：一是认真负责的态度，二是积极主动的精神。

认真负责是工作的底线。首先，要对我们交付的结果负责。项目中每一个设计文档、每一行代码都需要认真完成，要对它的质量负责。如果设计文档逻辑混乱，代码没有注释，测试时发现一堆Bug，影响的不仅仅是RD的工程交付质量，还会对协同工作的RD、QA、PM等产生不好的影响。久而久之，团队的整体交付质量、工作效率也会逐步下降，甚至会导致团队成员之间产生不信任感。其次，我们要对开发的系统负责。系统的架构是否需要改进，接口文档是否完善，日志是否完整，数据库是否需要扩容，缓存空间够不够等等，这些都是需要落地的事情。作为系统Owner，请一定要认真履行。

积极主动是“Owner意识”更高一级的要求。RD每天要面对大量的工作，而且很多并不在计划内，这就需要具备一种积极主动的精神。例如我们每天可能会面对大量的技术咨询，如果客户提出的问题很长时间得不到回应的话，就会带来不好的客户体验。很多同学说忙于自己的工作没有时间处理，有同学觉得这件事不是很重要，也有很多同学是看到了，但是不知道怎么回答，更有甚者，看到了干脆装没看见。这些都是缺乏Owner意识的体现。正确的做法是积极主动地推动问题的解决，如果时间无法排开或者不知道如何解决，可以直接将问题反馈给能解决的同学。积极主动还可以表现在更多方面。比如很多同学会自发地梳理负责服务的现状，根据接口在性能方面暴露的问题提出改进意见并持续推动解决；也有同学在跨团队沟通中主动承担起主R的角色，积极发现问题、暴露问题，推动合作团队的进度，保证项目顺利推进。这些同学无一不是团队的中坚力量。所以，我们在做好自己份内工作的同时，也应该积极主动地投入到“份外”的工作中去。一分耕耘一分收获，不要给自己设限，努力成为一个更加优秀的人。

原则九：善于提问

“善于提问”，首先要勤于提问。求知欲源于好奇心，是人类的一种本能。在工作中要养成勤于提问的好习惯，不懂就问，不要因为自己一时懒惰或者碍于情面，就放弃提问的机会。当遇到不同的观点时，也要礼貌地问出来。波克定理告诉我们，只有在争辩中，才可能诞生最好的主意和最好的决定。

在设计评审、代码评审这类体现集体智慧的活动中，遇到有问题的地方一定要提出来。我经常看到，很多同学评审全程一言不发，这就是浪费大家的时间。设计评审的目的，是让大家针对方案提出改进意见并达成一致，如果全程“打酱油”，那就失去了评审的意义。我们鼓励大家多提问，把自己内心的疑惑表达出来，然后通过交流的方式得到答案。

“善于提问”，还要懂得如何提问。为什么同样是参加设计评审，有的同学就能提出很好的问题，而有的同学却提不出任何问题？除了知识储备、专业技能、经验等方面的差异外，还有一点很重要：批判性思维。

批判性思维主张通过批判性思考达到理性思维，即对事物本质的认知和掌握。关于如何进行批判性思维，大家可以参考一些经典的图书如《批判性思维》、《学会提问》等。在工作中面临一项决策时，会有各种各样的意见摆在你面前，所以我们必须要学会使用批判性思维来进行分析，每个人的论据是否可靠，论证是否合理，是否有隐含的立场。同样，在阅读一篇技术博客的时候，也要使用批判性的思维，多问几个为什么，作者得出的结论是否合理？论据是否充分？只有这样，才能不断地获取真正的知识。

原则七：设计优先

“设计优先”这条原则，相对来说更加具体一些。之所以单列一项，是因为架构设计太重要了。Uncle Bob曾说过：“软件架构的目标，是为了让构建与维护系统的所需人力资源最小化。”

架构设计，并不仅仅关系到系统的质量，还关乎团队的效能问题。很多团队也有明文规定，开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。在具体的执行过程中，由于各种原因，设计往往并不能达到预期的效果。究其原因，有的是因为项目周期紧，来不及设计得足够详细；有的是因为RD主观上认为项目比较简单，设计草草了事。无数事实证明，忽略了前期设计，往往会导致后续开发周期被大幅拉长，给项目带来了很大的Delay风险。而且最可怕的是，不当的设计会给项目带来巨大的后期维护成本，我们不得不腾出时间，专门进行项目的优化与重构。因此，无论什么时候都要记住“设计优先”这一原则。磨刀不误砍柴工，前期良好的设计，会给项目开发以及后期维护带来极大的收益。

“设计优先”这一原则，要求写别人看得懂的设计。我们了解一个系统最直接的途径就是结合设计文档与代码。在实际工作中，很多同学的设计文档让大家看得一头雾水，通篇下来，看不出系统整体的设计思路。其实，设计的过程是一种智力上的创造，我们更希望它能成为个人与集体智慧的结晶。如何才能让我们的设计变得通俗易懂？我个人认为，设计应该尽量使用比较合理的逻辑，进而把设计中的一些点组织起来。比如可以使用从抽象到具体，由总到分的结构来组织材料。在设计过程中，要以需求为出发点，通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。做完设计之后，可以发给比较资深的RD或者PM审阅一下，根据他们的反馈再进行完善。好的设计，一定是逻辑清晰易懂、细节落地可执行的。

原则六：事不过二

“事不过二”，是我们团队一贯坚持的原则，它可以解读为两层含义。

一层含义是“所有的评审与问题讨论，不要超过两次”。之所以有这样的要求，是因为我们发现，很多RD都把时间花费在一些无休止的评审与问题讨论中，真正投入到实际开发中的时间反而很少。在实际工作场景中，我们经常会遇到一些不是很成熟的需求评审。这些需求文档，要么是背景与目标含糊不清，要么是产品方案描述不够细化，或者存在歧义。RD与PM被迫反复进行讨论，我曾经遇到过一个需求评审，进行了三次还被打回。同样的问题，在设计评审中也屡见不鲜。方案固然需要经过反复的讨论，但是如果迟迟不能达成一致，就会耗费很多RD与PM的宝贵时间，这就与提升研发效率的理念背道而驰。因此，我们团队规定：所有的评审最多两次。通过这种方式，倒逼利益相关方尽可能地做好需求与方案设计。评审会议组织前，尝试与所有相关人员达成一致，询问对方的意见，并进行有针对性的讨论，这样能够大大提升评审会议的效率和质量。如果在第一次评审中不通过，那么就只有一次机会进行复审。一旦两次不通过，就需要进行Casestudy。

“事不过二”原则的另一层含义，是“同样的错误不能犯第二次”。每次故障之后，Casestudy都必须进行深刻的总结复盘，对故障原因进行5Why分析，给出明确可执行的To Do List。每次季度总结会，大家自我反省问题所在，在下个季度必须有所改善，不能再犯类似的错误。孔子云：“不迁怒，不贰过”，在错误中反思与成长，才能让我们成为更优秀的人。

原则四：闭环思维

你是否遇到过这样的场景：参加了一个设计（或需求）评审，大家兴致勃勃地提了很多合理的意见，等到再次评审的时候，却发现第一次提的很多问题都没有得到改进，很多讨论过的问题需要从头再开始讨论。这种情况就是一种典型的工作不闭环。

之前看过一句话：一个人是否靠谱，就看他能否做到凡事有交代，件件有着落，事事有回音。这就是闭环思维的重要性。它强调的是一种即时反馈闭环，如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的时间内给出明确的反馈。例如在跨部门的沟通会议中，虽然各方达成了一致，会议发起者已经将最终的记录周知大家。但是，到这一步其实并没有完成真正的闭环，在落地执行过程中很可能还存在一些潜在的问题。例如，会议纪要是否经各方仔细核对并确认过？会议中明确的To Do进展是什么？完成结果有没有Check的机制？如果这些没有做到的话，就会陷入“沟通-发现问题-再沟通-再发现问题”的恶性循环中。真正的闭环，要求我们对工作中的事情都能够养成良好的思维习惯，沟通要有结论，通知要有反馈，To Do要有验收。

“闭环思维”还要求能够定期主动进行阶段性的反馈。刚参加工作时，我接了一个工期为两个月的项目。整个项目需要独自完成，自己每天按照计划，有条不紊地进行开发。大概过了两周之后，Leader询问项目进度，虽然我已经跟他说没问题。然而，Leader告诉我，因为我每天对着电脑也不说话，让他心里很没底。这时，我才意识到一个很重要的问题，我跟Leader之间存在信息不对称。从那以后，我就时不时得跟他汇报一下进度，哪怕就只有简短的一句话，也可以明显感觉，他对我的信心增加了很多。特别是我做Leader之后，对这种闭环反馈的理解，就更加深刻了。从Leader的角度看，其实只是想知道项目是否在正常推进，是否遇到问题需要他协助解决。