简介
日常记录，年终汇总为文章
学习并不是追求更多的知识，而是要寻找更好的决策依据。
在刚毕业的时候，讲收获说的都是学了什么新东西/技术，去了什么地方。在2020年，无论是技术还是生活， 更多是寻求突破/颠覆/打碎三观。因为人到一定程度，百利无一害的事情几乎没有了，花几天时间学习一个新技术在刚毕业是一个绝对正确的事情，但工作之后这样做可能牺牲了家庭生活/个性发展的时间。 这个时候，要求人更深刻，面对一件事，粗略的判断有利还是有害是不够的， 你甚至要给这件事精确到十分制的判断，个别事情要百分制的判断， 你必须判断出来 这件事是6分，那件事是5分，然后决定先做哪一件，以多大的决心做哪一件事（有时候判断事情更有价值，但不去做或投入不够，跟没有做出判断是一样的）。亦或者有一种淡然，为一种选择（意外着另一个放弃）承担后果。 更深刻，要求你更多的体验，也就是更多的行动/尝试，这样才会对生活有更真实的感受。
The master has failed more times than the beginner has tried.
沟通
2020.9.19：沟通先不谈别的，你自己得愿意先把你的想法，有意识的、潜意识的想法先告诉大家，都告诉大家，而不是啥都没说，就开始抱怨大家不理解你。 cpu 要想快，就得加大缓存，多cpu 协作的快，就得加大L3 共享缓存，你首先得把自己的 想法（Target、Why、When、Who、How）都先摆出来。这种沟通要有落地办法：晨会、日报等。就像我写的这篇博客，内心戏这么多，却没有直接说给小伙伴听。
沟通的本质是扩大共识 ==> 重要的是先观察对方的认知和想法
单纯的挣扎于某个具体问题，缺乏对事情的高层次认知，想不到/做不到从具体问题提炼共性问题，摸索共性方案进而解决具体问题。
核心竞争力 一开始是解决事儿，再后面是解决人，最后是向下兼容的能力
为什么程序员普遍不喜欢交流？工作被打断严重影响效率；交流不能直接帮程序员完成工作。网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。交流的好处可以从两个方面来说，一个是输入，一个是输出。
- 输入。在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
- 输出。现在已经不是一个酒香不怕巷子深的时代了。不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。
人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收（而不是努力的想把自己的想法表达出来，表达show自己，自己说爽了就行了）。所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。
我们不能玩霸道总裁向，不能说“我不要你觉得，我要我觉得”。而是要玩霸道码农向，要说“我不要我觉得，我要你觉得”。快给我觉，我说的这个怎么样，有没有感觉，这个 feel 对不对。不对我们继续聊。
当每个人的观点有冲突时，光凭直觉、猜测、经验都无法让对方信服。
这一年中，经常跟小伙伴A有争执。因为年龄差不多，两人一开始也是平级，A平时喜欢沉浸到技术中，不太乐于主动沟通。确定性比较大的事情还好，做探索性、模糊性的事情时 工作内容很少与身边人同步，经常导致返工（方案没有经过充分讨论），以及大量时间花在业务价值不高的事情上，极客思维过重，动辄想改个源码或者新做个系统。在多次争执之后，约束太多会导致他抗拒心理非常强，收效甚微。现在计划每周定一个固定时间例会，各自表述最近一周的研究和进展，对待做的事情做出充分讨论， 把方案汇报变成小组讨论，并且是固定形式的，减少出现遗漏的情况。PS：你的管理风格是否能容这个错，你的架构设计是否能容这个错？
对事儿不对人，多定量少定性。大部分沟通问题，都是你提前走了定性，进而产生悲观、失望情绪，放弃日拱一卒，最后宁愿换人，也不愿从小事慢慢做好。
弱沟通最大的敌人，就是那些不假思索就说出来的话，当你不去控制自己的语言和情绪时，是绝对无法达到最初的沟通目的的。另外，很重要的一点就是学会示弱。示弱有助于解决冲突，示弱并不代表你没有勇气，而是一种沟通的策略。什么是示弱？比如，经常有人不经意间透露自己一年能挣了多少钱云云，你会怎么做呢？你可以说我比你挣的多多了。也可说二爷挣的比你多多了，并且二爷从来不说。还可以说，二爷不仅挣钱多还比你会弹琴呢。说这些的时候，二爷是谁，认不认识，并不重要，重要的是有人比对方更强。这样的回复都不是示弱，是对抗。你不让我开心，那我们都不开心比较好。更好的做法什么？真诚的赞美对方，顺便了解一下人家赚钱的道理，对方开心了，你也有收获，关系还可能更进一步。
《关键对话》这本书提出的一个对话关键，就是一定要让双方都有心理安全感。哪怕你觉得这个人差到不行，你也得在他身上找到一个值得尊重的地方，否则这个话就没法谈。一旦有一方失去安全感，进入防守反击的状态，肯定谈崩。 我们谈话的目的从来都不应该是为了赢得什么争论，我们的目的是为了让这个人按我们的想法去把事儿办了，是为了赢得这个人！把一个希拉里的支持者给气哭了不算本事，你能说服她去给特朗普投票，这才算本事！
上下沟通
一个事情2天干完是惊喜，4天干完是完成任务， 一周干完是能力一般，一周干完还到处漏水 不能留。
有的人不喜欢折腾代码，你非得让他一直重构，来回三四遍整的双方都很累，是不是一定要坚持呢？这个时候只能说卡死上下游， 控制影响范围。他可以做出选择，也必须接受结果。
什么是灵性？
- 知乎一个回答：灵性是一种感受力，对眼睛看不到的事物的一种感受力。是一种悟性，一种表达能力。越有灵性的人越会关注和周围现实世界无关的东西，越不会只关注菜价或明星八卦。
- 我自己的想法：很多人对身边发生了什么未知未觉
- 一leader 想法：灵性是举一反三的能力
- 一leader 想法：你问他问题，问一个说一个，绝不多说的那种，一般灵性都不太够。PS：很多人可以把一个复杂的问题回答的很简单，其实都是些很正确但没用的话。
协作方沟通
搞明白自己怎么想的/立场/决心，更要搞明白对方怎么想的/立场/决心。
- 诉求完全相反
- 诉求有一点重合，有一点相反
- 诉求大体一致
做事要想明白，还要想的深刻，还要有很大决心，光想明白没有决心是不够的。
当协作方提出过高要求的时候，摆出困难、成本、摆出已有的安排、要求业务方需求打个折，大部分时候都是可以收获一定的理解的。但直接拒绝，或者拒绝沟通，对方就要跳起来了。
你和一个经历、性格、岗位完全不同的人如何达成一致？
- 数据思维，真正的数据思维，信数据，不偏执自己的想法。也可以减少与别人的争论，尽早达成一致
- 谁更能优先提出建设性的意见，而不是单纯的抱怨、指责或看不上。
向上沟通
你一定要让领导做选择题，而不是问答题、论述题。领导交给你的任何问题，你一定要有自己的想法，并且基于自己的思路提供一个或者多个可行的解决方案，并且需要知道每个方案的优缺点，并基于自己的判断在这多个方案中有一个自己认为最好的方案。跟领导汇报时，需要带着方案去汇报，而不是直接找领导讨论。
多做反馈，也能够更好地体现工作的积极性，代表你是在认认真真工作和思考的。多跟领导反馈，也让领导对你有更深刻的印象，更容易形成比较好的上下级关系。当领导遇到问题时也更愿意找这些积极主动的员工来帮忙处理，你可以得到更多的历练和成长。可以说，及时恰当反馈对员工是百利而无一害的。
职场中最忌讳的是沉默寡言，不做任何向上反馈。千万要记住，不要等着领导来找你。一旦领导过来找你，很可能不是什么好事，要么是工作中你出了什么问题，要么是领导想知道你最近在干啥，这可能都不是好的现象。
和产品沟通
一个架构师的感悟作为技术人员我们已经习惯于给出设计方案，总是做一个问答题的解决者。而很少思考设计什么，做一个问题的提出者。团队中常见典型矛盾的就是产品团队和研发团队的矛盾。作为研发团队，我们常吐槽产品团队的需求不合理的时候，不懂技术等。其实我们可以试想把自己的工作再往前移一下，不仅仅是去设计架构实现产品的需求，而是去实现客户的需求，甚至发现潜在的需求。这时我们就变成了在设计上提出问题的人，你会发现其实提出问题，很多时候需要同样深入的思考。设计一个好的问题，甚至比解决问题更难。
组织
不要为某个人烦恼，从流程上、分工上、组织上标准化、数据化、规范化，让强的有发挥空间，弱的拖不了后腿。
不同角色工作上真正的差异是上下文的不同。你和你职业台阶中的上一级那个人，差异到底是什么？也许你会说，他比我来的时间长，或者说，他每天的主要工作就是开会。如果真的是这样，那是不是只要你凑足这个条件，就可以到达他的位置呢？显然不是。你在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。有的问题解决靠技术，有的问题解决靠对需求的理解。在一个特定的产品设计下，我总觉得设计的技术方案有些不优雅的地方，而只要产品设计微调一下，技术方案一下子就会得到大幅度提升。在这种情况下，我会先去问产品经理，是否可以这样调整。只要不是至关重要的地方，产品经理通常会答应我的要求。为什么你的工作总能让老板挑出毛病？没错，工作的上下文不同，看到的维度差异很大。单一维度的思考，在多维度思考者的眼里几乎就是漏洞百出的。为人做事同样要不断扩展自己的上下文，这也就是我们常说的涨见识。
团队维护的成本除了实打实的薪资支出，还有文化建设成本。工程师们都号称需要宽容自由的环境，形式上看就像是花钱请了一群野马，这也是成本，或者说风险。因为真正优秀的工程师才会在宽松环境下创造出远大于成本的价值，而普通工程师有可能在宽松自由的环境下逐渐废掉。给团队维护一个宽松自由的环境，就需要有一些非常明确地验收工程师成果的机制，这种技术文化建设也不是一朝一夕的事情，需要付出很大的精力。
作为技术团队，对候选人的智商考察，是很重要的。技术工作有一定的智商门槛。这里强调一下，做技术工作，不是智商越高越好，而是过了门槛就好。到了实际工作里，只要智商达到一定水平，具体的工作贡献，和个人的情商、动机关联更高。工作做的更好、发展更快的，往往是那些情商更高的人。
- 我们遇到的每一个问题都不是小问题，只要没有被提出和解决，就有可能反复出现，消耗我们的精力。
- leader的很大一部分任务就是理清事情，排列优先级，让自己的手下去做事情。程序员能控制的就是如何安排和使用自己的时间，而leader要对手下所有人的时间负责。
管理
管理学本身的目的之一就是要抑制不确定性，产生确定性。对管理者最基本的要求，是对目标的承诺。你能够承诺多大的目标，你的岗位就有多大的价值。
管理是通过他人完成任务的艺术。正因为如此，有些成熟公司如京东就有规定，如果你没有培养出可以完全顶替你位置的人，你是不能晋升的。
先管，向管理要效益（组织调整，提高人才密度；加强协同；激发团队活力）；然后慢慢不管，团队自律、自驱，管理逐步达到无为状态。PS：做管理挣100w比做技术挣100w容易，为什么？因为管理工作也是有效益的。
- 管理的本质——是通过别人拿到结果。要了解每个人优缺点；要了解团队中每个人，他们的需求不一样，他们的性格不一样，所以定期和下属的1对1沟通是必不可少的；要关注下属的八卦，要了解他们的动态，还得擅长从他们的日常工作、朋友圈，洞察他们遇到什么困难、或者开心的事，好的管理者一定要八卦。因为这样你才知道下属的情绪或工作之外的事，那安排工作或者下属表现异常的时候，你就可以做相应的调整。
- 我们做程序员也好，产品经理也罢，我们处理的事都是确定性问题。比如，程序员按产品经理的需求，排期开发并上线；产品经理根据自己老大布置任务完成各种产品工作（产品调研、竞品分析、需求设计、写PRD、数据分析等等）。但是当你成为一位管理者， 情况就变了。沟通的本质就是把不确定性问题变成确定性问题。所以，很多管理者看起来写的代码少了，但工作压力依然很大。如果你对不确定性的事害怕，你可能就不太适合。
- 我觉得还有一个点特别重要——那就是你得有一个独特优势。如果你是程序员，这可能是产品思维，也可能是项目管理能力，也可能向上管理能力等；如果你是产品经理，把上面的产品思维换成技术思维，其他雷同。
技术管理是什么？
- 不单是你技术很牛，什么都想到办法，自己或小伙伴去实施。系统也不是 走的通就结束了，实验室环境走的通 跟给成千上百个从未用过的人 用是两个事情。
- 在很多事情都不是你具体做的情况下，如何保证质量（也就是通过他人拿到成果）？ 如何让用户满意？（比如一个问题不重复出现）。如何给人 人靠谱、团队靠谱的体验？
- 如何制定规则？ 比如客服工作一定要记录，哪些事情一定要文档化。团队如何起到 1+1>2 的效果？
- 小组日常的分享、分工？如何培养和小伙伴的亲近感？为什么有的小伙伴会出现产出与实力不匹配？ 一个事情，如何明确你和小伙伴的定位，以及不越界，避免出现你没事，小伙伴压力太大。或者你事情太多，小伙伴却缺乏历练的情况。
- 代码 = 控制 + 业务逻辑。管理 也有“控制”和“业务逻辑”，如何提高“控制”的效率，减少协作部分的损耗，让小伙伴专注于业务逻辑？如何精力可以集中在真正重要的事儿上？比如有了云效，分支分支管理就可以规范化。建立机制、系统、平台，削弱对个人素质、主观能动性、沟通能力的依赖。
没有指数级扩张，技术管理机会越来越少。
领导力可以细分为三种能力
- 战略规划能力，解决方向问题
- 判断抉择能力，解决路线问题
- 原则方针的制定能力，解决操作实施的问题
至于用人、乐观、鼓舞士气等本质上是上述三种能力的外在表现，比如乐观，如果没有正确的方向和路线，乐观也有可能是盲目乐观，从而产生出冒险主义。同理，悲观的人如果有了正确的方向，有了付诸实践的方法， 也有可能变得乐观起来。如果领导每次决策都出错，慢慢的大家也就不相信他了，就别提什么鼓舞士气了。
激发团队活力
你所有的不适，就是想把小伙伴变成你想要的样子（他也想要有自己的发挥空间），而不是让他们成为他们想要的样子，并以这个出发点做出安排和规划。这样小伙伴的想象空间才能最大化，团队才能自驱。PS： 如果你让一个人提高效率， 他投入更多时间就可以；如果是一个小组提高效率，小组长多辛苦一点也勉强可以；如果你给一个老板、总监说让提高效率，你让他怎么办？想到的一个办法是，找到低效的地方，减少低效，但他很难告诉所有人高效是什么样子。对于一个小组长来说，理想状态是什么
- 一切按自己想法来，其它人是 分身，做一些简单的事情
- 每个人按自己想法来，仅以目标和结果作为边界来约束。
管理的难点在哪？如果把一切都定好，都按你的想法来，那就是死气沉沉（从管理者视角出发的管理技巧 在被管理者看来都是反人性的，优秀的管理都是自下而上的）。如果不管不问，那事情很有可能跑偏了。一管就死，一放就乱。
人与人之间相互信任，不一定意味着他们彼此喜欢对方，而是意味着彼此了解。因此，人们绝对有必要对自己的人际关系负责。
先让别人干，自己晚点跟进下就好了，不要在最开始就介入
分析任何问题都要有系统化思维。比如阿里将人分为四种。李智慧将人分为
| 新手 | |
| 高级新手 | 高级新手不觉得自己是高级新手，碰到新问题，要么束手无策，要么老办法解决新问题 |
| 胜任者 | 主动性 在遇到新问题时，会积极寻求新的解决方案去解决问题 |
| 精通者 | 自我改进 反思精神以及全局思维：为什么会出现这样的问题？如何避免类似问题再发生？这个问题在更宏大的背景下处于什么位置？还有哪些类似的问题？ 工作中最重要的不是规则，而是对场景的理解 |
| 专家 | 专家把过往的经验都融汇贯通，然后形成一种直觉，然后用最直接、最简单的方法把问题解决 |
鱼是最后一个看到水的：问题 = 期望 - 体验。
- 很多小伙伴他倒是很努力在憋设计和代码，但还是看的东西太少，对“期望/理想状态” 缺乏想象力，只能想到基于已经会的技术最好能达到什么效果。容易被现状所限制，每一次的加需求，都是在“理想状态/假设一行代码都没写的视角” 重新审视系统。
- “如果做事想让你的领导满意，就必须以高两个层级的视角来看待和思考现在的工作，并作出行动”。视角越高，“期望”越大，就越能发现问题。
一线技术管理新人的困扰
- 当爹又当妈。培养骨干顶上来，以便聚焦自己的事情。
- 自己做到 90，还是让组员做到 70 分？定目标给方法，定期检查做指导，结束做复盘。
技术管理的价值：
- 事儿的产出：要比小伙伴看得更高更远，梳理业务需求和技术方案选型
- 人的成长：制定踮脚就可以实现的目标，并进行复盘（扶上马，送一程）
很多事情，甚至包括codereview、设计review 你不一定需要自己做，但要确保有人做，确保有人有时间做。每个人的工作时间可以说是leader掌握的最有价值的资源了。培养人才和为公司创造价值这俩目标，都需要用到组员的工作时间。PS：下文 “商业设计和组织设计是一号位不可推卸的责任”，作为leader，至少要想好一个月的计划，如果不清晰就时时刻刻琢磨想清晰，并根据实际合理调整。让小伙伴知道近一个月的事情，才能找到工作节奏，才能知道今晚该不该走的晚一点。
人最持久的动力一定是从自己做过的事情上得到的，而不是来自于外界，所以我们更多是帮助小伙伴找到这件事，做成这件事。PS：比如说我想说服小伙伴要交流， 我们在为一个feature 非常烦恼的时候，我实地找了下需求方，需求方说我们纠结的feature他们用不上。我们之前为难的时间越久， 小伙伴的体悟就越深刻。 让他体会到正反 两个实践的经验教训。
适当的放权，让团队人员不是负责执行一些事情，而是对某一块业务具备完全的决定权，也就是说，让他们去主导一些事情。这样员工会认为自己对项目有完整的所有权，进而具备责任心。在这个基础上，根据每个人的不同情况，在执行过程中适度跟进。发现问题的时候，及时指出来，但这时需要注意的是，管理者要用关心的口吻，而不是追究的态度，让对方了解到问题出在哪里。多花时间，让对方自己认识到问题所在，而不是把你的主观感觉强加于人，用引导的方式，会更好地激发团队的责任心。不要变成一个微观管理者，也不要成为一个纯粹的规则执行者。
如果一个人给你的反馈 80% 是正面的，另外 20% 是负面的，人的潜意识会接受这个比例，不会产生 “这个人为什么总是挑我刺儿” 的感觉。
我经常很生气的一件事就是对方不满足我的期望，但首先一个问题是：你是否对对方有不切实际的期望。
业务理解
毛主席曾在七大做结论的时候这样说：“什么叫做领导？领导和预见有什么关系？预见就是预先看到前途趋向。如果没有预见，叫不叫领导？我说不叫领导。斯大林说：没有预见就不叫领导，为着领导必须预见。整个人类在马克思主义产生以前对于社会的发展历来没有预见，或者没有很清楚的预见。”换句话说，所谓的领导力，其根本能力就是预见能力。如何锻炼自己的领导能力，根本在于培养自己的预见能力。
- 不管事物处于何种阶段，必须计算到往后会出现哪些阶段，至少也应该计算到下一个阶段——《中国革命战争的战略问题》。在战略方向上，摸着石头过河是不行的。
- 杜绝盲目性，找出事物的内部矛盾。任何事物的发展，尤其内部的规定、外部条件创建。如果要对事物作出预见，那么本质就是分析它的内部矛盾，以及可能出现的外部条件。
- 没有调查就没有发言权。任何一件事情，如果对它的历史和现状没有搞清楚，那你针对这件事作出的任何判断和决策都不可能是实事求是的。
我看技术人的成长路径为什么优秀的业务开发人员一定要有“想法”？如果没有想法，基本上就是产品经理安排什么，然后就做什么，不会考虑未来的发展，也不能很好的培养你的业务敏锐度，更加不会有前瞻性。什么是前瞻性，就是你思考的东西和业务真正发展的路径其实是一致的，那么就是有很好前瞻性。如果你思考的东西和业务发展背道而驰，那其实不叫前瞻性。另外我们在做业务的时候，业务沉淀是非常重要的。阿里有句土话说，“规模可复制的结果才是好的结果”，你做的东西能不能影响更多的人，就看你的业务沉淀如何，如果你做的东西一年后经过几次改版都消失不见了，那其实没有什么沉淀。
试图用自己擅长的技术去解决所有问题，就是手握锤子去寻找钉子。始终坚持从问题场景本身出发，探索适合的、简单直接的的技术方案。
组织协同
领导力的核心其实是沟通，通过沟通建立信任，从而来引领别人一起去达成目标。这个图叫做乔哈里视窗，也叫沟通视窗，本质是一种关于沟通的技巧和理论
- 我们应该不断的从别的象限拿出一点东西然后放到公开象限里面去，让公开象限放大，这样你的领导力就提升了，比如国家领导人和明星，他们的公开象限就非常大。
- 隐私象限：隐私象限就是自己知道但是他人不知道，把隐私象限往公开象限里面挪动最重要的方式就是自我揭示。
- 盲点象限：盲点象限就是自己不知道但是他人知道，把盲点象限往公开象限里面挪动最重要的方式是恳请反馈。
- 潜能象限：大家都说人的潜能是无限的，我们应该去挖掘他。
技术经理常犯哪些错误？
- 做事还是喜欢个人英雄主义，把事情都压在自己的头上，弄得自己很累，下属又得不到成长。
- 业务能力不足，在和业务方 PK 时，无法站在业务的角度去思考问题，认为业务方的需求大部分就是扯淡。PS：业务方的需求或许是扯淡，但多少也指明了系统发力的方向
- 要敢于对产品经理提的伪需求，各种临时方案，各种想不清楚的产品方案说不，说不，说不不不！
- 对待不同的下属会用不同方法。例如，有的责任心很强，但是技术能力不行，有的技术能强，但是做事容易马虎大意，都可以找到相应的办法帮他们改掉陋习，提升下属的能力。
从运维到技术运营的 14 年修炼之路2010 年随着国内云计算的起步，我接受了更感兴趣的运维管理工作，与用友的前沿团队一起实现 IaaS、PaaS 平台的投产运行。我遇到了另一位良师益友，他让我感受强执行力已经不能带动团队快速前进，更需要的是广阔的专业知识、自驱力的强大、充分的信任、业务的体系与格局。我要从基层程序员的纯编程角度上升到更高维度，从写好代码到思考客户真正的需求，甚至从公司成本等多角度地开始思考业务背后的意义。
管理岗一般是不做具体工作的。换句话说，管理岗除了具体的事情，所有的别的事情都要管。经理每天的工作都可以说是在救火。人永远不够用，事情永远都很急，技术债务也在一天天成为发展的掣肘，线上生产问题还会时不时的凑个热闹。经理要组织协调各种资源，在有限的人和有限的预算内，把事情安排到内外各方都能接受甚至满意。
不知道你有没有发现，阻碍一个人写出一个程序库的，往往是第一步：能想到的程序库，别人都写了，再造一个轮子意义并不大。这种思路往往是站在理解结果的角度。其实，程序库和所有的应用一样，都是从一个要解决的问题出发。所以，在日常的繁忙工作中，我们需要偶尔抬头，想想哪些问题正困扰着我们，也许这就是一个程序库或者一个工具的出发点。阻碍一个程序员写出好的程序库的原因，往往是没有找到一个好问题去解决。程序员不能只当一个问题的解决者，还应该经常抬头看路，做一个问题的发现者。
很多产品经理常犯的错误是，自己做出所有的决定，和工程师交流时只是要求他们按照指定要求来做，但实际上有些要求根本就不切实际。一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因，让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。 这样，很多的小决定完全可以让团队成员自己做，从而既可以大大提高产品效率，又可以提高团队成员的能动性。当然，这并不是说产品经理什么决定也不用做，一个优秀的产品经理，会确保自己的时间花在“非我不可”的事情上，如果一个产品经理把每天的时间都花在解决按钮是 100 像素还是 120 像素这种问题上，他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。PS：想起了雷军漏出手机壁纸：能不管就不管
作为一个有经验的开发来说， 单纯某个技术的学习 对我慢慢没有挑战性和吸引力，并且也有小伙伴给我分担具体的事务，那我的精力投向哪里？成长体现在哪里呢？
- 你就把这4人小团队搞的有声有色就不容易。
- 一定要带出来小伙伴 挡一下。
- 最近api 系统、容器报警系统的推进上和小伙伴有了争执，一些决策小伙伴很不以为然。说白了，还是相关领域的知识储备、思考研究不足造成的，只会反驳，但提不出有建设性的意见和方法来。一定要重视调查研究，不能偷懒，要全面熟悉业界的已有实现，对不熟悉的组件要有感觉性的认识。API文档、API调试、API mock、API自动化测试全搞定
- 尽管技术经理不必是团队中能力最出众的开发人员，但至少他们应该对相关技术有所了解。当团队成员向老板提出技术建议时，技术经理应该能够针对这些建议提供有价值的反馈。PS：一个管理人员每天要关注的：事情停滞在哪里，有哪些决定要做？哪些事情可以先让子弹飞一会儿。
- 小组长必须要能指明工作方向（尤其项目陷入停滞中时），要能规划一个月季度、月、周、日的工作内容，必须能把工作拆解到 小伙伴能力可以 接受的范畴
很多时候，不要抱怨，你给他们做成过一次。
如果流程就能解决问题，那还需要经理干什么呢？要提高组织效率，不脱两层皮付出点代价是不可能的。我们真正的难点在于怎么用人，怎么拿捏流程不能处理的意外情况。
霍泰稳：在团队管理中，我把“基石”定义为一个项目或者产品甚至一个团队的核心，也就是决定事情能不能成的关键要素之一。有它在，事情就已经到了 60 及格分，然后我们每个人只需要在这个及格线之上继续努力，发挥自己的特长和特色，就可以把事情做到 85 甚至 100 的优秀分。对于我来说，通过“基石观”，我可以不用在大多数基础的事情上操心，只要工作是不低于这个标准进行的，那么公司就不会出乱子，就能够每日精进，最终螺旋式上升。基石思维对于团队成员也有很多好处。因为有了对齐的标准，他们也就有了清晰的奋斗方向，知道事情这样做，是和公司的要求一致的，从而也有了很好的安全感。而在完成基本要求的基础上，他们也可以拥有很大的自主权，可以充分发挥自己的主观能动性，把更多新的想法注入到工作中，带来更多创新的源泉。
摘抄：如果一个公司的组织架构已经基本成型了，那么基本上设计出的系统架构和其人员组织架构必然是一致的。之前和同事一起得到了一个在大公司内推进事情的靠谱结论，如果一件事情在一个部门内就可以解决，那可以开开心心地推动它解决。如果一件事情需要跨部门，那还需要本部门的大领导出面才能解决，哪怕这事情再小。如果一件事情需要跨两个部门，那就没治了，谁出面都不行。这种事情做不了的。而如果一件事情和你要跨的部门 KPI 有冲突，那就更别想了，把部门重组了才能解决，这是 CTO 才能干的事情。
精
不要总是解决同样的问题，不要是总是回答同样的问题。多写文档。
收敛精力：java 只管设计不介入，容器化好好搞一下。
所谓的算法优化，其实就是尽可能利用已知的信息，少做不必要的事。插入排序并不会因为干的活多，就比快速排序得到更高的评价，因为它们比的是谁排得快。工作效率高，不是因为代码写得多，而是有效工作做得多。做本质复杂度（Essential Complexity）的事情，少做无意义的事情。怎么才能有效工作呢？
- 拓展自己的上下文，看到真正的目标，更好地对准靶子，比如，多了解用户，才不至于做错了方向；站在公司的层面上，才知道哪个任务优先级更高；站在行业的角度，而不局限于只在公司内成为高手，等等。
- 去掉不必要的内容，减少浪费，比如，花时间分析需求，不做非必要的功能；花时间做好领域设计，别围着特定技术打转；花时间做好自动化，把精力集中在编码上，等等。
充分利用工具的效能，化主动为被动，化计划外为计划内。比如钉钉提醒大家发日报周报、钉钉的自动回复、微信读书的零散划线笔记再集中汇总到博客上。
- 我还是挺喜欢一万小时这个法则的，不管这个社会怎么变化，人接受知识并转化为自己的智慧的能力没有本质的提升，仍然还是需要大量的学习、练习、反思，才能最终成为一个靠谱的人。在一个领域积累的时间长了，最终会迎来一个或者多个爆发点的，因为在中国，不仅仅是互联网行业，各行业都极度缺乏高级人才。
- 如果一个人有这种创业的心态，那他就自然的站在了一个更高的角度来看问题，相对容易能够看出事情的优先级和各种问题的真正原因，也就更有可能知道怎样推进事情才是更合理的。
技术人如何自我成长？工作上不可能所有的事情都能按自己的期望来，或多或少总会有一些大家理解的“杂活”、“苦力活”，在一个项目或一段合作中，不妨多问问自己希望被别人记住什么？然后赋予这段工作意义。我记得去年女排世界杯的时候，记者采访郎平，她提到每个人发球要有“使命感”，赋予每一次发球意义，大致意思是：不能说自己怕失误就保守，所以每个人都要去冲击对手。
一切兼有章法，只要肯用心、肯下苦功夫，敢于在思想上艰苦奋斗，我相信就一定会有大的收获。
而我们始终要记得工作中我们做很多的事情，最终发现留下来的不是事情本身，而是我们在做事情时候留给别人的印象，别人打给自己的标签
永远不要”屁股决定脑袋”。这里我想表达两层意思，一层是我们需要“进化”，需要不断的发现和感知世界的变化，更快的适应变化，有时候你在哪儿比你做什么更重要；另外一层是格局和眼界，就是不要被自己所处层级、所在的角色立场、视角所局限。PS：对于我来说，就是你开会反驳的时候，要再多琢磨一下，找的这些理由是不是因为你做这个事情 才找的。
如果“困难球”很大，大到挡住了我们看“目标球”的视线，结果会怎样？在现实生活中，发生了这样的事情，是不是意味着一叶障目不见泰山？时间长了，因为眼中已经没有了目标，而面前又是困难重重，是不是只能放弃作罢？希望我们每个人在工作和生活中，都能志存高远，将“目标球”设定得足够大，大到能足以掩盖“困难球”带来的挑战，然后每天矢志不移地朝目标努力，直至达成；
对于程序猿来说，当你看到一个概念的时候，最好去看下代码，这叫“知行合一”。一篇文章要写的透彻，一定是文章和代码实现相结合。
技术
- 设计重于编码，接口重于实现。制定接口的过程，本身就是设计过程，接口一定要反复推敲，尽量做减法而不是加法，在能满足需求的情况下越简单越好。PS：从小组长的视角来说，你不可能完成所有编码，也不可能所有细节都去review，这就要求你自己先想好一个项目的轮廓，然后去检查小伙伴有没有偏的太远，这个轮廓就是设计与接口。
- 不要完全根据使用需求去设计接口，参考 MVVM，ViewModel 就是根据 View 的需要而对 Model 进行的再封装，不能将这些接口直接设计到 Model 中。PS：一个Model尽量只有一个设计目的，ViewModel 可以只根据View 需要设计，而被多个场景用到的 Model 不行。
- 空杯心态，有人提意见，先收下它（无论接受与否）。
- 设计期间就一定要找他人讨论，我一直比较反对一个人把设计做完了，把文档写完了，然后才找大家开个评审会那种模式，虽然也有效果，但是效果真的达不到极致，大家没有参与到设计中来，通过一场会议的时间理解不一定有那么深，最关键的是，如果设计有些问题的时候，但也不是致命问题，难道还让打回重新设计么？
架构的腐化是必然的软件的后期迭代和进化架构师们往往是不参与的。业务的变化又不会少数人的意志为转移，随着变化，一定会有那些并不适合放进最初设计中的需求出现，这时候架构师远在天边。工程师们排期又紧，那就只能先临时用丑陋的方案把需求实现。在系统里留下技术债。这种“不适合融入既有架构”的需求事件出现在什么时间点，谁也说不清楚。给每个项目都安排长期跟进的架构师，而项目又一直没出现大的变化，又会变成资源浪费。架构师日常的工作如果不是跟进某个项目，这个项目碰到问题的时候，需要再做设计评审，临时抱佛脚找架构师来 review，大多也是走马观花。这还真是有点两难。
开发框架文档体系化的思考 当时看完之后非常有感触：1. 写文档本身就这么多道道。 2. 最令人启发的就是作者从案例中对问题的识别。关键是发现。
在容器云的落地构成中，三天两头各种小问题，业务方报过来很不满意。 很有能力，很有想法，所有的技术你都会，但就是没有办法输出成为一个平台（或者系统），发生的所有新的事情，都是在这个平台上找到或落地。一个组件A挂了，一会儿组件B挂了，或者天天很多简单的、无厘头的错误找你排查（重复性工作），这个时候就需要一个报警平台、异常探测平台等，这个平台不一定要cover住所有情况，但是当你发现一个新的问题，你可以加到这个平台上，沉淀下来，而不是解决完一个问题就结束了，什么也没留下。就好像你写博客，一开始有一个新的知识点就写一篇，我写到了466篇，发现很多内容都重复了，后来开始将博客归类，发现新的知识点就填补到原来的博客上。
有的时候不是谁擅长这个技术谁做这个事情，一定是谁（部门、组织）受益，谁主力去推动这个事情。
假设你实现一个系统，感觉上需要一个组件，但这个组件没有现成的库可以用，你自己动手写。那么有这个组件和没有这个组件，代码的差别不应该很大。经常出现因为组件的抽象没有做好，导致组件和系统的边界没有搞清楚，进而导致当现成库可以用时，代码要做很多的变动。
《职场求生攻略》根据我的观察和切身体验，其实很多时候，加班并没有让自己的产出更多。程序员的产出是不能用代码量来衡量的。如果非要衡量的话，可以用代码完成的功能这个维度来简单衡量。很多时候我们加班，并不是完成了更多的工作，而是用更长的时间，去完成自己本应该用工作时间就可以完成的工作。这就是效率低。如果系统重新设计重新做，是否可以让增加业务用例的时间大大缩短？如果是的话，现有系统架构陈旧就是效率低的原因。又比如公司里各种系统都不好用，工作中用到这些系统，就费时费力，还可能来来回回折腾很多次。这些现实情况，让本来听上去没太大工作量的工作，实际做起来要用的时间却会多很多。
代码质量：第一保持代码逻辑和业务相符，第二保持和团队一致的代码规范，第三考虑异常流程的正确处理，第四要做到架构超前于业务至少一个身位。
一个人会持续的的去做自己擅长做的事情。在不知不觉中，我们就会把自己的活动范围缩小，限定在自己最有优势的那些内容上。这就是优势陷阱。
程序要写出一定水平，那一定是非常有逻辑，非常有抽象能力的人。他们看到的世界看的是骨相。
解决问题，解决你这个层级能解决的最大问题，解决不了请汇报上级并给出你认为 OK 的解决方案。总之，就是让老板知道你的能力在快速提升，你的价值在不断放大。
林晓斌：如果有人请教你某个知识点，那真是太好了，一定要跟他讲明白。不要觉得这是在浪费时间。因为这样做，一来可以帮你验证自己确实搞懂了这个知识点；二来可以提升自己的技术表达能力，毕竟你终究要面临和这样的三类人讲清楚原理的情况，即：老板、晋升答辩的评委、新工作的面试官。
林晓斌：知识没体系，转身就忘记。在学习过程中最喜欢的就是这种交叉的瞬间。交叉多了，就形成了网络。而有了网络以后，吸收新知识的速度就很快了。
在美团做工程师，需要具备哪些技术基本功？对工程师而言，设计、编码、定位Bug是三项重要的基本功。技术基本功不易衡量和考核，它的提升更多源于工程师内心的技术理想以及把技术工作做到极致的态度。在训练方法上，我认为重要的一点是坚持在日常工作中“追求卓越”，用最高的工作标准牵引基本功的锻炼，然后通过基本功提升来支撑更高的交付标准。
压榨骑手的，绝不是系统无论什么工程师，设计系统的方法论都大致相同，这也是我在之前工作中反复宣导的，系统设计不可一概而论，也没有灵丹妙药，重要的只有一条：在约束条件下求得最优解。一旦约束条件搞清楚了，系统设计就成了“围猎”，基本是按部就班的事情。我参与设计过的系统五花八门，即便是相同类型的系统，只要约束条件不同，最终形态也可能大不相同。比如有些时候内存有限，就应当把复杂计算拆解开，分若干步骤完成；有时候网速有限，就应当把数据压缩，并且排出传输的优先级；还有些时候时间有限，就必须升级设备或者多加机器；有时候必须按时上线，那么可用性稍差一点也无所谓；有时候安全性必须绝对保证，所以使用体验差一点也无可厚非……或者说，系统设计如同走迷宫，约束条件是会“碰壁”的，阻力无穷大地方，为了走出迷宫，就不要去碰得头破血流，而应当在不会碰壁的，阻力小的地方想办法。上面的道理说起来简单，实际做起来却不简单。许多系统设计时根本不会列明约束条件是什么，有一些看起来无从退让的要求，很可能有很大的折扣空间。也有一些不起眼甚至根本想不到的要求，却成了绕不过去的拦路虎。恰恰是因为约束条件的不同，造成了问题所在的“局”不同，那么哪怕是同样的工作内容，也会有完全不一样的安排。现在我们回到骑手的悲惨处境。我坚持认为，问题的根源并不是工程师的冷血，也不是资本的无情，潜力的挖掘，一定是朝着约束最弱的方向进行。
逃离职业倦怠期，我是这样做的任何岗位都有存在的原因，如果仅仅只是把自己当成一个重复处理问题的机器，没有思考，没有总结和沉淀，那么也仅仅只是一个工具人。连机器人都算不上，机器人好歹效率高且能够自我学习。PS：在机器学习的背景下，人如果不努力，还不如机器
一个架构师的感悟因为软件是为了满足客户的功能性需求的，所以很多设计人员可能会认为架构是由要实现的功能性需求决定的。但实际上真正决定软件架构的其实是非功能性需求。架构师要更加关注非功能性需求，常见的非功能性包括：性能，伸缩性，扩展性和可维护性等，甚至还包括团队技术水平和发布时间要求。能实现功能的设计总是有很多，考虑了非功能性需求后才能筛选出最合适的设计。
闲鱼服务端架构演进历程我们要透过现象看本质，服务端架构永远在做两个方向的优化
- 研发效率。如何让业务开发效率更高，更少的人可以做更多的事，并且保证做的又快又稳又好。
- 业务赋能。技术要想在公司财报上不仅仅体现为成本，就要持续的创新，尤其是在 AI 浪潮下，服务端架构如何更全面的拥抱算法
软件架构中，横向的一层，做好了极大提高研发效率，做得不好则极大降低效率，可惜的是前者少见，后者常见。一个因素是，横向一层会产生组织，组织一旦产生就会生长，其生长的目的往往不是提升研发效率，而是壮大自身。因此这类组织的规模应该被严格控制。横向组织的规模小才能证明其技术价值。1:100 是有极大价值的，1:10 就有问号了，1:5 的话，多半是把活换了个地方干而已，而且因为沟通多了，全局效率得到极大降低。
社会
先做成一件事，是打开世界的钥匙。
张勇：作为企业一号位，什么是你不可推卸的责任？商业设计是一号位不可推卸的责任。你的团队，你指哪儿，大家打哪儿。但是你自己心里要不断去思考，公司走到现在，要走向未来，我的客户是谁，他有没有发生变化，我原来给他提供什么服务，我今天要给他提供什么服务，未来他还需要什么服务，跟我有什么关系。这就是整个商业模式设计。在商业设计以外，组织设计是企业一号位不可推卸的责任。再怎么思考得完美，抉择得果断，最终这个事情没有办成，就是你抉择的不对，也许是你执行没到位。如果没有好的组织，没有好的组织里的人，很多问题都会走样。所以要执行到位第一件事是解决生产力的问题，第二件事是解决内部生产关系的问题。
从整个商业模式构架来讲，最终考验每个人的是什么？是对我们自己本性的挑战。我们到底愿不愿意去面向未来、面向可能的市场，在非常困难的情况下，做一个不完美的决定。所有决定都是不完美的，因为在你没有发生好的结果之前，你甚至都不知道它是不是一个好的决定，但是没有决定是最大的问题。
技术人如何自我成长？认真生活也是一种态度，更是对人生的一种理解。在过去，我一直觉得自己处在一个奋斗的年纪，从来没有过多的关注生活，我也从来没有相信什么生活和工作的平衡，我对待工作的热情和投入的精力要远大过于我的生活。我觉得人的精力是有限的，必须要把最旺盛的阶段投入到事业和个人能力的提升上来。所以对待“认真生活”从来没有仔细去想过，更多停留在喊喊说说而已，我狭隘的看待了生活与工作之间的关系，Outing 之后我有不一样的思考。我们常常会提到一个问题：如何平衡生活和工作本身？这里边有一个词叫“平衡”，我不知道这个词在大家脑海里的画像是什么？在我脑子里第一出现的是“天平”，要么投入生活，工作上不做过多追求；要么更多思考工作，生活更多服务于工作。这种工作和生活非此即彼的狭义理解其实深刻阻碍了自己进一步的思考。我很长时间都是这么割裂开来看的。事实是工作是生活的一部分，是包含关系，生活是什么？生活是人生，生活包含了事业（工作）、家庭（我们常常理解的生活）、孩子、教育、兴趣爱好等等。《高效能人士的七个习惯》这本书在讲“要事第一”时提到“木桶人生”，这个木桶里可以装大石头、小石子、沙子等等，工作对于我可能是一个大石头，它承载了我很多人生的价值、经济基础等底座，这本书让我觉得生活是可以全面推进的，核心是我们需要识别自己在生活中每一个角色里承担的“重要不紧急”事项，然后做好它，做好这关键的 20%，不断的汲取，以“全面推进”为原则，而不是以某一个片面的侧重点为方向。而且日常生活中的思考和启发其实是可以很好的作用于工作。发现美好，发现痛的地方，发现人性中趋利避害，这是一种智慧，这也是过去一年在认真生活里收获的成长，我还在不断的强化这种理解，不断的在践行这条价值观。
你的战略之所以失败，很可能因为它根本不是战略。真正的战略包括一系列清晰的选择，这些选择明确了公司将来要做什么和不要做什么。很多所谓的战略都只是目标，这种目标不会告诉你你要做什么，而是告诉你你希望的结果是什么。然而，你依然需要战略去实现自己的目标。
那么“战略”到底是什么？日本的一本书里的定义给我印象很深：战场上，所有和看得见的敌人有关的，都叫战术，除此之外的，都叫战略。也就是说，所谓“战略”无非是超越某种感官限制的思考和手段。“看得见的东西都不是核心竞争力”。比如，大厂可以给你分享监控系统技术原理、如何支持多样的报警规则。但真实的业务系统需要监控什么东西、哪些事件无伤大雅、哪些事件要报警、哪些事件不仅要报警还要一直报警、如何让什么都不想管的开发用起来 等。 这些判断和决策（也就是”落地“） 才是系统发挥价值的关键。
很受启发的文章，要多看几遍：人是如何变强的人变强的过程，其实就是「心智世界」对「现实世界」的拟合。你的「心智世界」不断吸收外界的信息，不断拓展自己的边界，试图去拟合外在的现实世界，从中提炼出新的概念、规则和框架，来优化和更新旧的模式。
- 心智世界是会被「强化」和「固化」的。简单来说：你在同样的位置停留得越久，你对它就会越熟悉。那么，它在你的心智世界里面，就会居于越发中心的地位。你就会越加倾向于从它出发、以它为中心，去看待别的事物，让别的事物来适应它。
- 要对抗这一点，就需要锻炼我们的「非整合能力」。什么意思呢？它指的就是「在心智世界中，容忍不一致信念的能力」。
- 总要做一些事情， 不单纯以成功为目的，而是以探索和思考为目的，最大限度地体验它、理解它、思考它，来拓展自己的能力边界。
- 什么是「认知升级」？实际上，就是借由某个契机，某个关键节点，突然打通了一切障碍，把过往各个零散的点串联了起来，形成一张网络。这才是最高层级的快乐。也是我们不断突破认知边界、拓展心智世界的不竭动力。PS：有了一张思维网络（比如唯物辩证法，实践论、矛盾论），虽然某些事情不知道怎么弄，但大概方向是有数的。
王慧文的几句话
- 你觉得美团的基因是什么？君子不器
- 不是我们做了什么事情，只是我们跟上了，没掉队。
- 有担当的管理者，要把下属从“愚昧之巅”推向“绝望之谷”，至于下属能否爬上“开悟之坡”，看个人造化。大部分人都知道别人处在愚昧之巅，但是很少有人知道自己处在愚昧之巅，这就产生了非常大的信息不对称。因为每一个人在自己成长的过程中，没有得到有效反馈，没有人告诉他“你现在在愚昧之巅”。因此，有效反馈变得非常重要和稀缺。
池建强：人和人之间的差距，不在于你学会了哪些技术，而在于你如何使用这些技术解决实际的问题。这才是一个人的护城河。再进一步来说就是：技术决定了一个程序员的下限，技术不会，活儿肯定干不好；对业务的理解和灵活运用技术的能力，则决定了一个程序员的上限。
什么是技术情怀思考如果是被动式的，是主管、业务方叫你思考，那么这种思考有时候往往是缺乏想象力和创新力的。
张一鸣：只有在态度(决心、韧性、务实)上上一个台阶，调研设计上上一个台阶，工程质量上上一个台阶，才能做出强大复杂的系统。系统复杂度一高，对应的能力一欠缺问题就会层出不穷。
去做：风险是指不确定的事情，如果不确定的事情都能转化成可确定的事情，意味着风险已消除。
霍泰稳：基于恐惧做出的决定，基本都是错的。
程序员如何把控自己的职业我们可以看到整个世界就在不断地进行数字化，因为，只要数字化了，就可以进行复制传播和计算，只要可以进行计算了，就可以进行数学建模，就可以自动化，只要可以自动化了就可以规模化，只要可能规模化了，就可以改变整个行业。人类的近代史的大趋势基本上都是在解决能源和自动化的事，源源不断的能源是让机器不知疲倦的前提条件，用机器代替牲口，代替人类进行工作是规模化的前提条件。所以，技术的演进规律基本是自动化加规模化，从而降低成本，提升效率。这就是为什么世界变得越来越快，人类都快跟不上节奏的原因，主要是整个社会不断被机器、数据所驱动。
很多事情都是意愿大于能力的，比如涨工资，不能靠别人哄，自己首先要有更进一步的强烈意愿。工作久了，你一定会发现，很多人别的本事没有，下否定结论的能力特别强。 他们遇到任何不熟悉的事情，第一反应都是“不可能”，而不是“怎么才能”。一个人首先要有强烈的愿望，才有动力支撑你去实现目标，这样的愿望就像一个超级杠杆，能够将你的能力和影响力放大百倍、千倍，最终影响你的个人价值。
高薪的人在想什么？在想通过他人完成工作，通过他人创造价值。一个人的薪水，是由他创造的价值决定的。你可以一个人创造10w的价值，拿1w薪水。那么，如果你想拿10w 薪水，或者你能力提高10倍，或者团结10个可以创造10w价值的人，通过他人完成工作。并且，不是管理者也可以，可以找你的老板要资源、横向影响你的同事。
乔新亮：人一定要在认知上将自己解脱出来——辛苦是相对而言的，身体累不可怕，心累才可怕。其实你可以选择更轻松的城市、更轻松的工作，甚至部分同学可以啃老不工作，但你没有。如果你选择留在一线城市，就决定了自己的生活一定是充满挑战的，没有人强迫你。成年人，所有的决定，都是自己做的。如果你觉得焦虑、压力大，不妨如此告诫自己。留在一线城市的关键目的是为了成长；成长的关键又是什么？我认为是做事，坐在那里担心解决不了任何问题，猛将发于卒伍。短期的稳定、轻松，长期看来就是最大的变数啊。而且这样的变数，一旦发生了，就会天翻地覆。一直追求稳定的工作，最后不稳定；不断追求挑战，在动态、压力中寻找的稳定才是可靠的稳定，这点和架构设计里面追求高可用、高可靠要基于为失败设计的理念有异曲同工之妙。因为环境过于放松，没有逼你做事，逼你成长。当变故发生时，你不具备应变的能力和在变局中存活的实力。
事务性的工作不会总是让人不开心，特别是工作不太多的时候。已知的、重复性的工作有一种让人平静的功效。完成这些事可以带来一种满足感和快速胜利感。如果花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。什么才是真正的工程师文化？从浅层的意义来说，工程师就是要实现业务的自动化。所体现的内在逻辑是如何把问题 Close，如何把问题彻底解决掉，而编码只是一种工具。
风险和失败往往是你放弃长期投入的重要因素，但其实每个人都知道如果你做的真的是一件有价值的事，一件可以值得长期投入的事，那么风险和失败就是不可以避免的了。当然，谁不会想要找所谓风险比较小或者风险完全可控的好生意呢？
阿里 10 年：一个普通技术人的成长之路每个人每天都在做事情，为什么有的人做的好有的人做的不好？我认为很重要的一点是做的事情之间有没有产生连接。做的好的应该是：每天做的事是每个月的一件事的一部分，每个月做的事是该季度一件事的一部分，每个季度做的事是本年度一件事的一部分。当做的所有事情建立起了关系，组成了更大的一件事才有意义。每天的一件事和每月的一件事的高度是不一样的，复杂度和解决需要的时间也不一样。每个事情都该做，每个问题都该被解决，但我们的时间和精力是有限的，判断事情该不该做的依据就是这个事情能否成为你的月度、季度或年度的一件事的一部分，如果可以则制定计划去做，否则说明这个事情不该你来做。一件事情可以分为 99% 和 1% 两部分，大部分时候我们做到 99% 就觉得可以了，如某个成功率指标做到 99.99% 之后，可能发现最后 0.01% 要付出的代价比之前的全部还要高，要不要做？我觉得应该尽可能推进，因为越深入越能体现出竞争力，至于最后做到 5 个 9 还是 6 个 9 取决于和业界拉开的距离。99% 是必须做的，1% 是需要突破的，深度和壁垒往往体现在最后的 1%。每次完成一件事情较之前进步 0.01% 也是突破，100 次 0.01% 就是 1%。但如果每次做到 99% 就停止了，那么我们和流水线上的工人没有本质区别，都是在重复做事情只是重复的东西不一样而已。完成一件一件有关联的事情将自己打造成一个服务，避免完成一件一件无关的事情让自己成为一个资源。一件事情体现的是业务广度，1% 体现的是技术深度，规划时需要业务广度，落地时需要技术深度，二者结合起来才能保证所做事情的正确性和竞争力。