背景¶
在学习过程中，经常看到许许多多比自己优秀的人书写的博客。其内容往往给我以或是启迪、或是灵感、或是警醒。但是网络环境的不稳定性导致博客可能在若干时间后消失或是删帖等种种原因后不可查询。因此为了自己整理复习又或是为了保存这些“师傅”们的教诲，特在本篇博客中记录偏向总结性质的内容，并结合自己粗浅的见解，形成自己的输出，以供后生查阅。感谢各位前辈在网络上的分享！
2021 年终总结：记我在清华 Apache IoTDB 组的成长[1]¶
从要我干什么到我能干什么¶
我不再荒废太多时间在娱乐上，而是思考自己当前能做什么有意义的事情。我不再将一些工作视为是锅，而是将其视为成长的机会。我不再低头闷声学习，而是开始热衷于交流，反思，请教和提问。我不再认为自己当前仅仅专注技术就够了，而是开始学习一些有关管理，表达，领导力的技巧。
读研三年，仅仅拿个学位在我看来还是有些虚度年华的。在未来我希望自己能够继续跳出自己的舒适圈，继续折腾和挑战自己。
其实这点类似《软技能》一书中的一个观点，就是把自己当做一个公司来经营，非同质化。这里还加入了自己的主观思考，考虑工作能做能推动自己的成长，进而在工作上获得一些成就。
另一点就是上面说的有关管理，表达，领导力的技巧，这个我还需要加强，在工作后也仅仅是感受到了，但是没反应过来。看到文章后领悟了过来。
人与人最大的区别是认知¶
人与人最大的区别不是出身，不是社会地位，而是认知。同样的一件事，认知不同的人会有不同的看法，有的人视之为机会，有的人视之为灾祸，最后当然会有不同的结果。
就我个人的想法而言，多跟大佬们请教，怀着开放的心态去学习，把批评当做进步的机会就是提升自己认知的绝好方式。
重点是怀着开放的心态去学习，把批评当做进步的机会就是提升自己认知的绝好方式。
找准自己的兴趣点并持之以恒的专注¶
但所有老师均认为保持长期专注是很重要的一个特性：只有长期的专注才有可能做到顶尖，这一点上没有捷径。
这个回答也引起了我强烈的共鸣，不论是在学术界还是在工业界，很重要的一点就是找准自己的兴趣点。一定要找到一个自己感兴趣的方向，通俗点来说，就是找到那种自己在休息时间也愿意去学习去钻研的兴趣点。这样，我们不仅在工作学习时更有热情，而且自己的价值也会随着长期地专注而得到不断增长。
拒绝无效内卷¶
尽管长期地专注很重要，但无效内卷是不可取的。从长远来看，无效内卷会影响我们的工作热情并破坏团队氛围，最终一定是得不偿失的。不同人对”无效内卷”的评判标准不同，但我觉得每个人都应该有意识的去反思自己到底是不是在无效内卷。如果是，那一定要想到缓解甚至拒绝它的方法，包括但不限于和 leader one-one，润等。世界这么大，要相信自己一定能够找到立足之地，没必要恶心自己。
脑袋决定屁股，屁股驱动行为¶
今年阅读了桥水基金创始人瑞·达利欧的《原则》这本书，我被其中描述的创意择优像家一样的工作氛围所深深吸引，幻想着自己未来能到这样的公司工作。
然而，我和很多读者一样都进入了相同的思维误区，那就是等着别人来营造这种氛围而我们坐享其成。既然每个人都喜欢这样的氛围，那么为什么不能在自己力所能及的范围内行动呢？
尽管营造团队氛围每个人都有责任，但我还是觉得考虑自己职业规划时一定要优先考虑关注员工成长的公司，否则推进这种氛围可能会非常难，这会进而影响自己的热情和产出。我个人是非常不认同企业付高工资就可以将工程师当做工具人来使用的企业文化的，员工和项目只有共同成长才有可能建立一个长期高效持续创新的团队，也只有这样的团队才值得大家齐心协力为之奋斗。
真诚坦率¶
当我们能够真诚坦率的公开我们的工作内容和进度时，一方面会使我们更容易获得上级和同事的理解信任，另一方面也会促使我们减少摸鱼时间，更加重视自己的单位时间产出并努力提高自己的工作效率，而后者在我看来是更关键的。人都会存在惰性，这样的机制可以帮助自己克服惰性，追求效率至上。
不要妄想别人帮自己指出最优解，路都是自己走出来的¶
对于大部分人来说，路都是要自己一步步走出来的，不要妄想有个大佬能直接给自己指出全局最优的捷径。保持开放的心态，一直学习一直反思，多向大佬们请教，能走出一条局部最优解的路就已经很不错了。
养成定期反思的好习惯¶
犯错误不可怕，不反思错误的原因并进行针对性的分析和改进就很可怕了。
就跟当年高考刷题一样，悲观的人认为题量是无尽的，怎么刷也刷不完；乐观的人认为题量是有尽的，刷一道少一道。我是乐观的人，我坚信这些定期反思加上我们的长期专注一定会迎来收获。
了解技术细节最好的时机有两个，一个是过去，一个是现在¶
在写代码的时候我们常会碰到一些技术细节（比如 git 命令，比如不同 IO 的区别），有些人认为这些细节无关紧要将其置之不理，而有些人非常重视这些细节并将其很快学懂。我觉得面对这些细节问题的态度是决定技术水平是否会停滞不前的重要因素。
了解技术细节最好的时机有两个，一个是过去，一个是现在。当遇到技术细节时，可以简单评估一下学习成本。如果很低（小于 1 小时），则可以在当天尽量将其搞明白。如果比较高，则可以将其放在预计学习的列表里面，定期抽出一些整块的时间集中学习。
诚然，在刚开始编程的时候就这样会比较累，因为什么都不会。但只要能够长期坚持学习，遇到不懂技术细节的概率会越来越低，自己的水平也会越来越高，形成的正反馈效应也会强化这一过程。
不要给自己设限¶
在大型基础软件里，往往不同的人会负责不同的模块。如果模块解耦做的比较好的话，可能不同模块的同学不会有太多交流。比如在刚进组的时候我就只关注了分布式模块的内容，有关单机任何模块的功能和 bug 修复我基本都不会关注，这也使得我进组都一年了还不太了解时序数据库是什么。现在回想当时的自己还是太傻了。
之前振华组里的明亮学长在做秋招分享时介绍到，他认为互联网跳槽之所以容易涨薪涨职级，就是因为跳槽人往往对其所在组工作具有比较深刻的认知，这些认知可能是几十人的团队踩了数年的坑才提炼出来的经验，而只要在这个团队待几个月说不定就能够学懂大半了，这些经验可以为下家公司创造很大的价值。
基于这样的思路，我们就不应该给自己设限。在自己力所能及的范围内去关注一下其他模块的工作往往不需要很多时间，但对于自己的职业发展一定是有益无害的。这里我就非常佩服和我在一个组的苏总，他就是典型的不给自己设限的人，他一人为 IoTDB 带来了 UDF, Trigger, Select into, Continuous query, 算数表达式等高级特性，写入，查询，生态工具这些模块他都碰过。尽管他现在非常忙，但我们这一届的同学毕业后对 IoTDB 了解最深的人很可能就是他，那他的价值就会非常高了。
多给自己一些正向反馈¶
这个感悟其实涉及到了一些心理学的技巧。在学习计算机的过程中，往往会遇到很多棘手的问题，而这些问题很可能会影响学习热情。很多小白在刚入门的时候遇到一个棘手的问题就被劝退了。因此我们需要定期给自己一些正向反馈，这些反馈包括但不限于做一个完整的 project/feature，解决一个别人解决不了的 bug，参加各种比赛获奖，做 talk，发论文等等。通过这种外在的对自己的认可，我们也就能继续保持着学习热情。这一点黄东旭老师在 VLDB summer school 的 panel 上也有提到。
不能只有输入没有输出¶
在工作学习中，不能只有输入没有输出。我对输入的理解是指花费的时间成本，对输出的理解则是明确的他人可以看到的工作量。
为什么要强调这一点？因为我刚到实验室就是这样的状态，后面才慢慢意识到并进行了改变。比如对于一个调研的工作，往往会花费很多时间，调研完后自己可能感觉学习到了很多东西，但也没有明确的输出（包括但不限于分享，阅读笔记，解决实际问题等等）让别人看到，过一段时间可能自己又忘了。这不仅会导致别人丧失对自己的信任，也会导致自己忽视自己的单位时间产出，形成过一天混一天的惰性思维。它们都会使得自己丧失进一步成长的机会。因此，定期适当地输出是非常重要的。
敢于不卑不亢地分享自己的想法¶
对于技术问题，我们要敢于不卑不亢，就事论事的分享自己的想法。如果我们的想法是正确的，这样能够不断竖立自己的个人影响力。如果我们的想法是错误的，这样也能够早点遭致批评来纠正自己的错误想法。无论如何对自己都是有益无害的。
养成闭环的做事习惯¶
养成闭环的做事习惯非常重要，这有利于自己在同事中建立信任，塑造自己靠谱的形象。
一个新功能的开发工作，从接受，需求，调研，设计，实现，测试，review，合并到最终汇报要形成一个闭环。我在刚开始参与社区的时候对这样繁琐的流程非常困惑，感觉没有什么意义。随着维护项目经验的积累，我逐步意识到了这些都是过来人的智慧。
乔老师常给我们介绍说做事要做到”事事有回应 件件有着落 凡事有交代”，务实的说，很难对所有的事情都做到这种程度，但我们可以怀抱着这样的期望尽力做到这样，至少也得把重要且紧急的事情做到这个地步。养成这样的习惯对于自己的职业发展绝对是有益无害的。
开源铸就了数据库最好的时代¶
作为学生，这也是我们迅速成长的最好时代。我们完全可以参与开源社区，迅速提升自己的能力并认识一批志同道合的朋友，我就是开源的典型受益者，不论是 Talent Plan 社区还是 Apache IoTDB 社区都让我受益良多。
此外，站在巨人的肩膀上非常重要。我们如今身处开源的时代，很多资料都是公开的，一定要避免闭门造车。多了解其他系统，多交流，多调研，这对于个人和项目的发展都是有益无害的。
稳定性可维护性大于性能¶
当修 bug 次数多了之后，我逐渐意识到软件工程的重要性，并开始思考项目不稳定的根因。
OceanBase 的杨传辉老师提过一个观点：每个系统设计时都需要考虑架构、稳定性和性能，这三者之间的关系是什么？一个经典的规律是“把稳定的系统做高效，远比把高效的系统做稳定更容易”。最难的是从 0 到 1 把系统做稳定。有了稳定的系统，接下来逐步优化性能往往会比较顺利，直到遇到系统架构的性能天花板。因此，系统架构设计之前，首先要考虑清楚系统的目标和性能天花板，接着基于正确的架构把系统做稳定，最后优化性能。
我个人非常认同这个观点，大型基础软件的性能和稳定性可维护性往往存在一个不那么明显的 trade-off。在开源软件里，要实现新功能或者重构，一定要优先关注可维护性和稳定性。实现一个性能最优但模块耦合不好维护的功能对项目的伤害是非常大的，甚至可以被称为技术债，这会大大影响开发者的热情并辜负客户的信任。先实现一个 naive 但好维护几乎没有 bug 的版本，逐步的去优化性能，对于开发者和客户来说都是一个正向反馈的过程，这对于社区的发展也是很有帮助的。这里我就非常喜欢 TiDB 社区的方式，模块解耦做的比较干净，从 3.0 到 4.0 再到 5.0。每个版本都有巨大的性能提升，社区也越来越好，这就是一个明显的正反馈过程。
至于如何进一步提升系统的稳定性，在 VLDB summer school 的 panel 上我请教了黄东旭老师，他分享了 PingCAP 现在已经有几百台测试服务器日夜不息的进行测试，同时每年 PingCAP 为了稳定性付出的成本（包括硬件成本，人力成本等）已经达到了总支出的 30%~40%，而这依然还没有让他满意。由此可见，稳定的产品一定是大量的测试打磨出来的，没有太多捷径可走。当然，作为写代码的工程师，多反思总结，不断提升自己的技术水平，也能够对项目的稳定性做出自己的贡献。
创新往往来自假设的改变¶
在今年的 VLDB summer school 上，有一个观点始终被提及：”创新往往来自假设的改变”。这个世界本来并不存在什么假设，假设是人类描述自然规律时的前置条件，而这个前置条件并不一定绝对正确，也不一定一成不变。不论是做学术还是做产品，可以时常想想假设在部分场景是否已经发生了变化，这其中可能蕴含着巨大的创新。
参考文献¶
2021 年终总结：记我在清华 Apache IoTDB 组的成长，2022-1-24 ↩︎
