眼前的工作即将告一段落了，想着有必要对这段经历总结一下。写这些并不是为了分享什么有价值的经验，因为这两年最大的体会就是：二手经验不会让人有多大成长，唯有脚踏实地的去经历才能变得智慧。所以反思的目的是为了整理并记录下自己的一些思考，希望自己以后别在同一个地方掉坑。

关于管理

其实从上家公司起，工作内容就开始接触一些管理的事宜了，但属于被强制委托不得不管；换工作后，正好有这么个机会，就想着去争取尝试一下，虽然只有三两个人，但也算迈出这一步了。这么做并不是因为年龄到了，或是工作年限到了。只是因为随着能力和视野提升，总是想着去做一些更有挑战的事情；而有挑战的事情自然有其自身的复杂性。其中包含着大量繁杂琐碎的工作，很多都是自己在过去反复做过很多次的内容，不想自己动手，就只能寻找他人来协助。

我觉得一个优秀的 Leader，应该是自带气场的，并且有清晰的目标和做事原则。能够汇聚诸多追随者。但这种 Leader 在职场中其实很难遇到，至少我遇到的大多数都不是，只不过是一个个高级打工人而已；但于我而言，还是能从他们身上学到很多东西，反面教材也可以是好教材。对于20人以下小团队，总结下来主要有以下这几点：

• 团队目标（画饼）是很重要的，而且必须是确定而且坚定的，不能每天想一出是一出，自己都没头绪。如果所在的环境就很乱，比如自己有个很糟糕的领导，或外部环境恶劣，无法制定出持久的目标，那最好趁早走人。
• 搞清团队成员的个人意愿，为其找一个合适的定位和方向。讲清楚对他的期望。这点和目标一样，是不可以随意变化的。否则下属没办法做事。如果实在找不到合适的定位，说明这个人并不适合当前的团队。
• 用人不疑。如果某一个方向自己懂得不多，确定好方向上的目标，剩下的就是信任。如果就是不放心，就让2个人以竞争的关系做同一个方向。
• 确定内外部协作流程，流程和定位是相呼应的。要对所有具体工作内容有很清晰的理解，否则协作过程中的边界问题，容易出现摩擦。别忘了把自身也纳入到流程之中。
• 明确做事标准，表明自己的态度和喜恶。优秀的表现要得到看得见的表扬；差劲的表现不必惩罚，只需在团队内公开提出即可，诛心已经是很大的惩罚了。Leader的喜恶很影响下属做事的侧重点。
• 如果有下属单纯只是主观（或价值观）上反对团队做事的标准和流程，最好把他踢出团队，强扭的瓜不甜。这种人容易搅乱团队。
• 定期的团建是非常重要的。团建可以消解很多团队内部矛盾。跟合作团队一起团建，也更容易促进合作。再就是可以和大家打成一片，比较方便做事。重要的信息往往都是在外面闲聊时获得的。
• 把控整个团队的对外输出内容，无论是做产品，还是做服务。都要对交付内容有很好的把控。
• 要清楚自己是团队的轴心，以身作则。自身的一举一动可能都会被下属看到，并影响到团队。
• 下属很多时候不会跟领导说实话。

有些琐碎，进一步抽象总结下，自己这两年主要有 2 个大错误。

一是没有清晰恒定的目标，没有很具体地想清楚到底做成什么，导致付出了很多无意义努力。到最后大家都觉得我所负责的方向有点乱，乱七八糟啥都有，还啥都缺，不成体系。但这里很重要的一个原因是我身处在一个混乱的大团队里。

二是不愿意表达，现在才意识到信息的整合、处理、包装、传达是非常重要的；横向要跟合作伙伴表达自己的规划、意愿、态度等；纵向要向上表达自己的规划、成果、难处等，向下传达传达目标、标准、资源等。

关于发展

都说程序员迈不过35岁的坎儿，所以能看到一些人迫不及待地想要挤到管理层，这好像是过去20年互联网人留下的经验。

对此我并没有那么悲观，反而觉得，如果仅仅是因为年龄到了，就挤到大厂的管理层基层，对自己的职业生涯才是最危险的。因为很多差劲的基层Leader表面上管理着团队，实际上就是上层和下属之间的传话筒，团队只不过是靠组织结构聚拢的一伙人而已；目标是上面给的，下属是公司分配的，自身也没有足以影响他人的气场；没有核心竞争力，做这种Leader的危机感要比普通程序员大的多。

就程序员这个方向来说，我觉得 35 岁的魔咒会在不久的将来被打破，这是国内行业发展的必然趋势。现在之所以有35岁危机，根本原因是因为程序员的后备新生力量太充沛了。每年都有大批大批的毕业生涌进互联网行业，有科班出身的，也有半路出家的，都是奔着高薪来的，这里面不乏大量的虾兵蟹将。但由于互联网红利的存在，多么烂的技术都能创造出收益。 随着国家对金融、互联网、房地产的打压，潮水退去，红利消失，新鲜血液会变得越来越少，互联网技术圈也会慢慢朝着高质量方向发展，相信五年后，只要有扎实的技术能力，即便没有跻身到管理层，也能在行业里横着走，想要浑水摸鱼的拿高薪是不太可能了。

关于做事

随着工作经验的增加，发现大家成长路线都差不多，都是踩着一个一个坑走向成熟的。

工作不是做作业

刚毕业的大学生在做事时很容易维持大学里交作业思维。就是上面布置个任务，只要我把工作中核心主体部分完成了，就能拿个90分。但工作并不是这样，作业要考察的是知识能力；而工作考察的是最终的交付结果。比如任务是实现一个高性能缓存系统，如果不把 API 接口及运维做好，内部设计无论多么高大上也是0分。

发现隐性成本

工作上并不是做的事情越多越好，同理产品的功能特性也不是越多越好。我们在做事时，经常会通过引入一个新的工具或新的概念，来解决当前的一些问题。但任何工具和概念的引入，势必会在一定程度上增加系统的复杂度，而复杂度的增加往往会带来新的问题。所以我们必须要衡量，一个新事物的引入，它自身所带来的问题，与目标问题比起来，孰轻孰重。我们遇到的最多的就是成本问题。

比如有人参考网上资料，要引入流式计算去处理日志统计问题；可目前流行的 kafka + flink 会增加下面几点复杂度和成本：

1. 消息队列和流式计算的系统本身维护成本。
2. 机器、带宽等物理资源成本。
3. topic 和各种 job 等虚拟资产的管理成本。
4. 维护和使用的复杂度升高。
5. 数据链路变长，整体稳定性会下降。

我们再对照这一举措所要解决的问题，比如日志量大不大，数据重不重要，统计的意义大不大等。进而才能决定要不要这么做，甚至是要不要做。

有技术热情的人很容易掉进自嗨的坑里，因为技术也是有时髦性质的，自嗨有时是控制不住的。有时为了调动大家做事的积极性，自嗨一下也是没办法的，但重要的是要勇于承担这自嗨的后果，不能等报应来的时候就各种甩锅，甚至拍拍屁股走人了。

注重交付内容

我之前总是单纯的以为，认认真真的把一件事做好，追求极致卓越，就会有更高的回报。但却无数次被现实打脸。因为这里好的标准是我主观臆断出来的，而不是客户标准。

一件事情会有很多个维度，所以讲极致卓越时，一定要有针对性；要看清哪些维度是自己喜好的，哪些维度是客户喜好的。 我们必须要非常清晰地确定要交付的内容是什么，然后才能追求机制卓越。比如DB系统负责人，一味地追求每秒写入最大化；而使用者的数据量可能很小很小，更希望的是DB稳定。错误地追求极致往往是得不到认可和回报的。

总结下来就是一定要很清楚地确定自己要交付的内容是什么，这个内容包含哪些维度，选择最有价值的维度去做极致追求。

其实确认交付内容是一件很难的事情，它包含大量的细枝末节。包括客户的期望是啥？客户如何使用我们的系统？系统如何设计？我们负责维护还是客户自己维护？如何维护？后期如何运营和升级？如何计价？客户把系统用坏了如何解决？

如果就是某一个方面有极大的热情，那么就不应该在乎回报和认可。因为这有些类似于艺术的自我表达了，艺术是不需要被他人认可的。

关于学习

好多人都说程序员有学不完的技术，技术更新迭代的太快。其实都是胡扯。这些花里胡哨的新技术基本都大体相似，也可以说都是轮子。大多数新技术的学习手册，跟家用电风扇的安装手册没什么本质的区别，需要的时候去查阅看一眼就好，这个过程不能称之为学习。

学习其实是一种抽象能力，从繁杂的事务中抽象的理论规律，并能应用于更多的同类事务。其实是一个信息减熵过程。

当我们学习了多个开发语言，多种DB，或分布式系统后，就会发现他们本质上没有太大的区别。架构设计上基本都以低耦合高内聚的原则进行分层，不必拘泥于各种设计模式；性能上就是无处不在的加 cache，大锁换小锁消除不必要的互斥，随机写换顺序写，多线程并行，幂等；db 就是 B+，LSM的各种变体。之所以他们会大同小异，是因为计算机的体系结构是迭代很慢的，十年都不会变一次，而能够最大限度压榨物理计算资源的方案早就被前辈们探索过了。当然更深层次的技术创新也是有很多的，但是在工程领域并不常见，而且创新的频率也没那么高。

分层

分层思路其实是一个非常通用的解决复杂问题的方式。比如管理上的职级划分属于分层，国家机构的划分其实也属于分层，我们做系统架构也喜欢使用分层，一是方便梳理系统本身，二是方便与人员组织结构对齐，三是让系统层级与业务逻辑上的各个步骤对齐。感觉整个人类社会都是按照层级去构建的，只不过维度不同而已。

试错

最后一点关于学习想说的就是，要敢于试错。我觉得人之间最大的差别就是，有些人能用一年的时间经历完别人五年才经历完的事情。勤奋自然是一方面，另一方面就是要敢于试错。其实所有人都期望能把每一件事情做好，但这是不可能的；对于未知的事情我们总是恐惧，怕犯错。但其实很多时候犯错的成本并不高，大不了挨顿批评，扣点奖金。但这个试错经历是很宝贵的。我们可以不那么勤奋，但有想要做或是必须做的事情时，要尽早。一旦做完，下一段剧情就开始了。

阅历使人智慧，生命的时间又那么有限，无需欣赏别人怎样怎样；一切随心而动，不要让念头悬在那里，跟着念头行动起来。