#职场

跳槽时的薪水，由什么因素决定？

你自身的能力（水平、资源、学历等），肯定是决定因素之一，这已经是共识，不再多说。除此以外，跳槽的薪水，还取决于你当前工作的薪水，因为跳槽薪水还有一部分因素是“给你多少钱能让你离开现在的工作”。

水平能决定你是否满足这份工作的要求下限，而现有薪水能决定你在满足要求下限之后，拿到这份工作薪水范围的哪个点。

以一个例子来说明，假设一份工作的薪水范围是1W~2W。同样满足这个工作要求的两个人，一个人现有薪水8K，另一个人10K，假设至少都要涨薪5成才够跳槽吸引力，那么8K的人只需要给12K，而10K的人则需要15K了。讽刺的是，大部分情况下这两人的水平差距也许并没有8K和10K的差距，而仅仅由于上一份工作的薪水就能决定多少钱能挖的动ta了。

因此，跳槽时的薪水溢价，有相当一部分来源于“多少钱能让你离开现在的公司”。

当然，一份工作的吸引力，除了待遇还有别的维度，可以回看前面的文章《选择的维度》，在这里只谈论待遇这个维度。

#博客

上个月写过一篇memcached的文章，最近项目实现了cache库之后，发现很多细节当时理解的并不够细致，于是重新又写了一篇memcached的文章：

https://www.codedump.info/post/20210812-memcached/

这次将slab、分段LRU、读写操作中的锁、安全回收item、hash表的扩容操作等都讲到了，希望以后也不需要再写memcached的文章了。

总体感觉是实现一个多线程安全且高效的cache库还是有不少细节要考虑的，细节是魔鬼。

知乎上看到很好的一句话，“向别人学，跟自己比”，对我这样的后进生很有鼓舞作用。

https://www.zhihu.com/question/359652140/answer/1824572882

#文章推荐

JuiceFS创始人的一篇文章，很同意里面的一句话：“互联网的人口增长的红利结束了，但是数据增长的红利还很足，而且应该能持续很久，甚至不知道会不会有结束的那天。”。前者表现在内卷越来越严重了，后者原因是场景（AI、智能）、上网设备（车联网、物联网）越多越多了。

https://mp.weixin.qq.com/s/AQk7dd2g0MDzYMdwmjzL5g

#项目推荐

之前已经清楚了b-tree大体的算法思想，最近想找一个简洁的b-tree实现看看生产级都是怎么做的，发现一个不错的项目：https://github.com/madushadhanushka/simple-sqlite

看介绍，作者把sqlite2.5里b-tree相关的部分代码抽取出来了，我编译运行了一下用例都能正常跑，代码量不过几千行，就从这里入手开始吧。

按照sqlite官网上记载的发布历史，sqlite 2.5是2002年6月的版本了：

https://www.sqlite.org/changes.html

附带博客里整理过的B、B+Tree算法原理：

https://www.codedump.info/post/20200609-btree-1/

https://www.codedump.info/post/20200615-btree-2/

#推荐

B站上纯纯甘的节目《浮生一日》是我每期都会看的节目，主题是每次采访跟踪一个不同行业素人的生活：

https://space.bilibili.com/110930331

最开始知道这个栏目是看了《国企外卖小哥的一天》，背景是这位小哥由于疫情原因失业，所以找了一份国企的工作；媳妇买P2P赔光了积蓄，赶上老人得病要治疗，所以晚上得出来兼职跑跑外卖。

里面有句话让我感动：“结婚时面对自己媳妇儿最漂亮的时候，你说我愿意和你同甘共苦，然后现在又开始责怪她，那当初又何必说这四个字呢？”

https://www.bilibili.com/video/BV1V54y1h7Zr

这个栏目里还有各色不同职业的人：程序员、投资者、早餐摊位主人...等等。

不同的职业，都有各自不同的生活轨道和选择。

油管上有同名频道：https://www.youtube.com/channel/UCIs3-LcOCdpiGve6yu1-Fug

#可能是错的

人生没有“一蹴而就”这种事，好比软件设计里没有“银弹”：能解决一切的问题的神器。

以前某个工作干烦了，会羡慕另一个人或另一个公司的状态，其实换了工作蜜月期过后，又会面临各种新的问题。类似的，小时候会羡慕别人怎么样，真到了他那个程度，又会有新的烦恼，等等等等。

年轻时总会认为到了某个程度就能解决所有的烦恼，实际并不是这样的。

所以，不存在那么一个状态，你到了这个状态就没有任何烦恼；反倒是，一个阶段有这个阶段的问题和收益。就好比爬一座山，有那座山的风景还有阶梯，然后继续往下走。

除非死了，否则一辈子都会跟着各种问题。与其想着解决所有的问题，不如先调整心态，想想怎样和各种问题共存，在问题的夹缝里，找到自己的方向，做自己想做的事情。

以上结合自己经历和最近的思考有感而发，正好昨天看到了2014年世界杯贺炜解说西班牙与澳大利亚赛后总结的台词（向不太了解足球的同学交代一下背景：西班牙是2010年世界杯的冠军，而在2014年世界杯小组赛上前两场比赛都输了，这场比赛即便赢了澳洲也会在小组赛阶段被淘汰）：

“人生当中成功只是一时的，失败却是主旋律，但是如何面对失败却把人分成了不同的样子。有的人会被失败击垮，有的人会不断爬起来继续向前，澳大利亚队是如此，西班牙队也是如此。我想真正的成熟应该并不是追求完美，而是直面自己的缺憾，这才是生活的本质。罗曼-罗兰说过：“这个世界上只有一种真正的英雄主义，那就是认清生活的真相并且仍然热爱它。”

这一段解说的视频版见：

https://www.bilibili.com/video/BV1cf4y1X7w2

接纳自己的不完美，直面缺憾，热爱生活。

#推荐

这次推荐投资人Naval Ravikant的书《Almanack of Naval Ravikant》，可以在线或者下载免费阅读：

https://www.navalmanack.com/almanack-of-naval-ravikant/table-of-contents

最早知道此人，是看到和菜头翻译的《如何不靠运气致富》（How to Get Rich (without getting lucky)）：

https://mp.weixin.qq.com/s/TfhBCbr8-IoHyPKtB3hTlw

里面给了很多箴言式的建议，比如：

“你不会通过出租自己的时间而变得富有。”

“互联网极大拓展了一个人职业生涯的可能性。”

等等，风格有点像《穷查理宝典》这种充满智慧的书籍。而《Almanack of Naval Ravikant》一书，相当于把这些箴言式的建议，又给展开详细讨论了一下，还加上了作者其他的一些思考。

据说这本书的中文版就要出版了，网上能找到其他人翻译的中文版：

https://www.yuque.com/qingmiyang/naval

个人阅读下来的体验，看原版会更畅快一些。

#博客

新写博客，讲解为什么Raft论文里不允许提交之前任期的日志。这部分论文内容有点难懂，这是因为经常忽略了这个图示展示的是错误的情况，即允许“提交之前任期的日志”可能导致的问题。如果允许这样做，图示展示的是会导致备份到多数的日志被覆盖的情况，这是不允许出现的。

https://www.codedump.info/post/20211011-raft-propose-prev-term/

#冷知识

b-tree数据结构中的“b”到底是什么单词的缩写？

下意识的，都认为是“balance”的缩写，毕竟这是一个平衡的树形数据结构。但是其实，连几位发明人，也从来没有解释过。

有可能是“boeing”的缩写，因为作者当时就职于波音公司；还有可能是第一作者Bayer的名字首字母。

#推荐

《Readings in Database Systems》（数据库圈常说的“小红书”）第五版的在线阅读版，给出了数据库领域常见的问题以及这个领域相关的重要论文，可以当成数据库领域的论文导读吧：

http://www.redbook.io/

（别看我推荐了，其实我也没有看过：）

#推荐

由于经常需要阅读代码，就少不了使用工具来统计一个项目的大体代码量，以做到心里有底。

早期，我使用的是find + grep + `wc -l`等命令的组合来统计。这类基于纯文本的统计，最大的问题是无法将文件中的注释和代码区分统计。

后来，发现了cloc（ https://github.com/AlDanial/cloc ） 这个工具，就一直用来统计项目代码量，看实现内部用的是Perl脚本。

最近，其他朋友给我推荐了Rust实现的tokei（ https://github.com/XAMPPRocky/tokei ） ，这个工具在我的机器上，统计速度是cloc的5倍以上，还有更多的统计维度：空行、注释、代码等等，用法跟cloc大体是一样的。

如果一个产品有各种维度，“快”和“资源占用”少，肯定是对这个产品最开始的印象之一。

我打算全面将统计代码行数这个需求切换到tokei来了。

补充：laixintao为这个工具写了一个图形化展示的辅助功能，见：https://github.com/laixintao/tokei-pie

#不推荐

没有看错，今天这个推送的标签是“不推荐”。既然有“推荐”的东西，就应该有那种我认为名不符实“不推荐”的。

“推荐”或“不推荐”，都是个人主观的看法。我且说一说，读者就权且看一看吧。

第一篇“不推荐”，留给《Database Internals》（简体中文版也已经出版，名为《数据库系统内幕》）这本书。

之所以不推荐，是因为这本书虽然号称“internal”，但是深度方面距离还太远。

本书属于那种典型的“知道分子”写出来的书：什么都能给你涉及一点，但只是隔靴搔痒得点到为止。就好比那些饭桌上能给你侃侃而谈中美形势、台海局势、股市行情等的中年油腻男：什么都能说一点，但是也仅仅局限在“茶余饭后谈资”的程度了。

如果这本书的名字不是“internal”，而是类似“primer”这样的词汇，倒是觉得可以接受，毕竟这个领域的知识点大体能给你科普一遍。但是如果是“internal”，深度还远远不够。

由于之前作者在推特上营销的有点多，于是我对本书的期望值从一开始就挺高，但是当我拿到这本书，想在一些我有疑问的领域想找到深度的解答（比如Btree的实现等）而大失所望时，就得出了前面的结论。

“他什么都懂，直到说到你的领域”，这是我对本书的总体印象。

遂，不推荐。

#杂

“
May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.
”

每次看sqlite代码里的这段话都会肃然起敬，这个相当于把自己的价值观写到了自己的作品里面，随着作品一起发布吧？

喊的口号要跟做的事情对应起来一起看才能看出东西来。比如有的公司是光谈价值观（最受人尊敬的XXX之流），看到作品实则臭不可闻。但是像这样把价值观直接写在作品里，“不但听其言，还能观其行”，这是一件需要更多勇气的事情。

SQLite Blessing license: https://spdx.org/licenses/blessing.html

#杂
上周到知乎上写了一则与公司相关、带有PR性质的回答。

按照我之前的习惯，并不愿意在网上暴露自己的公司，原因很多，主要还是怕麻烦。

换了新工作之后，老板的要求：多在社交媒体上宣传公司，于是上面的习惯就难以保持了。

回到这个问题本身来，我当时的想法是：即便是一个带有PR性质的回答，也并不妨碍说一些真话。于是我整理回顾了一下当时做出选择时的心路历程，以及对这个行业方向的一些思考，写进了回答里面。

脑子里想到一句话来形容：“尽管是预设的舞台，并不影响我表达真实的想法。”（原创）

所以，如果有时候不得不说话，尽量做到说的都是自己认可的话，这种话的维护成本最低，因为能够闭环与自己的价值观自解释。

除此之外，我还想到了另外的问题：假设某一天，我离开这家公司，或者不欢而散，今天写下的这些回答，是不是就变成了到时候打脸的文字？

我的考虑是：做任何事情，遵循当时的想法即可，当时怎么想的就怎么做。瞻前顾后的话，就什么都别做了。

总结下来：言和行都要尽量遵循当时内心的想法，这是维护成本最小的做法。说到底，对当时的自己负责，这就足够了。

最后，吐槽一下知乎：早期好好的一个问答平台，现在成了营销平台，广告、营销满天飞，正经人已经很少到上面写回答了，可惜。

https://www.zhihu.com/question/499510958/answer/2232593756

#推荐
这一次推荐一个人，看过他的文章和代码，以及现实中也算认识了，他更多混迹在游戏圈，圈外的人可能并不是太知道他。

网名skywind3000，他相关的链接有：

知乎：https://www.zhihu.com/people/skywind3000
github：https://github.com/skywind3000
博客：http://www.skywind.me/blog/
推特：https://twitter.com/skywind3000

skywind擅长的领域主要包括：游戏（引擎）开发、网络传输、音视频开发等。这几个方面，他是既有理论技术文章的输出，也有开源项目的，最出名的开源项目当属KCP：

https://github.com/skywind3000/kcp

我认真读过KCP的代码，就是我喜欢的那种风格：小巧精悍，扩展性高，仅有几千行代码量。

他是我认识的人里编码、理论水平都很高的人，推荐关注。

#杂
要么不说，要说就尽量说你真正想的话，是“维护成本”最低的一种办法，因为很容易就能跟你的行为保持一致，毕竟一直装是很难的。

想起来某大V，某次微博里面说：要尽量读英文书，中文都是二手知识。话是说的很漂亮，但是他本人就在某大平台卖课割韭菜。

于是我去回复了一句：你的课也是中文的。遂，被拉黑。

以Git分支的角度来解释一下“言行一致”为什么是“维护成本”最低的办法。

言、行好比是从你的主干分支里拉出来的两个不同的分支，如果出现不一致的情况，那么等到合并回去主干的时候都要解决冲突。于是，言行不一致的情况越来越多，解决冲突时就越来越麻烦，最后甚至可能出现就是解决不了冲突合并不回去的情况，这就变成了要维护超过一个主干代码的情况，所谓的难以“自圆其说”。

而言行一致，就是每次都不用解决冲突就能合并回去主干，你需要的只是维护一个主干的代码即可。这就是“维护成本”最低的办法。

做为一个普通人，幸运的是，我到现在为止还没有遇到不得不说违心话的时候，很多时候有一些我不愿意说的话，我会选择沉默，再或者直接回答不愿意说。当普通人，也是有好处的。

#推荐

输入用户名，找到你在Github上的第一次提交信息：

https://www.amitmerchant.com/your-first-commit-ever/

#推荐

这个页面里对GNU coreutils 8.3每个命令实现都做了详细分析，有整体实现分析图和具体源码解析：

http://maizure.org/projects/decoded-gnu-coreutils/

可用于初学者学习C语言、Linux系统编程时参考。

除此以外，我深度遍历了一下这个作者的其他文章，也是挺硬核的，比如：
http://maizure.org/projects/evolution_x86_context_switch_linux/index.html

作者自己把这一系列文章称为“Decoded”系列文章，我当初网名定为“codedump”，就是因为喜欢把“code”的原理给“dump”出来。

#杂
今天看到心动创始人黄一孟的推特：

“第一次和阿北认识是在十几年前的上海，当时和Mtime的马锐拉三个人约在徐家汇的一个星巴克里，商量如何把豆瓣、VeryCD、Mtime的电影资料用开放协议打通。
那是Web2.0的黄金年代，大家都认为开放是理所应当的，各网站各司其职拼凑起一个更丰富的互联网。无需登录注册的API、RSS、XML导出都是当年的标配。”

https://twitter.com/DashHuang/status/1468043778128711682

想起刺猬乐队《火车驶向云外，梦安魂于九霄》里的那句歌词：“一代人终将老去 但总有人正年轻”。

做为经历过那个年代的人，看到这段文字真是心情复杂。世界真的有在变得更好吗？我没有答案。

#推荐

最近几天，我在各种场合看到了PostgreSQL相关的赞美，比如：

https://www.infoq.cn/article/TKAkZijRFoRGCYrhBYtQ

再比如一位认识的朋友N年前在知乎的回答：

https://www.zhihu.com/question/20010554/answer/15863274

还有一位朋友，去基于PostgreSQL打造的GreenPlum团队面试之后，给出了很高的面试体验评价：

https://twitter.com/yihong0618/status/1467778716981817345

以前只是大体知道和听说而已，现在对PostgreSQL很感兴趣了，有时间也要看看这个神奇的数据库。