<aside> 💡 大公司里虽然团队（也可以是人）众多，但是始终可以分成两类：一类是真的想把事情做好；一类是想显得“自己想把事情做好”。
这两类团队（人）很好区分，跟他们合作的时候如果遇到了问题：
第一类团队（人）会站在事情的角度上思考问题，他们会思考你当前遇到的问题，提出方案，然后试图和你一起解决问题。
第二类团队（人）会站在自己的角度上思考问题，他们会思考你当前遇到的问题有可能对他们有什么影响，在此基础上进一步指出和强调你的问题，然后试图让自己跟这个问题撇清关系。
而你往往会发现，随着时间的推移，第一类团队的工作能力，和第二类团队的撕逼能力会同步增长，以至于不管第一类团队做到什么程度，第二类团队都能更进一步的找到合适的逼点撕扯起来，把大家拉回同一个起跑线。
无论过程如何，最终还是会达到一个两类团队都能在公司和平共存的平衡状态，我把这个平衡的状态称作撕逼平衡态。
</aside>
<aside> 💡 技术述职tips
如果不是老司机，老老实实按照描述问题-介绍方案-展示成果这个套路写，并且三者之间必须是有关系的。比如我的成果是计算耗时降低50%，那么方案里要有性能优化的方式，问题里要有耗时高的影响。
提前对着空气讲几遍掌握节奏，按历年的经验，总会有人把答辩的一半时间用在自我介绍上。
避免机械性的罗列工作，等级高的人更需要只讲一件事，其他所有事情都是这件事的分解。
要有意识的区分自己的成果和项目的成果，曾经有个人给我们说了半天docker的先进性，最后发现他做的事是拉了个官方镜像执行了一下，没了。
没事别特么瞎加ppt特效了，屡教不改，脑子疼。
</aside>
<aside> 💡 招聘搞了这么多年，基本上总结出了几条zz不正确的快速筛人心得。
985/211绝大多数比普通大学毕业的人牛逼。
研究生大部分比本科有经验，但是水平更大几率还是取决于学校。
懂小众编程语言的（包括但不限于erlang/closure/rust/lisp等），绝大多数更牛逼。
有个人项目的，绝大多数更牛逼。
有大厂工作经验（尤其是校招过去）的，大多数更牛逼。
水平不太行但是态度明显好的过分的人反而放鸽子的几率更高。
</aside>
<aside> 💡 前几天听到一个观点，最近我一直在琢磨。
原话忘了，大概意思是培养人得给足够的时间和精力一点点磨，不能直接扔给他一个他现在一下搞不定的问题。
算起来，我给几乎所有合作过的人都定下过（对方认为）超过他们能力的要求，甚至wow带团玩游戏的时候也经常因为这种事跟人吵。最后就变成我要向对方证明他其实能做到这件事。
最后要么是证明了其实他可以做到，他错了；要么是证明了他对了，他确实做不到。
无论如何都感觉我在刁难他。
太难了。
</aside>
<aside> 💡 推动部门转用钉钉一段时间了。
算下来，我也算是做过很多次内部运动性质的项目，从上古时期的svn转git，eclipse转idea，升级jdk，上docker，到最近的换钉钉，等等等等。不敢说身经百战，但也绝对算得上有经验的布道者了。
我也目睹了很多一腔热血的年轻人想要推动什么事情，开始的时候热情高涨，搞的头破血流一身伤也没推成，最后变成了坚定的悲观主义者，日复一日的等着给下一个人泼冷水。
我还是要分享一些经验。
首先大部分人其实都是杠精，有了想法不要随便跟人说，你会被带入到“这件事究竟能不能成”的无止境的辩论里。至少要想法初步落地，甚至小有成效再公开，公开的时候也不需要试图说服别人，就告诉他有这么个事实就行了，毕竟事实不容易反驳。
其次要仔细斟酌要和谁说，不同性格的人，不同角度的人对同一件事的看法有可能截然不同。在公司呆久了你一定会找到折腾派，都行派和传统派。早期靠热情和折腾派一起做事，中期靠着既成事实拉拢都行派，后期靠着人数优势发力传统派。
不要试图所有问题都要获得上级的资源支持，就像我之前说的，很多从个人视角出发提出的“效率优化”，从团队或者组织的视角来看的话其实没有价值，只是能让一线员工被压榨的时候快乐一些而已。所以跟上级要支持可以翻译成“我想花点公司的钱来提高我们大家的工作满意度，你看怎么样”，你自己感受一下。
还有就是一定要对自己有点b数，这事到底应不应该做，这是到底能不能成自己要有个基本的判断。如果没成的次数多了就会进入一个恶性循环，基本上翻不了身；而成了的话就会逐渐建立起信任关系，这是布道者能找到的最强武器。一些事情我能推动换个人就不行，不是因为能力问题，而是我有多年累积建立起来的信任关系。
但总的来说，失败又是必然的，偶尔一次运动黄了，坦然面对，虚心总结就好。 毕竟，一两次布道改变不了什么，但是敢于发起下一次，才是最重要的。
</aside>
<aside> 💡 继续昨天思考的话题，“如何判断一个技术团队是否真正缺人”。
问一个团队负责人他缺不缺人，答案一定是缺人，每个人都能说几句缺人缺到崩溃之类的演讲。真正的问题是，怎么判断谁更缺人？
绝大部分人的第一反应都是按加班时长算，但是组织里永远会有劣币存在，他们会把加班当做目的而不是手段，和白天休息晚上装样子干活的人相比，一个正常团队再怎么忙也不可能比专门加班的人还能加班。
按工作量来其实也不现实，除非做完全相同的工作，否则工作量很难横向比较，就比如说前端做一个页面和后台做一个接口的工作量究竟哪个更大，很难讲清楚。这里同样也会出现劣币的问题，一个低效率的团队肯定有更多事可做。
完全撒手不管，谁先招到人算谁的也是个办法，毕竟缺人的团队会更努力招人，但问题同样是，混子有更多的精力招人，而且混子可以轻易的降低标准，招更多更混的人。
我也尝试过把问题反过来思考，不考虑谁更缺人，而是评价每个团队加人之后能够带来什么收益，这个方案看起来更好一些，但是也有缺陷，很多创新和突破并不是天生带着目的的，这一部分没有确定的收益，就很难评价。
我想象中的组织，应该同时足够精简而又足够灵活，能够避免无意义的内耗又能确保个人利益，组织中的每一个节点都存在意义，形成组织的每一个结构也是有意义的。
但是很可惜，这个问题我也没有答案。
</aside>
<aside> 💡 每次一提起效率工具就会有人问“到底这玩意能提升多少效率”。
我思考了很久，得出了三个结论：
对于组织来说，效率的提升绝大部分来自于组织结构，更准确的说是一致的目标、低成本的沟通和敏捷的反馈回路。
对于团队来说，效率的提升绝大部分来自于人员素质。
而效率工具，主要提升的是一线人员的幸福感，为他们节省时间的意义更多在于节省了“他们的时间”，而不会节省多少“组织的时间”。
因此在我看来，在一个大型组织的环境下提出“这个工具能提升多少效率”这个问题，差不多是在问“这道菜加了味精能提升多少营养”一样，认真回答就输了。
</aside>
<aside> 💡 我现在的每日工作安排：
10%的时间思考方案 10%的时间发呆 80%的时间活动颈椎
</aside>
<aside> 💡 今日工作总结。
有同学跟我聊团队配合的问题，说在项目里遇到猪队友感觉自己很绝望。
如果把一个互联网项目比作汽车的话，不同的团队可能一个负责转向，一个负责发动机。都做到三分，汽车只能卖的很便宜；但是一个转不了弯的汽车，配上牛逼的发动机也不会有多少人买。
猪队友对其他人的影响并不是加法，而是乘法。所以，做好自己的事情，然后想办法换个转向，才是正途。
</aside>
<aside> 💡 今天跟人聊到视频播完自动播下一个的问题。
A说这样体验辣鸡的一匹应该赶紧下掉，B说应该做测试对比是否自动播放的数据，C说应该提升后推荐算法准确度。
这个问题有些似曾相识。
我想起来若干年前坐地铁上下班的时候，中关村地铁口是海龙大厦，进出地铁口站了一排各种推销手机电脑的小伙，但凡你跟他们的视线对上就会被一路围追堵截，为了把你拉到店里从哄到劝甚至上手拉扯各种手段全都见过。
店长们肯定知道拉人进店会招人反感，但是拉人能增加收入又毋庸置疑。正面坐拥着中关村的巨大人流，背后感受着jd这些在线平台的快速崛起，如果我是海龙里摆摊的老板，想要经营下去，要如何抉择？
为了声誉不再拉人？给拉不拉人算笔经济账？还是把摊位里的货物重新摆摆？
我觉着可能都没什么用。
摊主能做的只有赶上时代或者被时代抛弃，要做的是投资，哪里是营业额的问题。
</aside>
<aside> 💡 今日工作总结。
跟工作一年的同学聊了聊工作上的困惑，其中一条是感觉很难把控进度，经常会出现以为一天能搞定，结果熬了俩通宵的情况。
其实评估工期是个很隐蔽又很重要的能力，但是很多同学存在一个误区，错误的认为评估工期等于按时完成任务：某一次工期没有估准，吃了亏之后暗下决心，下次一定要吸取教训，不要踩坑，争取提升效率。
其实这是错的，最优先要做的是把工期估准：这一次踩了个坑，多花了三天时间，下次类似的情况就按多三天去评估；这次运气好按时完成了，下次有可能运气不好，那下次就把冗余时间加上。
当事情总是能按时完成之后，再去针对性的优化效率，此时优化效率是水到渠成的；反过来，事情还没能做完就搞优化，事情成不成大部分看运气，必然是不靠谱的。
每个程序员的成长过程中，必然都要经历这么一段区分自己的目标与能力的过程，虽然它无关技术成长，但却一定程度上决定了个人发展速度。
我把程序员工作生涯中的这个过程称为，
寻找b树。
</aside>
<aside> 💡 前几天面试了一些应届的同学。
有的同学专业课1%，有的论文发了一堆，有的bat实习了一年，基本素质都非常强，远超当年的我，看完简历就能直接通过的那种。
问题来了，那我还要考察什么来凑满三十分钟的面试？
我最终决定考察他们的好奇心。
比如，你自己写的这个rpc框架是基于nio异步模型实现的，那么我收到一个网络请求的时候，计算机里都发生了什么事情，最终变成了一次代码回调？
又比如，你的项目基于mysql做了索引优化，能讲一讲加索引之前和之后，从硬件的视角看，一次查询有什么具体区别吗？
再比如，你已经通过redis的zset实现了一个高性能优先级队列，现在的性能瓶颈是什么？如果让你只针对这一个业务场景做优化redis的话，会对跳表做什么修改？
简单的说，都是不同领域的交叉问题，或者如何把理论联系到实践当中。经常问“为什么”的人对这类问题会非常熟悉，而只学不做或者只做不学的人遇到这种问题会比较难受。
好奇心并不会决定他们是否会收到offer，但是决定了在未来五年，十年后他们是否能够不被所谓的35岁问题而困惑，他们是否能够带领某个组织持续进化，甚至决定了是否能够驱动这个行业持续发展。
另一方面，能跟有好奇心的同事一起工作，是一种莫大的幸福。
</aside>
<aside> 💡 最近天天处理各种问题，一次又一次领悟到了这个道理：
很多事情没做好并不是因为真的做不好，而是没能在交付前及时发现问题。
换句话说，
自己做的东西有多少问题，自己心里还是没有b tree。
</aside>
<aside> 💡 今日工作总结，作为团队管理者大概能遇到三种项目。
收获型：扔进去人，返回收益。
黑洞型：扔进去人，什么都没返回。
真理之门型：扔进去人，返回一堆hc。
</aside>
<aside> 💡 昨天晚上到现在反复看了大概五六遍飞猪直播回放的完整版，又去祥子发的微博下面翻完了100多评论和700条转发。
虽然这次被骂的不是微博视频，但是我很焦虑。
最近这半年我基本都被淹没在各种合理或者不合理的需求里，对于基础体验的优化力度放松了不少。
去年我们集团队之力，从需求的缝隙里硬里挤出来的体验优化成果，很有可能被一两个不经思考的需求，或者哪天没测试的一两个bug，未来瞬间就（甚至可能已经）被颠覆掉了。
按去年的经验，用户体验不是憋几个大招就能解决的。难的是改变内在驱动模式和提升外部反馈效率，这也是我下一步的目标。
下半年，且行且珍惜吧。
</aside>
<aside> 💡 封闭开发基本上到了尾声，照例总结一下吧。
先说做的好的，有三条。
首先是坚持了两年多的招聘宁缺毋滥原则明显产生了效果，平时有没有拖后腿的人差别不大，但是一旦要上场打硬仗就会发现一个不靠谱的人能把五个以上同事的效率变成0。
这一次我们作为底层所有核心服务的提供方，十几个人支持了近十个技术团队的底层服务，对接了好几十号人，过程中基本没有明显需求延期和重大bug，其中最核心的效率提升就来自于靠谱的团队成员，当团队里每人都能独当一面时，放心的把后背交给队友是一件非常幸福的事。
其二在于我们没有单纯做需求，而是在需求的夹缝中沉淀下来了一套能够进一步提升效率的系统，让技术的一部分价值能够独立于业务，通过技术建立秩序而不是迷失于混沌的需求，为接下来要做的事情打好基础。
其三关于是我个人管理实践水平的提升。我没有单纯的试图通过996机械式的加班、提高团队工时来赶进度，相反，我在加班的基础上建立了自由轮休制度：每人每周可以自由选择一天，提前下班。事实是，休息变多以后，整个团队的效率飞涨，几乎没再有低级错误，做的决策也都更加合理了，感谢人月神话。
而这次封闭缺点也很明显。
我们又一次没能够一次把事情做好。封闭开发期间很多代码没有单测，设计里遍布妥协和兼容逻辑，很多方案没有完整的分析和思考，肉眼可见的埋下了许多坑。甚至于前面说的能够提升效率的系统，也只是勉强做到了能用，离好用还差了十万八千里。
封闭开发是为了时间，但讽刺的是，我们可能需要用更多的时间，来换回节约下来的时间吧。
</aside>
<aside> 💡 项目时间紧的意思是，要在这个时间条件下拿出你能做到的最好成果，不是时间一紧就要优先选差的方案。
这样说不好理解，我换个说法。
假如上班要迟到了，你还没吃早饭。
这个时候你应该想办法吃点东西别饿着，尽可能在不迟到的情况下保证营养。
而不是第一时间跑去吃屎。
</aside>
<aside> 💡 封闭开发第一周总结。
参与过的几乎所有的跨团队大型项目都会经历不同程度的项目失控，只是失控程度的区别。人月，项目计划或者管理者的雄心壮志都解决不了项目失控的问题。
一周以来我一直在被“未来究竟哪里会出问题”这个念头所困扰，这个念头非常不好，打个比方的话，一线写代码是跟具体问题对打，现在就好像是蒙着眼睛跟空气肉搏。
以至于最近开始因为“不知道自己正在焦虑什么”而焦虑了。。
</aside>