Intro
新的一年，想做一些有趣的新尝试，其中一个想法就是把每周阅读的一些有趣的文章记录并分享出来，类似于 Newsletter 的形式。
我每天打开电脑的第一件事就是看看 HackerNews，看到一些有趣的项目、文章会做一些记录，正好适合用来分享。
新的一年快到啦，提前祝大家新年快乐啦！🐰🧧🎉🎇
文章
For your next side project, make a browser extension
这篇文章的作者是浏览器插件 Twemex 的开发者，这个浏览器插件的功能是增强 Twitter 的搜索体验，安装好这个插件之后可以很方便地直接输入关键字来搜索某个用户历史发送过的推文、搜索你关注的人的推文，而不用去记忆 Twitter 搜索框的搜索语法。
这个浏览器插件最初只是作者为了满足自己的需求所开发的，因为他发现 Twitter 的搜索功能其实提供了很丰富的搜索指令，例如在关键词前面加上 from:xxx 就可以指定只搜索来自 xxx 的推文，但是 Twitter 并没有很明显地在搜索页面上告诉用户可以这么使用，也没有提供一个很方便的 UI，大多数用户并不知道这个功能，而作者自己平时在发表推文的时候，经常会使用这些高级搜索指令来搜索自己过往所发送的相关推文，于是他就开发了这么一个小插件。
但一开始他并没有进行什么推广，相反的，他只是偶尔会在自己的 Twitter 上分享这个插件的截图，然后就有人好奇地问他：我能否也使用这个插件。于是作者开始和这些用户沟通交流，了解他们的需求，逐步完善了自己所使用的这个插件，并通过 Twitter 召集了 100 多个感兴趣的用户，让他们成为首批测试人员，同时通过 Twitter 的 DM (Direct Messages) 和这些用户保持持续的沟通（作者这里提到，因为 DM 的非正式性，不需要像邮件、电话等联系方式那样每次都得写很正式的回复，这让他觉得很轻松，他可以通过 DM 同时处理好多人的问题）。
用户多起来之后，作者开始考虑优化这个插件的用户体验，他最先从 UI 开始润色，让插件使用起来像是 Twitter 原生就提供的功能一样，这样用户使用起来会觉得这个插件就应该是 Twitter 的一部分，减少插件被用户禁用、卸载的概率。
一年后，这个浏览器插件已经拥有超过 20k 的用户了，甚至有很多用户表示愿意为这个插件支付 5$ 每月的费用。后来一家专注构建 Twitter 相关产品的团队联系作者，收购了这个插件。
作者认为，从浏览器插件开始做自己的 Side Project 是一个不错的主意：
从 0 开始要创造出一个变革性的软件很困难，就算你想到了一个能改变世界的 idea，通常也需要冒很大的风险，付出巨大的努力才能成功。相反的，对现有软件的改进的想法却很容易想到，每个人或多或少都会抱怨自己日常所使用的软件有这样或那样的不足，这些抱怨汇集起来就足够形成一个插件的原始想法。
不需要投入太多的成本（作者称为"Easy operations"，但我理解为不需要投入太多的成本），浏览器插件的开发通常不需要有自己的服务器，也不需要考虑用户数据的存储。大多数时候，对某个现有产品的改进只需要利用现有产品提供的服务就足够了，基本上不需要部署服务器来存储数据，这就不用考虑很多很复杂的系统架构问题，也不需要考虑成本问题，只需要专注于插件功能的开发。
容易成长。相比于构建大型软件，构建浏览器插件可以很快速地从一个简单的想法、操作开始，很容易就能成长壮大。（类似于，有创意、有想法的时候先快速做一个MVP 出来验证自己的想法，验证成功之后再考虑后续的发展、壮大，能规避一些不必要的风险，也能快速验证自己的想法是否可靠）
但同时，浏览器插件也存在一些风险：
- 平台风险
- 如果 Twitter 不喜欢，Twitter 随时可以让这个插件无法正常工作
- Twitter 每天都在发生变化，插件需要不断进行修改来适应 Twitter 的变化
- Chrome 插件平台存在一些问题
- Chrome 插件平台依赖于人工审查，人工审查具有很大的不确定性（审核时间的快慢、审核能否通过）
- 我之前在博客里面提到的 Google 对于浏览器插件规范 Manifest V3 的推动，限制了浏览器插件的权限，导致浏览器插件能做的事变少了
我的一些想法：
- 作者的这个插件最初只是自用，也没有进行宣传，反而是在自己的社交媒体上发表推文而积累到用户的，作者的 Twitter 有 8k followers，平时多分享、多写一些有价值的东西，经营一个自己的社交账号真的蛮重要的，这些关注随时都可能给自己带来意想不到的惊喜
- 找准用户的痛点很重要，多和自己的用户沟通
The internet wants to be fragmented
这篇文章讲的是世界互联网正在变得越来越碎片化。
作者提到一个现象是 Facebook 和 Twitter 这类中心化的平台似乎越来越不受年轻人的喜爱，相反，Tiktok、YouTube、Snapchat、Instagram、WhatsApp、Signal、Discord 等 App 正在年轻人之间变得越来越流行。
Facebook 和 Twitter 的共同点是：中心化，平台上的内容会受管理者喜好的影响，例如 Elon Musk 可以随意 ban 掉批评他的记者的 Twitter 账户，言论并不总是自由的。
相反的，例如，TikTok 和 YouTube 更类似于电视、广播和传统的单向推送媒体，内容纯粹由算法驱动，而不是基于用户分享所驱动；Snapchat 和 Instagram 也更侧重于人与人之间的互动，而不是公共讨论，以及，即时通讯 App 也正在变得越来越流行。（我的理解：人们越来越趋向于使用一些更小尺度、更小众的社交媒体，在这样的社交媒体上人与人之间的联系更紧密，也更容易找到自己喜欢看的东西）
这些越来越流行的平台的共同点是碎片化 (fragmentation)，人们受够了中心化平台的各种争议、漫骂以及监管，转而走向更小的群体组织，例如可能是小众爱好的群体、志同道合的群体等，大家聚在一起，可以在这样的小众社区里互相分享自己的观点，大家都能看到自己想看的内容，如果哪天觉得不喜欢了，就可以随时转移到其他小社区里面。
现在的 Twitter 就像是一个城市的中心广场，而这些 app 就像一个个的小城镇。这反而回到了互联网最初的本质，是碎片化的，大家可以随时把自己的所知道的信息共享出来，不喜欢了也可以随时换到另一个地方。Disagreement in society is necessary for progress, but it’s most constructive when it’s mediated by bonds of trust and affinity and semi-privacy. Our boundaries will always rub up against each other, but we need some boundaries.
很喜欢题图中的一段话：
15 years ago, the internet was an escape from the real world. Now the real world is an escape from the internet.
We invested 10% to pay back tech debt; Here’s what happened
这篇文章，作者讲述了他们团队花费 10% 的时间用于偿还技术债的故事。
任何一个维护过一段时间的软件系统，都会随着时间的增加逐渐变得"腐烂"，这种现象被称为 bit rot 或 software entropy，具体表现有：
- MTBF (mean time between failure) 下降：软件的失败次数变得更加频繁
- LT (lead time) 增加：implementation, review, deploy 和 release 所需的时间，会随着时间的增加而不断增加
- 效率下降：$\frac{价值}{付出}$ 的比例不断降低
- TTR (time to repair or remedy) 增加：修复软件中的缺陷并确保它不会再次发生所需要的时间变长
- TTFC (time to first commit) 增加：用于衡量新人加入代码库的效率的指标之一
而引起这些问题的原因一般是：
- 外部：runtime、操作系统、依赖可能随着时间不断发生着变化，开发者需要不断适应这些变化
- 内部：错误、config drift、技术债务
- 混合：需求的变化速度过快
作者的团队有开发并维护着两个大型的全栈应用程序，每个应用程序都有 +180K SLOC，但项目的领导并不关心代码质量，往往偷工减料，跳过测试，只要能按时交付即可，这让这些程序变得摇摇欲坠。
最终项目的开发者和管理层沟通，确定花 10% 的时间专门用于解决技术债务。从此，每隔一周，程序员们就会举行一次 “Tech Debt Friday” 活动，在这一天里，不能做一些常规的需求，而是专门用于处理技术债务。
随着时间推移，这项 “Tech Debt Friday” 活动对作者所在团队的回报是巨大的：
- 他们很快偿还了技术债务，通常不会超过 10 天
- 他们可以一起调查代码库，并了解代码的历史，而不用按照某种固定的流程
- 可以有时间整理文档，标注一些不会重构或删除的内容
- 可以做一些更有意义的事情，例如改进测试、linting 或者是 CI/CD 管道，来防止错误或者降低错误成本
- 通过团队成员直接的协作处理好技术债之后，他们能够更快地完成他们日常的常规工作，因为他们在处理技术债的时候，对代码有了更集体性的理解
- 代码的设计和架构变得更加清晰，使得他们能够在时间紧急的时刻做出更好的判断
- 这种管理层对开发者的提供的自由和信任提升了团队精神
- 公司的其他团队也开始试验 “Tech Debt Friday”
20 Things I’ve Learned in my 20 Years as a Software Engineer
I still don’t know very much
在软件领域，无论往哪个方向看，都有广阔的知识远景，并且在日益扩大。
这意味着不同的人在相同的职业生涯中度过数十年，仍可能产生巨大的知识差距。
越早意识到这一点，就能越早开始乐于向他人学习和教导其他人。
The hardest part of software is building the right thing
你可以设计出世界上技术最令人印象深刻的东西，但却没有人愿意使用它。
设计软件主要是一种倾听的活动，我们需要成为软件工程师、心理学家和人类学家。
在软件设计过程中的投资，无论是通过专门的用户体验团队还是通过简单的自学，都将带来巨大的回报。
The best software engineers think like designers
伟大的工程师会深入思考他们代码的用户体验问题。把用户的需求放在心上，是好的用户体验的核心。
The best code is no code, or code you don’t have to maintain
Software is a means to an end
任何软件工程师的主要工作都是交付价值。
Sometimes you have to stop sharpening the saw, and just start cutting shit
有些人倾向于跳进问题中，直接开始写代码。
另一些人则倾向于研究，并陷入分析瘫痪。
在这些情况下，为自己设定一个期限，然后就开始探索解决方案。当你开始解决问题时，你会很快学到更多东西，这将引导你迭代出一个更好的解决方案。
If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Every system eventually sucks, get over it
Nobody asks “why” enough
We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
对自己的工具或者如何构建软件没有任何意见的工程师是很让人担心的。作者说他宁愿有人给他一些"我不同意"的意见，也不想要有人和他说"我没有意见"。积极寻找别人如何使用与你不同的工具和技术来完成任务，能很快提高你的技术水平。
People don’t really want innovation
人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇感。
如果你真正进行创新，并且改变人们做事的方式，预计会有大量的负面反馈。
如果你相信你正在做的事情，并且知道它将真正改善一些事情，那么请做好准备迎接一场漫长的战斗。
Your data is the most important part of your system
系统中的数据可能会比代码还更长寿，花时间和经历保持数据的有序和规整，从长远来看会有很好的回报。
Look for technological sharks
Don’t mistake humility for ignorance
Software engineers should write regularly
软件工程师应该定期写博客、写日记、写文档，做任何需要保持书面沟通技巧的事情。
写作可以帮助思考问题，并帮助自己更有效地与团队和未来的自己沟通。
良好的书面沟通技巧是任何软件工程师都需要掌握的最重要的技能之一。
Keep your processes as lean as possible
Software engineers, like all humans, need to feel ownership
Interviews are almost worthless for telling how good of a team member someone will be
面试的最好只是用于了解某人是谁，以及他们对某个专业领域的兴趣如何。试图弄清楚他们将来会是一个多么好的团队成员是没用的，因为没有人会在面试的时候告诉你：他们不可靠、滥用职权、华而不实，或者从不按时出席会议。
Always strive to build a smaller system
视频
PaperPaul YouTube Channel
发现一个立体折纸爱好者的 Youtube Channel 叫 PaperPaul，里面有个视频展示了很多他喜欢的立体折纸作品，都设计得十分巧妙：