Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

大公司里虽然团队（也可以是人）众多，但是始终可以分成两类：一类是真的想把事情做好；一类是想显得“自己想把事情做好”。 这两类团队（人）很好区分，跟他们合作的时候如果遇到了问题： 第一类团队（人）会站在事情的角度上思考问题，他们会思考你当前遇到的问题，提出方案，然后试图和你一起解决问题。 第二类团队（人）会站在自己的角度上思考问题，他们会思考你当前遇到的问题有可能对他们有什么影响，在此基础上进一步指出和强调你的问题，然后试图让自己跟这个问题撇清关系。 而你往往会发现，随着时间的推移，第一类团队的工作能力，和第二类团队的撕逼能力会同步增长，以至于不管第一类团队做到什么程度，第二类团队都能更进一步的找到合适的逼点撕扯起来，把大家拉回同一个起跑线。 无论过程如何，最终还是会达到一个两类团队都能在公司和平共存的平衡状态，我把这个平衡的状态称作撕逼平衡态。

前几天听到一个观点，最近我一直在琢磨。 原话忘了，大概意思是培养人得给足够的时间和精力一点点磨，不能直接扔给他一个他现在一下搞不定的问题。 算起来，我给几乎所有合作过的人都定下过（对方认为）超过他们能力的要求，甚至wow带团玩游戏的时候也经常因为这种事跟人吵。最后就变成我要向对方证明他其实能做到这件事。 最后要么是证明了其实他可以做到，他错了；要么是证明了他对了，他确实做不到。 无论如何都感觉我在刁难他。 太难了。

继续昨天思考的话题，“如何判断一个技术团队是否真正缺人”。 问一个团队负责人他缺不缺人，答案一定是缺人，每个人都能说几句缺人缺到崩溃之类的演讲。真正的问题是，怎么判断谁更缺人？ 绝大部分人的第一反应都是按加班时长算，但是组织里永远会有劣币存在，他们会把加班当做目的而不是手段，和白天休息晚上装样子干活的人相比，一个正常团队再怎么忙也不可能比专门加班的人还能加班。 按工作量来其实也不现实，除非做完全相同的工作，否则工作量很难横向比较，就比如说前端做一个页面和后台做一个接口的工作量究竟哪个更大，很难讲清楚。这里同样也会出现劣币的问题，一个低效率的团队肯定有更多事可做。 完全撒手不管，谁先招到人算谁的也是个办法，毕竟缺人的团队会更努力招人，但问题同样是，混子有更多的精力招人，而且混子可以轻易的降低标准，招更多更混的人。 我也尝试过把问题反过来思考，不考虑谁更缺人，而是评价每个团队加人之后能够带来什么收益，这个方案看起来更好一些，但是也有缺陷，很多创新和突破并不是天生带着目的的，这一部分没有确定的收益，就很难评价。 我想象中的组织，应该同时足够精简而又足够灵活，能够避免无意义的内耗又能确保个人利益，组织中的每一个节点都存在意义，形成组织的每一个结构也是有意义的。 但是很可惜，这个问题我也没有答案。

我现在的每日工作安排： 10%的时间思考方案 10%的时间发呆 80%的时间活动颈椎

今日工作总结。 有同学跟我聊团队配合的问题，说在项目里遇到猪队友感觉自己很绝望。 如果把一个互联网项目比作汽车的话，不同的团队可能一个负责转向，一个负责发动机。都做到三分，汽车只能卖的很便宜；但是一个转不了弯的汽车，配上牛逼的发动机也不会有多少人买。 猪队友对其他人的影响并不是加法，而是乘法。所以，做好自己的事情，然后想办法换个转向，才是正途。

今天跟人聊到视频播完自动播下一个的问题。 A说这样体验辣鸡的一匹应该赶紧下掉，B说应该做测试对比是否自动播放的数据，C说应该提升后推荐算法准确度。 这个问题有些似曾相识。 我想起来若干年前坐地铁上下班的时候，中关村地铁口是海龙大厦，进出地铁口站了一排各种推销手机电脑的小伙，但凡你跟他们的视线对上就会被一路围追堵截，为了把你拉到店里从哄到劝甚至上手拉扯各种手段全都见过。 店长们肯定知道拉人进店会招人反感，但是拉人能增加收入又毋庸置疑。正面坐拥着中关村的巨大人流，背后感受着jd这些在线平台的快速崛起，如果我是海龙里摆摊的老板，想要经营下去，要如何抉择？ 为了声誉不再拉人？给拉不拉人算笔经济账？还是把摊位里的货物重新摆摆？ 我觉着可能都没什么用。 摊主能做的只有赶上时代或者被时代抛弃，要做的是投资，哪里是营业额的问题。

今日工作总结。 跟工作一年的同学聊了聊工作上的困惑，其中一条是感觉很难把控进度，经常会出现以为一天能搞定，结果熬了俩通宵的情况。 其实评估工期是个很隐蔽又很重要的能力，但是很多同学存在一个误区，错误的认为评估工期等于按时完成任务：某一次工期没有估准，吃了亏之后暗下决心，下次一定要吸取教训，不要踩坑，争取提升效率。 其实这是错的，最优先要做的是把工期估准：这一次踩了个坑，多花了三天时间，下次类似的情况就按多三天去评估；这次运气好按时完成了，下次有可能运气不好，那下次就把冗余时间加上。 当事情总是能按时完成之后，再去针对性的优化效率，此时优化效率是水到渠成的；反过来，事情还没能做完就搞优化，事情成不成大部分看运气，必然是不靠谱的。 每个程序员的成长过程中，必然都要经历这么一段区分自己的目标与能力的过程，虽然它无关技术成长，但却一定程度上决定了个人发展速度。 我把程序员工作生涯中的这个过程称为， 寻找b树。

前几天面试了一些应届的同学。 有的同学专业课1%，有的论文发了一堆，有的bat实习了一年，基本素质都非常强，远超当年的我，看完简历就能直接通过的那种。 问题来了，那我还要考察什么来凑满三十分钟的面试？ 我最终决定考察他们的好奇心。 比如，你自己写的这个rpc框架是基于nio异步模型实现的，那么我收到一个网络请求的时候，计算机里都发生了什么事情，最终变成了一次代码回调？ 又比如，你的项目基于mysql做了索引优化，能讲一讲加索引之前和之后，从硬件的视角看，一次查询有什么具体区别吗？ 再比如，你已经通过redis的zset实现了一个高性能优先级队列，现在的性能瓶颈是什么？如果让你只针对这一个业务场景做优化redis的话，会对跳表做什么修改？ 简单的说，都是不同领域的交叉问题，或者如何把理论联系到实践当中。经常问“为什么”的人对这类问题会非常熟悉，而只学不做或者只做不学的人遇到这种问题会比较难受。 好奇心并不会决定他们是否会收到offer，但是决定了在未来五年，十年后他们是否能够不被所谓的35岁问题而困惑，他们是否能够带领某个组织持续进化，甚至决定了是否能够驱动这个行业持续发展。 另一方面，能跟有好奇心的同事一起工作，是一种莫大的幸福。

最近天天处理各种问题，一次又一次领悟到了这个道理： 很多事情没做好并不是因为真的做不好，而是没能在交付前及时发现问题。 换句话说， 自己做的东西有多少问题，自己心里还是没有b tree。

今日工作总结，作为团队管理者大概能遇到三种项目。 收获型：扔进去人，返回收益。 黑洞型：扔进去人，什么都没返回。 真理之门型：扔进去人，返回一堆hc。

昨天晚上到现在反复看了大概五六遍飞猪直播回放的完整版，又去祥子发的微博下面翻完了100多评论和700条转发。 虽然这次被骂的不是微博视频，但是我很焦虑。 最近这半年我基本都被淹没在各种合理或者不合理的需求里，对于基础体验的优化力度放松了不少。 去年我们集团队之力，从需求的缝隙里硬里挤出来的体验优化成果，很有可能被一两个不经思考的需求，或者哪天没测试的一两个bug，未来瞬间就（甚至可能已经）被颠覆掉了。 按去年的经验，用户体验不是憋几个大招就能解决的。难的是改变内在驱动模式和提升外部反馈效率，这也是我下一步的目标。 下半年，且行且珍惜吧。

封闭开发基本上到了尾声，照例总结一下吧。 先说做的好的，有三条。 首先是坚持了两年多的招聘宁缺毋滥原则明显产生了效果，平时有没有拖后腿的人差别不大，但是一旦要上场打硬仗就会发现一个不靠谱的人能把五个以上同事的效率变成0。 这一次我们作为底层所有核心服务的提供方，十几个人支持了近十个技术团队的底层服务，对接了好几十号人，过程中基本没有明显需求延期和重大bug，其中最核心的效率提升就来自于靠谱的团队成员，当团队里每人都能独当一面时，放心的把后背交给队友是一件非常幸福的事。 其二在于我们没有单纯做需求，而是在需求的夹缝中沉淀下来了一套能够进一步提升效率的系统，让技术的一部分价值能够独立于业务，通过技术建立秩序而不是迷失于混沌的需求，为接下来要做的事情打好基础。 其三关于是我个人管理实践水平的提升。我没有单纯的试图通过996机械式的加班、提高团队工时来赶进度，相反，我在加班的基础上建立了自由轮休制度：每人每周可以自由选择一天，提前下班。事实是，休息变多以后，整个团队的效率飞涨，几乎没再有低级错误，做的决策也都更加合理了，感谢人月神话。 而这次封闭缺点也很明显。 我们又一次没能够一次把事情做好。封闭开发期间很多代码没有单测，设计里遍布妥协和兼容逻辑，很多方案没有完整的分析和思考，肉眼可见的埋下了许多坑。甚至于前面说的能够提升效率的系统，也只是勉强做到了能用，离好用还差了十万八千里。 封闭开发是为了时间，但讽刺的是，我们可能需要用更多的时间，来换回节约下来的时间吧。

项目时间紧的意思是，要在这个时间条件下拿出你能做到的最好成果，不是时间一紧就要优先选差的方案。 这样说不好理解，我换个说法。 假如上班要迟到了，你还没吃早饭。 这个时候你应该想办法吃点东西别饿着，尽可能在不迟到的情况下保证营养。 而不是第一时间跑去吃屎。

封闭开发第一周总结。 参与过的几乎所有的跨团队大型项目都会经历不同程度的项目失控，只是失控程度的区别。人月，项目计划或者管理者的雄心壮志都解决不了项目失控的问题。 一周以来我一直在被“未来究竟哪里会出问题”这个念头所困扰，这个念头非常不好，打个比方的话，一线写代码是跟具体问题对打，现在就好像是蒙着眼睛跟空气肉搏。 以至于最近开始因为“不知道自己正在焦虑什么”而焦虑了。。

互联网后端架构师应该有针对性的训练自己的数据估算能力，否则设计方案会很没有效率。 比如“每秒钟插入20000条kv数据，过期时间7天，如果要用redis需要多少内存，内存方案是否可行” 或者是“每次查询需要对2000条数据做聚合，缓存命中率95%左右，10000qps的情况下是否需要增加二级缓存” 又像是“100亿pv的日点击，1/3的点击需要加一个特殊逻辑，晚高峰的每秒峰值处理量是多少” 甚至是“这个功能我也不知道会有多少人用，你们看着评估要申请多少台机器吧” 类似的情况在讨论方案的时候经常出现，虽然都是小学四则运算，但是不专门练习一段时间的话很难快速给出计算结果，而计算结果决定了方案是否能够落地。 跟产品开会的时候如果不能当场确定产品方案的技术可行性，很有可能接下来就是一次又一次冗长又没有意义的“细化”会议。 当然，就算效率低，最终产品和技术方案也是能在一轮又一轮的讨论中确定的。 但是到了那个时候，留给技术的时间也不多了。

《系统之美》这本书我要再推荐一下。 有了系统的概念之后才会意识到，其实很多问题是的根源是系统的目标或结构，而不是某些个体的独立问题。很多决策的摇摆、目标和行动的不一致、或者持续性的低效率，其实体现的是系统的特性，而不是个人的意志。 其次是通过有限理性这个观点，可以高效的理解系统与个体之间的关系，解释各种个体与系统之间相互矛盾甚至无法理解的行为。 最重要的是，把系统当做整体来对待之后，逐渐的感觉周围的很多傻[]其实只是“系统”里的一个结构，看到他们也不那么生气了。

过去一年多时间我的团队主要参与的是微博视频的上传发布速度、播放流畅度和清晰度优化，但问题是 从行业角度，怎样评价我们的工作做的好坏？ 从公司角度，怎样评估我们所做工作的价值？ 在现状下，怎样开展下一步的工作？

互联网干久了，面对海量数据的时候经常会产生一个错觉：数据是万能的，ab实验的结果就代表了一切。 举个例子，当初在做视频播放流畅度优化的时候，我们也做了很多大数据分析的工作，起初确实解决了一些问题，但是越往后分析就越会发现单纯数据分析的局限性：简单数据分析已经发现不了问题，基于海量数据全面做深度数据挖掘的成本又太高。 后来我们换了个思路，配合数据分析做了一些用户调研，了解用户的问题场景，并且让用户配合我们一起做了深入的测试和网络分析，竟然很简单的就发现和解决了很多问题。 这让我想起以前书上看过的一个例子：某个系统一到周末凌晨就会宕机一小时，之后又神奇的恢复了。研发人员绞尽脑汁分析原因还是没有结论，最后跑到机房大楼蹲点才发现，每周末保洁阿姨打扫卫生的时候会顺手拔掉电源，完事再插回去。 有时候离用户近一点不是坏事。

我最近越来越意识到“知行合一”的重要性。 举个例子，代码质量是否重要，leader每天说两句“代码质量非常重要”，并不意味着他真的觉着代码质量重要。只有这个leader花了力气建立、执行和持续经营了制度，来保证代码好的人有奖励，代码烂的人有惩罚，才代表他真的认为“代码质量非常重要”，这个团队也才会真的提升代码质量。 往大点说，一个组织内的价值观，并不是愿景之类的口号，而是应当有与之匹配的组织结构和权责分配。 再举个例子，用户体验是否重要，光靠开会的时候说“我们非常重视体验”是没有价值的，当组织里有人为用户体验负责，并被赋予了监督体验的权力之后，才能建立和执行相应的制度。最终制度落地，真正的让提升体验的人得到奖励，降低体验的人受到惩罚之后，才能认为这个组织真的认为“用户体验非常重要”。 再说回来，评价一个人，不应该看他微博里天天发的那些天花乱坠的价值观，而是要看他究竟做了什么，他对外展现的价值观是否与自己日常的行为相符。如果不相符的话，应该第一时间付诸行动，而不是进一步升华价值观。 付诸行动之后才会发现，付诸行动是如此的困难，所以才使得大部分人和组织都难以让行动追上价值观。 共勉。

最近这一两年的的工作让我充分的理解了80/20原则。 很多复杂的问题看起来无从下手，一群人会念叨“没那么简单”、“这么做解决不了所有问题”、“要先搞明白”。 但其实只要确定好哪些事是必须做的，踏实的把这些事情一件一件事情的完成，其实做不了几件事就可以完成到80分的程度。在实践中也会慢慢探索出接下来到达100分的方向。 所以我现在特别看不惯指点江山的空想家：“别瞎bb，干tmd就完了”

看到@纯银V 发的关于如何加快项目进度的问题，正好最近在做效率提升方面的思考，从开发的角度说一下。 首先我认为最有效率的就是砍需求，没有之一。但任何需求都有潜在动机，即使是“老板说就是要做没有什么理由”的需求，如果深入的分析潜在动机的话，绝大多数也是合理的。因此砍需求不应该按照“如何砍掉不做”的思路执行，而是“如何事半功倍”的思路来规划。在这过程中不可避免的会遇到决策和执行层思路的冲突，有效的沟通能够找出达成最终（而不是每一个）目标的最优路径；反之，最终会发现砍掉的一定都是跟执行效率有关的需求。 其次是人月神话，离执行者的角色越远，就越喜欢算人月。我认为加人或者加班的方式对于效率的提升是先扬后抑的，加两周班或者加一个人，大部分情况下进度会提升；而加两个月班或者频繁的团队调整，除了给决策和管理者“我做事了”的心理安慰之外没有任何正面价值。 再次是协调，大部分一线执行者不会有参与整体协调的觉悟（尤其是进度压力大的时候），能从个人的周报上发现的进度延期风险基本上相当于人去医院的时候已经七孔流血无药可医了，真正能避免进度风险的节点都在日常开发中。需要有标准化的开发流程，和一个了解流程细节的人把控进度。大部分情况下，写代码的架构师更适合这个角色。 最后，敏捷开发也好，快速迭代也好，增长黑客也好。背后是高效的开发、测试、数据系统支撑，不是产品经理多提点需求试试，或者每周加班多上一两个需求。如果要走敏捷开发、快速迭代，就要正视背后的技术支撑体系和搭建庞大体系的投入，项目越大，背后的支撑体系投入就越大；否则就要正视产品经理的能力和正确决策的价值，避免无谓试错。 我特么又流泪了。

如果我是厨具行业的老板，最近这一阵我会找几个与做饭完全无关的up主，数码美妆旅游之类的，让他们拍几期疫情时期在家做饭的视频。 视频不用特别刻意的介绍产品，大体剧情搞成一开始啥也不懂做一次俩钟头还做糊了，后来一边换厨具一边发现这玩意太好用了原来做饭也没那么难，其余都交给作者自由发挥。评论里来个小号问哪里买的，再来个小号回复链接然后推上热门，齐活。 以上就是我买了个不粘锅做饭之后的感想。

我发现最近这几年我越来越习惯通过“人”来预测一件事情：开发会不会出bug，产品会不会改需求，设计会不会不好看，决策是不是有问题……影响因素里只有一小部分跟事情本身有关，起决定性作用的是做这件事的人是谁，很多事情在决定是谁做的那一刻就注定失败了。 评估风险的时候要更多的考虑人而不是事情，屡试不爽。

久违的有人向我咨询技术问题，就单独开个微博吧。 “我是做后端的，工作一年左右，每天工作偏向于CRUD，不知道后面该如何提升自己” 其实跟职业发展的问题都应该分人回答，不同的人就算问出了相同的问题，答案也不太一样。我大概把人分成A/B/C/D和S级的人，分别描述一下。 对于一个工作一年的CRUD后端工程师来说， A：已经是团队主力，除了CRUD之外，还做了不少流程或者功能上的改进，引入了先进的框架或理论，目前的困惑是感觉自己的能力无处发挥（或是团队风格和自己不一致）。 B：已经融入了团队，每天按时完成领导安排的工作，一年时间已经能把在校学习的理论应用到工作中，目前的困惑是不知道领导下一年会不会还是安排类似的工作。 C：感觉工作有些吃力，这一年基本都是在学习，隐隐感觉自己做的还不够好，目前的困惑是不知道怎么提升自己（做CRUD）的能力。 D：把前面所有对A和B的评价里都加上自认为。 S：大神应该没有这问题。 我的建议是首先要跟直接上级深入交流一下，找出自己目前属于哪个层次，然后针对性的选择明年的方向。 D：找出自我评价与上级评价的矛盾点，如果沟通之后确实发现了自己的不足，首先针对性的做改进，其次尽快建立起合理的自我评价标准；如果坚定的认为自己是对的，那就同A。 C：除了跟上级交流之外，多找同级或者工作经验多一些的人沟通，学习和实践他们解决类似问题的【方法】，并且多邀请他们对自己的【成果】做评价，学习如何自我驱动。 B：向上级表达一下自己的诉求，在工作之外花时间学习一下基础理论（内核、网络、存储原理、软件工程等）、或者行业实践（高可用架构、行业解决方案等），为跳槽做准备，但不建议工作一年直接跳槽。 A：跳槽或者内部转岗吧 S：我也不知道

新年的第一次睡前思考。 去年有两个比较大的问题，第一个问题是浮躁，微博视频技术方面能做的事情太多，过去的一年里零零总总上马了十几个大项目。虽然每个项目都切实解决了一些问题，但是也多多少少产生了一新问题。基础不牢固，思考不深入是这些新问题的直接原因。 在未来用上更多新项目，新技术，新概念确实很吸引人，但回顾自己的成长历程，每次完成跨越都不是因为学了什么新名词或者简单完成了某个需求，而是把技术尽可能完美的在业务上落地，发现问题，思考问题，解决问题，校验效果，形成沉淀，明年的微博视频技术方面要做的更踏实，不求做大做多，只求做好做强。 另一个问题是边界，作为一个平台技术团队，我们的目标应该是纯粹的技术能力，还是关注业务与用户体验？上一年我做了很多体验反馈收集和建议相关的事情，这些体验与反馈一定程度上指导了我们上一年的工作。 但是相对的，边界越宽，精力越散。我们这种小团队既没有精力，也没有能力去负责所有的事情。但是在目前的情况下，多做一些事情，确实能对业务产生一些价值。与用户的距离多少合适，怎样合适，这是明年需要我去继续探索的事情。 在公司做事情就像打游戏，路人队友人猪不可期，自己天赋好坏不可改，游戏规则随时都会变，大部份时候一个人甚至一个团队确实左右不了胜败。但是既然要继续玩，还是希望明年会更好吧。

深夜碎碎念。 今年我主导的几个项目基本都在收尾，一翻日历生日过完也没写点啥，离元旦还剩三礼拜，是时候回头看看自己的这一年了。 今年算是我养病之后终于开始恢复工作状态的又一年，还是隐约的感觉到元气损伤加上锻炼不足，一整年浑浑噩噩，每天能集中精力的时间超不过一小时，以前写代码算是放松，如今还是写一会反而要休息一下了。 不过还好今年还是努力推进了一些微博视频的技术改造，简单说来就是在这一年里微博视频的发布变快，画质提升，卡顿减少，成本也下降了。带领团队克服一个又一个的问题还是挺有成就感的一件事，经过一年时间，微博的视频技术也算是踏上了视频技术的主赛场。 团队里我最欣赏的程序员的离职是个对我挺大的打击，不过对于一个团队来说，没人离职反而不是个好事。今年在带团队方面最大的心得就是确认了宁缺毋滥的价值，1个优秀的程序员能不能顶上3个普通人不好说，但是团队里只要有1个不行的人一定会搭上3个优秀的程序员的精力。今年的几次压力最大的时候都能明显的感觉到优秀的“忙”与普通的“乱”的区别。 这一年我打破了很多次边界，这些打破边界之后的经验让我更加清晰的意识到了组织结构对于所有人的影响。很多福利是合理的组织结构带来的，也有很多问题是由于不合理的组织结构产生的。有些程序员费劲精力解决的问题，可能仅仅只是消除了组织结构不合理带来的“外债”而已，他的工作并没有真正的产生价值。 而另一方面，打破边界意味着要跟更多的人打交道，这其中有一半成功，一半失败。而失败的那一半体验基本都可以总结成哀其不幸，或者怒其不争。不过要说收获倒是有的，我学会了如何合理的降低期望，学会了睡前做冥想，也学会了对自己说：不生气。 今年看书的数量明显减少了，甚至不到之前的1/5。作为被工作占据大部分精力的人来说，微博视频占据了我这一年里绝大部分时间，甚至写年终总结都无法区分工作和生活，今年我也明白了工作就必须只能是工作，这种矛盾是让我有些懊恼的事情。 在凭借着这些五味杂陈的经验又完成了一次技术晋升之后，我有些开始怀念那些心无旁骛写代码的日子，和那些仅凭我一己之力就能够被解决的问题。如今我面对的很多问题，现在的我看来并不能单枪匹马一个人靠技术解决，甚至几乎是无解的。 即使这样，还是要努力前行……

周会的技术分享上讲了一下这周我感觉自己做的不错的一个紧急需求：虽然遇到了很多意外情况，但是既没有造成项目延期，也没有降低代码质量。 其中一个很重要的方面是我没有用瀑布式的开发流程：接需求，订方案，写代码，联调，上线。这种方式在互联网场景下很难抵抗风险，比如说联调的时候发现之前的协议定错了有可能是毁灭性打击。 这种场景下以更适合以验证为出发点的敏捷开发：先调通一个什么功能都没有的架子，再快速迭代出各个功能。在此基础上以风险的高低（而不是业务流程的先后）决定开发优先级，并且保证每天完成的版本都是可验证的，这样问题基本上都能在早期发现，可以有效的降低开发后期的压力。 在工作量相似的情况下，后期的压力很容易造成项目的整体走形，而在前期即使遇到相同的问题，也有更多思考和矫正的空间。大部分程序员在进度管理方面的问题，都是低估了风险带来的影响，高估了自己面对问题的能力。

瞥了一眼邮箱，发现之前漏看了一封问题总结邮件，结果一看给我气的够呛，既生他的气，也生我自己的气。 对我来说，处罚不是目的，甚至也不是手段，只是团队管理上的例行公事。 团队出现这种“做错了事情之后自己应该主动考虑受罚”心态的原因一定是我没能彻底的把三观洗脑给团队里的人。 我心目中理想的团队，在出了问题并且做了处置之后，应该只关心一件事情：以后如何通过技术手段把这件事做得更好，如何创造性的解决类似的问题，而不是找领导负荆请罪-受罚这件事一点也不cool。 毕竟我讨厌管人。 我讨厌没有创造力的做事方式。 我讨厌由于被管理而束手束脚的团队。 我只喜欢通过代码炫酷的解决问题。

秦老师请问下2年经验后端（e.g. PHP岗位）需要哪些竞争力呢（进微博的话）？看到您的一个回答是三年以后看心情换语言，想问问您换语言的话前期需要如何准备以及工作上的协调？ 就算是微博，每个部门的要求都不一样，具体的考察的重点也不一样，差距可以达到两个公司之间的区别。不过可以肯定的是不管哪里招人都会看公司教育背景、项目经历和面试表现。因为我不能代表其他部门，所以只说我这边考察的重点。 首先，两年工作经验的人我还是非常看重他的学历（硕士/本科）、毕业学校（是否985/211）和校招入职的第一家公司和部门（是否互联网行业/知名企业的核心部门）的，因为这些都是硬实力，高考、考研和校招已经把90%以上的优秀人才筛过一轮了，我没必要再筛一遍。 其次，工作两年左右，基本上绝大部分人都是第一年打杂，第二年独立做点东西。项目本身有技术难度，加分；做的项目与我们在做东西的类似，加分；在公司有过获奖、高绩效或者升职，加分；自己在项目里有亮眼表现（比如应用了某个框架解决了具体问题之类的），加分。 再次是面试表现，我初筛主要考察思维是否清晰，方式很简单，就是给你纸笔，让对方画个图介绍一下所负责的系统或者模块的架构，思维清晰的人会给我画出边界明显，交互清晰的架构草图；而不太行的应聘者一般会不停的在某个符号上画圈或者描边，最后给我的是杂乱到完全看出画的什么的一张草纸。虽然这个阶段我一般只要说“嗯”就可以了，但是大概会筛掉50%以上的面试者。 再之后就是一些技术的细节，就不再展开了，主要是考察有没有对技术的追求、对问题的思考和技术深广度。问题里的竞争力，大致就是刚才说的那些加分项。 至于换语言，对我来说没有什么负担。写个hello world就算是开坑，接下来只要不停的写，就行了。

技术专家每天的工作都在做什么？ 说实话，写代码的频率越来越少了。并不是绝对意义上的时间不够，而是每天有太多事情不停的打断你，很难有一个大段的时间让我去深度思考问题，因此现在写代码的频率越来越低，上次写代码已经是一周前的事情了。目前写的代码也不是那种特别难的只有我能搞的定的代码（真遇到这种情况我更倾向于培养其他人解决复杂问题的能力），而是我觉着他写的不对，所以把他的代码重写了给他做个示范。 那么时间都去哪了？我大概总结了一下每天要处理的事情。 首先是开会，每天要跟各种技术或者非技术的同事开会，其中最多的就是项目的需求（技术）沟通会，在互联网公司里，做项目要参与的部门很多，所以沟通就成了非常重要的一部分。大约一半的会议是开到一半突然想起来好像跟xxx也有关系突然一个电话把你叫过去，所以很多时候都是被临时叫过去定方案，年轻的同学们因为对系统的历史包袱、公司的组织结构或者系统的未来规划认识不够深入，所以很难在这种会上快速准确的完美的敲定方案，所以作为技术专家经常要参与各种会议的拍板。大概每天这样的会有3-4个。其他还有各种周例会之类的，每周有3-5个。 然后是解决问题，严重的比如系统突然报警了、用户突然投诉了，或者组里的同学遇到什么解决不了的问题之类的。如果是简单的问题就会现场解决，复杂的会现场给个思路让其他人继续解决，然后定期追踪进度。当然也会有那种特别难，或者特别急的问题我会亲自全程处理。每天这样的问题有5-10个。 然后是代码review，这个属于我自己的兴趣，因为实在是没有精力写代码，所以只能看其他人的代码解解眼瘾。大部分只写点评论让他们小修小补就行了，也偶尔会出现把人叫过来重新讨论方案，然后让他回去重写的情景。基本上每天会随机review1-2个PR。 然后是内部的方案细节review，每周有那么3-5个需要我了解或者决策的方案。但是大部分情况下组里的同学们已经把方案做的非常不错了，我只要听他们说然后若有所思的点头就可以了，就当做是每天活动颈椎的时间。 然后是招人，每天上班刷一遍招聘站，下班刷一遍招聘站，去各种论坛发发招聘贴之类的，这种权当放松了。每周还会有1-2个面试，大概一个人如果不是特别不行，我都会面1小时左右，把候选人聊开心了（或者聊到怀疑人生了）再把他们送走。 然后是学习，基本上看书、看博客、看论文都有，一方面要有足够的理论知识来指导团队和其他人的技术发展，一方面是向业界先进水平对标，找出自己的不足，然后跟具体某个方向的负责人进一步沟通。这个会占据大部分大段（10分钟以上）空闲的的时间。 然后是一些团队管理相关的事情，跟人谈个话啊，准备月/季/年的团队目标啊之类的，每个月会有那么几天需要集中谈话。 然后就是……刷微博，工作做久了会有微妙的第六感，预测出现在闲下来的时间会不会超过10分钟，如果感觉超不过，那就直接刷会微博放松放松。 最后还有个，提需求。比如要做个吐槽收集系统啊，内部的框架要做个升级啊，监控系统做个改造之类的，之前做工程师的时候基本上不会提需求，想起来自己撸着袖子就做了，但是现在更多的是提出想法，由其他人来实现。基本上每天刷微博的时候都会突发奇想要做点什么东西，然后找一个无辜的程序员要排期。 一般他们第一反应是排期要一周，然后我会指给他们要改的那段代码，然后说这段代码改起来也就10分钟，今天晚上下班之前就要要上线。 他们脸上的表情从轻松，到愤怒，到无可奈何。 我笑了笑，技术专家客串产品经理提提需求就是这么为所欲为，且枯燥……

分享一个工作中的沟通小技巧。 刚上班那会特别害怕跟人沟通，尤其是要麻烦其他人的时候总是觉着不好意思开口。后来领导跟我说： “不要觉得是「我」在跟其他人沟通，跟他们说话的其实是工作。只要能完成工作，换个人对他们也一样。就比如说现在，我其实不想跟你没事瞎聊天，但是我的工作是指导你，所以我就需要跟你说这些。你现在知道我是因为工作不得不跟你说这些，会对我这个人有偏见吗，不会，因为工作就是工作。工作上的事情，没必要不好意思”。

前几天review代码的时候发现注释写的有问题：注释应该首先是对动机的描述，其次才是对代码的补充描述。 举个例子，代码的逻辑大概是if(开关A) then 动作1;else(开关B) then 动作2;end 不好的注释： // 如果A，那么动作1，否则，在B的情况下，执行动作2 好的注释： // 由于某某原因，产品逻辑由xx修改为xx，这里正常情况下应该判断A，但是为了防止产品经理在上线之后又临时改需求，因此也要兼容情况B，未来1-2月没有变更的话可以考虑下掉B 讲动机。讲动机。讲动机。

我目前的7月追番评价： 平凡职业造就世界最强 - 配合B站的吐槽视频观看有奇效 Cop Craft - 好看 海盗战纪 - 好看 女高中生的虚度日常 - 超出预期，好看 猎兽神兵 - 比中规中矩稍微好一点 BEM - 比中规中矩稍微好一点 在地下城寻找邂逅是否搞错了什么 第二季 - 中规中矩 石纪元 - 别的都还好，就是男主这个白菜头人设…… 某科学的一方通行 - 魔禁全系列看下来一直都有的困惑：这人是谁，那人是谁，他们在干嘛 炎炎消防队 - 本来很期待的热血番，实际看下来日常和中二占了大多数时间…… 君主 埃尔梅罗二世事件簿 - 没想到竟然是玄学版柯南，略失望

给新人做入职培训的时候突然意识到，很多现在看来必不可少的基础工具或组件，它的开发过程并不是想象中软件工程的场景：“领导说要做个基础工具，大家分工拆解项目，做好方案，三个人一个月把它突击搞定。” 实际情况是，大部分工具在当时只是某个才华横溢的工程师在通宵做需求的时候，“顺手搞了一把”搞出来的。 最近看有人在讨论10x工程师，我觉得能够“顺手搞了一把”的程序员何止是十倍，根本就是魔法师挥一挥魔棒跟一群苦力冲上去搬砖的区别。 一个团队的发展潜力，很大程度上取决于究竟有多少魔法师挥动了魔棒。而做工程师的很大一部分乐趣，就是在于能够见证无数次挥动魔棒的瞬间。 忘了说了，我就是最初那个通宵做需求的工程师

工作中最痛苦的事莫过于遇到那些不上进又占着资源的佛系甲方队友： “这个问题应该可以解决，你那边这样修改一下就行了” “不行我这弄不了” “为什么不行，我们之前都这么解决过啊” “就是弄不了，你想别的办法吧” “为什么定的这个方案？我感觉不是很合理啊” “老板定的，我不知道，你找老板去” “你这样会耽误整个项目进度的” “哦”

这几天一直在做组里上半年的代码质量review，说一下我的评价标准。 默认6分 代码风格有问题扣1分 代码有明显的设计问题，耦合严重扣1分 逻辑有明显功能或性能问题扣1-2分 没有单元测试扣1分 通过各种模式解耦和提高扩展性加1分 优化高并发下的性能问题加1分 代码本身有一定技术挑战加1分 引入或者实现新框架解决通用问题加1分 每个人自行选择过去半年里自己认为写的最好的代码，向我介绍他写的代码好在哪里。 好像大部分人不知道自己的代码好在哪里，这点我很震惊。 我最近写代码的机会不多，但是每次写完代码，晚上睡觉前都要回味一下： “今天写的那段代码真好 设计模式用的真是恰到好处 注释写的朗朗上口 啊，我写的代码简直是艺术品”

前两天跟同事聊天，不知怎么就聊到了关于我之前的各种传闻。比如传闻我以前对需求的时候非常凶残，经常对着对着就把产品给弄哭了，但是这两年工作的时候好像脾气好了很多，问我怎么做的情绪管理。 我努力的回想这几年的经历，希望能找到什么可以启发他的方法--毕竟我从来没有做过什么情绪管理。 思考半天之后，我不得不语重心长的告诉他： 这两年我不怎么对需求了。

今天看了个胃炎保养的微博，作为工作十年的程序员，捋了捋我得过的（或者知道的）程序员的常见健康问题、日常需要注意的地方和我知道的可以买的东西（不过我推荐的东西一般没有性价比……） 首先是颈椎病，注意颈椎病不光是脖子疼，还有可能引起各种地方的不舒服，手麻腿无力胸闷头痛等等等等。 可以预防的方式网上各种颈椎操有很多种，定时做，还可以做小燕飞动作；晚上睡觉的时候用好点的枕头，枕头高度不要过高或过低；显示器垫高，让视线能和显示器平视，避免一直低头；不要突然扭脖子，尤其是咔咔响那种。 可以买的东西有枕头，枕头要能支撑颈椎而不是仅仅垫着头，我自己用的tempur；另外就是显示器支架，其实主要作用还是垫高显示器，我用过爱格升；还有颈托和拉伸器，这个一定要遵医嘱购买。 鼠标用的多了有可能得腕管综合征，就是俗称的鼠标手，幸运的是我没得过，据说症状是手麻。 可以预防的方式是经常活动手腕，网上有很多这方面的视频。 可以买的东西据说有各种腕托，不过我没用过；还有各种人体工程学的鼠标键盘，我也没用过，不知道效果…… 然后是腰部疾病，据说会腰痛，或者腰部肌肉容易疲劳。 预防方式是日常坐着不要歪在椅子上，容易单侧腰部肌肉劳损；并且不要一个姿势坐太久，经常起来活动；网上各种护腰的视频也很多。 可以买个护腰垫，几百块到上千的都有；或者人体工学椅，关键词herman miller。不管哪种，都要把腰靠实，不要坐着的时候让腰部悬空。 再往下是男性病，坐久了容易精索静脉曲张或者前列腺之类的问题，据说容易O疼。 预防方式是经常起来走走，不要穿太紧的裤子。 可买的东西没研究过，貌似有托O用的内裤…… 然后是菊花，坐久了有可能会犯痔疮。 经常做提肛运动可破，写代码的时候顺便提几下不怎么耽误事。 可买的据说智能冲洗马桶对预防有一定效果…… 再下面是双腿的深静脉血栓或者静脉曲张，这个比较凶猛，血栓可能直接猝死，静脉曲张据说会双腿喷血…… 预防方法是多喝水，多走动，腿部多做勾脚活动；晚上睡觉时垫高腿部。 能买的有分区弹力袜，如果腿胀或者腿部血管明显变粗可以试试。还可以买升降电动床，一般都有抬腿功能。 项目赶工的时候经常容易耽误吃饭，平日工作压力又大，容易出现浅表性胃炎，或者反流性食道炎，胃胀胃痛反酸烧心之类的，当然我还见过更猛的，加班加到胃穿孔…… 预防方法就是好好吃饭，网上很多胃病食谱，总结下来就是少吃好吃的食物；保持心态平和，不要老是想着殴打产品经理；如果睡觉烧心可以用个被子垫高上半身。 能买的，家里置办上油盐酱醋，自己在家做饭比吃外卖好；如果睡觉的时候经常反流也可以考虑买个电动升降床。 喝水少，容易肾结石。症状就是下腹痛，据说排出结石的时候疼的生不如死…… 能做的就是多喝水，多上厕所。 能买的大概就是个电水壶，现在市面上还有不少智能水杯可以提醒喝水，没买过不知道效果怎么样。 程序员晚睡晚起，不吃早饭，并且外卖饮食比较油腻，有可能引发胆囊炎或者胆囊结石。症状是右上腹和右肩疼。 能做的就是一日三餐定时吃饭，少吃肉多吃菜。 能买的好像没有。 天天一直盯显示器有可能干眼症或者其他眼部疾病。 能做的多注意眨眼，多看看窗外，避免显示器亮度过高或过低。 能买的有人工泪液，不过我还没试过。 项目压力大，作息不规律有可能会引起失眠。 可以试一下478呼吸法，但是失眠如果太严重建议药物辅助。我个人觉得中度失眠时安眠类药物是有必要的，据说会有依赖性，不过我一两晚上药物辅助睡眠之后作息调整回来就停了药；另外睡前听歌泡脚做做拉伸，不要老想代码。 可买的……舒服点的床垫和被子？ 熬夜通宵有可能引发心源性猝死，这个我只在报道里见过。 解决方案是正常作息，早睡早起，避免压力过大……吧。 没啥可买的…… 运动少容易引起肥胖，作为体重最高达到过240+的人，切身感觉到肥胖时会影响全身各处功能，减肥之后身上90%的毛病都没了。 解决方案是减肥…… 没啥可买的…… 最后就是秃顶这个世界性难题。 我知道的针对男性的M字秃头的唯一有效的治疗（缓解）方案是外用米诺地尔，内服非那雄胺，副作用是影响X功能，并且无法根治。其余方案都是图个心理安慰。 能买的，可以买个假发，据说有位大哥剃秃了之后每天都会根据心情换个发型…… 总结下来就是上班多起身活动，下班多运动，多喝水，早睡早起，规律饮食，少吃生冷油腻等等等等，有问题记得去医院确诊。30岁之后会发现，年轻的时候医生说的这些每个人都能说两句的套话，其实都是对的……

到了半年需要做工作review的时间。有两个问题迫切需要解决：一，如何review；二，review什么。 对于问题一，考虑了一下决定采用一对一沟通的方式来进行review，发总结或者拉评审会虽然省事一些，但是要么感觉过于敷衍，要么感觉过于形式化，无法达到总结、反思和筛选的作用。 但更重要的问题是review什么。对于应用了okr的我们团队来说肯定会关注每个人的目标和关键成果是否符合期望，但更现实的问题是：如何评价每个人的贡献和价值，并以此为基础制定激励和淘汰策略？ 仅仅review okr肯定不能完全代表一个人对于团队的贡献，毕竟okr的初衷是只是一个工具而不是评价标准，如果仅考察okr那么就不会有挑战性的目标出现。 思前想后，我决定在常规的工作汇报基础上加一条：review上季度完成质量最高的代码，代码质量的权重高于工作量权重。 没啥特别原因，只是比起被领导催进度，我还是更忍不了烂代码……

这周review的几处代码设计都有问题。不是具体某处代码的问题，而是设计接口的方式不对。 面向对象设计中，接口代表了对能力的抽象；而在实际设计时，工程师们却很容易把接口当作对实现的抽象。 换个说法，就是错误的理解了抽象这件事：仅仅把接口当成未来可以替换实现类的脚手架，而没有把它作为程序设计的基础。 举个例子，差的设计者会设计一个带有“开灯”，“关灯”功能的接口，期望其他人能根据这个接口实现出不同样式的开关；而合格的设计者会设计出带“开”，“关”功能的接口：既不会过于抽象，也不会过于局限。 好的设计应该由接口规划骨架之后，依靠实现填充血肉。过于抽象或者过于具体的接口连“骨架”的效果都达不到，更别提实现的好坏了。

发现个现象。 组里遗留了不少祖传的技术债务，即使我天天强调代码质量的重要性，但是在我的眼皮底下，很多人面对债务的时候都选择了“先凑合上，以后再改”。 我对此很不理解，在明知道问题和解决方法的情况下，为什么还要再等等，得到了两类回答： “不敢动，怕一动就出问题了” “感觉太复杂了，这次改不完” 先说第一个回答，在风险可预知、可控制的情况下做改动，比风险不可控的情况下突然某一天爆发当然要好的多。举个例子，如果有个人心脏不舒服，当然是越早去医院越好，早开刀早治疗，而不是等等再说。 第二个，在时间有限的情况下，更好的选择是控制范围，抽出精力去高质量的完成一部分工作，而不是破罐破摔，把所有工作都低质量的完成。没有人天生就能写出好代码，写出100行优质代码的带来的经验，要大大强于10000行垃圾代码。 至于“以后再改”，以我10年的编程经验来看，只会有两种结果： 项目处于成长期，大家都觉着应该好好搞，但是一直被束缚在无穷无尽的杂事里抽不开身大搞一场。 项目处于稳定期，有时间了，但是也没有什么折腾的意义了，有做这个的时间不如开发点新项目。 程序员面对的很多选择都是now or never，要么一次做好，要么一辈子做烂。 以后再改=不改 以后再看=不看 以后再xxx=我就想当个辣鸡程序员 别骗自己了。

分享一个显著提高测试效率的小技巧：写测试文本的时候不要随便写个“test”，改成“测试😀”。

最近有不少视频作者问我微博上应该上传什么样的视频格式更合适，我大概整理了一下，大致可以参考youtube： 容器： MP4封装格式 不含edt list（有些非线性剪辑软件导出之后会插入各种稀奇古怪的edt list，有可能导致视频无法正确处理） 文件以moov atom开始（压缩时使用-faststart参数） 音频： aac或aac-lc编码 声道：双声道 采样率：44.1khz 比特率：最高320kbps 视频： H.264或H.265编码 逐行扫描 high profile yuv420 不支持10bit VBR：crf20或以下(H.265 crf24以下），不设上限码率（推荐使用这种编码方式） ABR：码率限制1080p8Mb以上，740p5Mb以上，480p2.5Mb以上（H.265自行调整） 帧率： 微博目前不支持播放高帧率视频，建议根据视频内容选择24、25或30帧视频。 HDR： 目前微博暂时不支持播放HDR视频。 其他设置： 【上传时选择专辑】【上传时选择专辑】【上传时选择专辑】，重要的事情说三遍。 简单的说就是原始视频质量越高，最终播放效果越好。至于二压，都是几年前的坊间传言，不必当真……

《OKR工作法》，四星。书中的实践指导和踩坑经历有不少启发和可以借鉴的地方。美中不足的是前几章的故事实在是太过冗长了，让我有种在读职场小说的错觉……[汗]

为了统一微博里的所有视频业务，最近组里的小伙伴在讨论拆出一个新服务，但是根据什么来拆服务一直没能达成一致。 有人说为了统一，应该拆出一个“api网关层”，所有调用都要经过网关层，这样就能统一了。 也有人说网关层不能解决问题，应该拆出一个“平台层”，把跟某个具体业务线无关的代码都拆到平台层，这样就统一了。 还有人说平台层不合适，应该在平台和业务之间再拆出一个“中台层”，这样才能适应业务发展。 我觉着造成这种无意义争论的核心的问题有两个。 一个是引入动态链接和远程调用技术之后，一群人分不清楚自己到底是在“拆”什么，甚至简单的认为服务拆分=不在一块部署。 一个是互联网技术概念发展太快，很多人提出了新概念但是没有详细而准确的定义（其实提出的是概念的实践应用），导致出现了各种四不像系统。 我的解决思路很简单：先想明白自己要解决的到底是什么问题，然后牢记一个原则：跟开发有关的问题（复用，灵活性，降低耦合等）应该通过编译期隔离解决，而跟运维有关的问题（上线频率，故障隔离等）应该通过运行期隔离解决。 天天研究新概念并不能帮你理解问题的本质，多做几次有思想的重构却可以。

今天抽空思考了这样一个问题：假如有一个项目，期望是10天做完，做到第5天发现计划定的不准，预计可能要15天才能搞定，这个时候应该怎么处理。 常见的选择有降低标准、加人、加班或者延期。 降低标准看起来是可行的方案之一，所有的程序员应该都经历过“先保进度，凑合着上一版，之后再改造”，但是大多数改造最终都不了了之：真正改造的代价实在是太大，以至于要拿出数倍于第一遍开发的时间与人力把整个项目推倒重来一遍。即使这样，被改造过的项目也很大概率会带着之前错误的痕迹难以消除，不停的消耗后续开发人员的精力。 同时，质量标准又不像进度那样可以量化和快速反馈，很容易就把重构一拖再拖，标准一降再降，等到发现质量问题时，基本标准已经降无可降了。这不仅是对某个项目的影响，而是威胁到团队未来发展的问题。降低标准是个最差的方案。 加人看起来对项目的影响不大，但就像《人月神话》里说的那样，不考虑任务分解的限制和沟通带来的影响，而只是简单的把软件开发的工作量当做人月计算并不合理，我在负责一些项目的时候也犯过这种抱薪救火的错误，大部分情况下，临时加人带来的混乱远大于收益，最终新加入进来的人只能做一些边角工作。加人也不是一个好方案。 而加班和延期都会在相当程度上影响项目质量，并且有各种其他问题（影响健康，或者项目组不接受延期等等），不考虑。 总结下来，要保障项目进度，更靠谱的方式是依靠优秀的、能快速高质量进行开发的程序员。 而我根本没有必要在管理上浪费时间……

这几天一直在考虑明年如何更高效的组织团队。 虽然我一直特别讨厌做管理，但是当团队规模扩大之后，团队的组织架构就会不可避免的越来越深入的影响技术系统的架构；对人员的激励和约束也会逐渐反映到最终团队的成果上。 传统的方式可以按职能划分，比如一群人专门做产品需求，一群人专心做服务改造。 也可以按项目划分，比如某几个人专门做某个项目，另一部分人做通用服务或框架。 无论哪种方式，关键的问题都是类似的。我们也尝试过一些组织，激励和考核的方式，但是团队负责的业务变化快、涉及领域多，再加上高并发高可用与海量数据的大背景，无论如何划分，始终感觉没有能够完全发挥出每个人的能力。 今年比起之前的分任务方式，我更希望能够形成一种接任务模式，每个人可以选择自己的方向和压力，虽然读到过类似的文章，但是想让这种理想化的方式落地感觉还有很长的路要走……

今天周会review了一个不恰当的设计方案，不恰当的核心问题在于没有正确的遵循依赖反转(DIP)原则。 依赖反转对于模块设计和边界划分来说是非常重要的原则，但遗憾的是很多程序员并没有掌握和应用它，甚至认为“面向接口编程就是依赖反转”、“事件-队列模式就是依赖反转”等等。导致了各种设计上的问题，写出的代码难以扩展和维护，甚至出现了“影分身”式、“毛线团”式的设计。 每每想到这些错误的设计都会心痛，心痛啊……

其实有些时候解决技术问题和非技术问题的思路是类似的。 我发现有些同学效率低的原因之一是习惯于“悲观锁思维”。比如说 “这个问题产品之前没交代，我问他了，他还没回我，等他回我之后再继续。” 很多情况下，把悲观锁换成乐观锁效率会高得多，更通俗的说法是“别等了，先做了再说”。 还是前面的例子，找不着产品经理确认需求，那么可以自己考虑产品会提什么需求，提前想好方案，甚至可以写好代码，中间等待的时间就被节省下来了。 接下来的问题是，如果白做了怎么办。这恰好是这个方法有价值的地方：问题使人独立思考，思考使人逐步改进，改进使人成长为决策者。