70 后都跑哪去了？
这篇讲的是一位互联网“老兵”对自己所在行业中“70后”技术人踪迹的寻觅与思考。 作者从自己公司春节后只剩一位70后同事的“残酷真相”出发，回溯了在洪恩、用友、锤子等公司的经历，发现自己在不知不觉中成了团队里最年长的人。他调研发现，当年那批使用JDK 1.4、HTML4的第一代程序员，并没有消失，而是悄然分流：一部分晋升为大厂高管（如阿里的逍遥子、鲁肃），一部分在技术领域持续深耕，还有不少人转行、投身区块链、回归故里或消失在创业公司的起起落落中。 文章并未停留在感慨，而是深入剖析了这一现象背后的原因：互联网行业本身年轻，早期从业者本就稀少，而行业的剧烈发展又在不断稀释着这些“老人”的比例。作者联想到村上春树72岁仍笔耕不辍的创作生涯，以此反思技术人的职业生命周期——年龄增长并非必然意味着停滞，持续热爱与产出才是对抗时间的关键。 文章结尾，作者将个人“逆行”般的职业轨迹（年轻时专注技术，四十岁后反而迎来更广阔的人生）与村上春树的“特质”（30岁后找到写作方向并坚持一生）并置，留给读者一个开放的思考：技术人的中年并非终点，而是可以重新定义起点、继续前行的生命阶段。
你老了
这篇讲的是一位技术人的“年龄焦虑”与自我和解。作者从自己在用友、锤子科技，到极客邦创业的经历切入，发现自己一路走来，竟从团队里最年轻的变成了最年长的那个——入职极客邦的第一天，就成了公司年龄最大的人。 文章的核心并非抱怨，而是通过这些个人观察与同行趣事，引出了一个更普世的思考：我们是如何看待衰老的？作者坦言，人过四十，所谓的“不惑”更像是接受“有些事再也想不明白”的现实，而午夜梦回时，对青春理想的追问仍会惊出一身冷汗。 但他最终的态度是清醒而积极的。他援引姜文的“不怕老”，提到七十多岁的创作者依然笔耕不辍，并认为当代的技术人，尤其是七零后、八零后，很可能将“精力充沛地工作到七十岁甚至八十岁”。全文用一种混合了自嘲、哲思与幽默的笔调，探讨了成长、边界与梦想的消逝，最终回归到一个朴素的观点：认清年龄的边界，或许才是真正的超越。
How to Install Native Homebrew on an Apple Silicon M1 Mac
在Apple Silicon M1 Mac上安装Homebrew，不少开发者会直接运行官方脚本，结果收到报错提示“Homebrew is not (yet) supported on ARM processors!”。作者从这个常见踩坑点出发，解释了根因：M1芯片采用ARM指令集，而传统Homebrew是为x86架构设计的，直接安装会导致兼容性问题。 文章梳理了两种解决方案。一种是借助Rosetta 2转译安装x86版本的Homebrew，命令只需在官方脚本前加上`arch -x86_64`，简单快捷。但作者指出，这种方式后续通过Homebrew安装的所有软件都会是x86架构，
fbx 到 gltf 转换问题
这篇文章讲述了游戏引擎团队在迁移到 glTF 格式时，为解决美术工具导出支持不足与 FBX 私有格式带来的转换问题所经历的系列尝试。作者从项目背景出发，详细记录了团队评估和使用四个不同方案的过程：先是发现 Assimp 工具臃肿、编译问题多且存在链接失败 bug，因而放弃；继而尝试自行编写 FBX 解析模块，但意识到数据转换的繁杂性远超预期，非长期维护之选；接着采用 Facebook 发布的 FBX2glTF，却在对方停止维护后陷入 bug 无法修复的困境；最终转向 Blender，利用其优秀的命令行脚本支持、官方 glTF 插件以及详尽的 FBX 文档，形成了稳定可靠的工作流。文章不仅分享了具体的技术选型思路与踩坑经验，也反映了从私有格式走向开放标准过程中的现实挑战与务实解决策略。
做连贯性活动 - 读《好战略，坏战略》
这篇文章从作者在微信群看到《美团清华产品课》笔记中提到《好战略，坏战略》一书开始，分享了对该书核心观点的解读。好战略的逻辑结构包括调查分析、指导方针和连贯性活动，其中连贯性活动强调战略必须落地，结合自身特点发挥优势。作者用iOS程序员的类比说明：战略发展应基于已有的“属性”和“方法”，而非随意定方向，避免历史成为包袱。 书中介绍了三种实现连贯性活动的方法：聚焦，如苹果削减产品线、Intel转型微处理器，通过收缩核心业务等待机会；转换视角，如IBM将产业链整合劣势转化为整体咨询服务优势；设计思维，强调战略应精心设计而非投票决定，以保持渐进性和资源聚焦。同时，文章列举了坏战略的特征，如空话、回避挑战、目标不落地等。 通过对比波特的竞争战略，本文从执行层面探讨了战略制定，案例丰富：苹果的成功聚焦、DEC因高管意见分散导致失败等。读者能从中理解如何识别坏战略，并借鉴具体方法制定连贯性活动，在商业挑战中发挥自身优势。
选择开源项目的几点原则
这篇讲的是资深工程师在面对琳琅满目的开源项目时，如何做出不后悔的选择。作者从自己曾受邀为校招生做技术分享的背景出发，分享了沉淀下来的三点实用原则。 核心观点非常明确：选项目，本质上是选“人”。具体来说，一要看项目是否活跃，有持续演进的历史，拒绝“已死”的项目；二要看项目主导者是否善于沟通，这是项目能否健康演进的关键；三要看项目是否专注，解决单一问题的“小而美”项目更便于集成与取舍。 作者特别强调，我们不必苛求代码完美，因为选择使用一个开源项目，就意味着选择了与维护者同行。真正重要的是找到那些勤奋、开明且专注的“合作伙伴”。文中还顺带吐槽了国内某些只发代码快照、缺乏持续维护的“伪开源”现象，让这个选择原则显得更加切中时弊。
在家工作一周年
这篇文章记录了作者从2020年3月开始，持续在家工作一整年的回顾与思考。作者结合2003年SARS的“宅家”经验，原本对疫情持续时间预计乐观，但事实远超预期。文章详细描述了从公司通知可自愿远程办公、自己随后出现流感症状并康复，到逐步搭建起稳定家庭办公环境的全过程。 技术细节上，作者分享了配置居家办公设备时遇到的实际“坑”：例如使用HP USB-C显示器为Pixelbook供电时，发现显示器供电不足，需额外占用USB-C口或使用带供电的Hub；某些设备直接连接显示器无法工作，改用USB-A转C线缆则能解决。这些具体经验对面临类似设备兼容问题的读者有直接参考价值。 生活层面，文章记录了为适应居家状态，在购物（转向农场团购）、车辆维护、个人护理（购置推子自助理发）及家庭清洁（引入扫地机器人）等方面发生的切实变化。此外，作者还提及在加州山火季，如何制定应急撤离清单并检查数字备份，展现了应对突发风险的准备思路。 结尾部分，作者在反思中指出，尽管居家一年完成了不少工作，但疫情无疑打乱了许多计划，也影响了更深远影响力的产生。文章在平静的记述中，流露出对逝去时光的感慨和对行业困境的观察。
面试的艺术 - 如何面试别人
这篇讲的是，作者如何面对自己并非专家的岗位，去面试候选人。他坦言，面试是一门不完美的艺术，很难在短短几十分钟内准确判断一个人。我们能做的，是在有限时间内提高判断的正确率与召回率。 具体怎么做呢？作者的核心方法是“进行有区分度的考查”。他反对那种所有人都能答对或答错的问题。比如用算法题考察工程师的逻辑与智力，就是一种有效的区分手段。同时，面对光鲜的简历，要围绕一个项目深挖细节：问目标、问流程、问数据、问挑战。通过追问“为什么做”、“谁配合”、“最终结果如何”，能有效判断候选人是否真负责、做得好不好。 除了具体的专业技能，作者强调要关注一些基础素质，比如表达沟通能力（注意信息的“密度”）、工作热情、团队精神和学习习惯。最后，他建议将面试问题与经验标准化，形成可共享的“方法论”，并定期复盘迭代，以适应变化。 总的来说，面试不是一次性的考核，而是一个需要持续打磨和反思的技能。作者从实践出发，提供了一套可操作的框架，帮助面试官在不确定中做出更可靠的判断。
程序员职业生涯巡礼
这篇文章是作者基于十多年从业经历的总结，围绕程序员职业生涯的八点核心感想展开，既是对个人路径的回顾，也是对行业规律的洞察。 作者首先肯定了程序员是一个投入产出比高、能创造价值的好职业，并指出它已具备长久生命力，“35岁危机”更多是早期行业的误读。他强调，职业生涯的不同阶段应有不同侧重——写代码并非永恒任务，当角色需要你从更高维度把握方向时，应勇于转型。 文章特别深入探讨了“入行三到五年”的关键探索期。作者认为这段时间对于发现自身特质、建立深度技术栈不可或缺，即便领域知识浩如烟海，这段摸索也是巨大财富。同时，他犀利地指出了专业深度与广度的平衡问题：既要深耕以免缺乏竞争力，又要避免陷入过于冷门的技术孤岛。 在个人技能之外，作者着重谈到了协作与产品思维。他以张小龙等为例，说明优秀的产品离不开程序员与产品经理的深度协同，鼓励程序员主动介入产品全流程。最后，他认为职业规划不必僵化，踏实写好每一行代码、在时代浪潮中把握机遇，本身就是一种可行的规划。 这些源自实践的思考，为身处不同阶段的开发者提供了兼具共鸣感与方向性的参考。
游戏引擎中的资源生命期管理问题
这篇讲的是游戏引擎开发中资源生命期管理的架构演进与权衡。作者从团队实际遇到的问题出发：最初依赖Lua的垃圾回收，但其触发时机不可控，易造成图形渲染卡顿；而随着场景复杂化，单帧内过多的资源API调用甚至导致渲染后端崩溃。 为应对这些问题，团队先后尝试了经典的引用计数方案，但作者认为在Lua框架与内存受限的移动设备上，单纯基于“是否还有引用”来决定资源释放并非最优解。他将资源分为两类：一类是可从磁盘重新加载的IO资源（如贴图），另一类是依赖上下文、难以重建的运行时生成资源。 针对第一类资源，作者提出不应被引用关系束缚，而应遵循LRU原则，允许引擎随时释放长期未用的内存。对于第二类资源的处理灵感则来自imgui：采用“每帧主动创建”的方式来规避复杂的重建回调，再将结果缓存。这样一来，所有资源都可以统一由LRU策略管理，在内存压力下安全淘汰。文章梳理了从全量保留、Lua GC、引用计数到统一LRU缓存的完整思考路径，展现了从具体约束中提炼通用架构的工程智慧。
程序员应该怎样提高自己
这篇文章是一位拥有近30年经验的资深程序员，对“程序员如何提高自己”这一高频问题的系统性回应。作者认为，成长始于对代码优化的乐趣——正是“写出更高效代码”的追求，驱动着程序员自发去理解操作系统、内存模型等底层原理。 精通一门语言是基石，但这意味着要了解其所有特性的代价与惯用法。作者指出，设计模式本质上是语言特定惯用法的总结。而要突破瓶颈，则必须掌握第二门语言，通过对比不同范式来拓宽解决问题的思路。 在掌握具体技能之外，更高阶的能力在于分解问题、保持简洁的架构设计思维。作者强调，真正的简洁源于对优化与代价的深刻理解，而非一味追求技巧。同时，他呼吁重视工具链掌握、脚本编写等“软能力”，并积极参与开源协作，将沟通与理解能力视为与编码同等重要的核心素养。 这些源于长期实践的经验，为年轻程序员勾勒出一条从兴趣驱动到工程思维的成长路径。
工作七年小结: 学习,生活及其他
这是一位有七年工作经验的后端开发者的自述。文章以时间线回顾了他从测试开发转至Python后台开发，历经创业公司起伏后在现公司沉淀的历程，并由此分享了对学习、生活与工作的核心思考。 在学习上，作者形成了两个关键观点：一是从实际工作需求出发，进行“学以致用”的实践循环，避免无效投入；二是跳出日常，从职业规划与行业趋势出发，系统性地构建个人的技能树。他反思了过去盲目追求技术热点、购买大量书籍却转化率低的“盲区”，并推荐了以深度和体系化见长的学习资源。 生活方面，作者强调“follow your heart”做出选择并为之负责，同时要警惕注意力陷阱——通过限制屏幕时间、关掉不必要的通知，将更多精力投入到阳光、运动等真实生活的美好细节中。他提出通过仪式感（如“电影之夜”）打破模式化的僵局。 对于工作，他总结了几点心得：多站在对方角度思考、保持谦虚并真正反省改进、凡事“多走一步”，以及最根本的，建立自己专业与靠谱的口碑。 文章结尾处，作者坦言过往种种皆为积累，未来仍需不断学习与成长，并计划重新拾起笔记录思考。这七年的折腾与沉淀，最终指向一个清醒的认识：规划与持续行动是成长的关键。
OKR 工作法简介
这篇讲的是 OKR（目标与关键结果）工作法。作者从阅读《OKR 工作法》一书出发，结合实践经验，拆解了这个在硅谷流行、后引入国内的目标管理方法。 文章的核心在于阐明 OKR 的独特性：它设定有挑战性的目标（关键结果初始信心指数仅为 5/10），且**明确不与绩效挂钩**，旨在激发团队内驱力。作者详细介绍了其实践工具——一个包含目标、关键结果、本周重点及状态指标的四象限画布，以及每周讨论、更新的流程。 一个重点是 OKR 与 Scrum 的融合。作者认为，OKR（宏观战略）与 Scrum（微观战术）可以互补：在 Scrum 计划和回顾会议中，同步更新 OKR 画布，让日常迭代与长期目标对齐。文章也犀利地对比了 OKR 与 KPI：KPI 易导致数据造假等短视行为，而 OKR 通过断开与薪酬的关联、强调自组织讨论，来避免这一点。它真正替代的，是原本模糊的团队目标透明化机制。 最后，文章也指出了落地挑战，比如组织架构（需要业务型团队）和团队积极性。总的来说，OKR 不仅是团队管理工具，也适用于个人目标梳理，其价值在于将“要我做”转化为“我要做”的清晰路径。
创业笔记 | 从0到1开公司是什么体验
这篇讲的是一位技术创业者从零开始注册公司的真实体验。作者从辞职创业后着手公司注册出发，详细记录了在深圳“自己动手”完成工商注册的全过程，并分享了其中遇到的坑与实用建议。 文章的核心是经验分享：从最初在上海找代理失败，到后来完全通过“广东政务服务网”等线上平台自助完成申请。作者具体介绍了核名查询、使用银行U盾进行PDF数字签名、最终免费获取营业执照的流程。在领取执照后，又自费完成了刻制公章、前往银行办理对公账户的步骤，期间还特别提醒了注册信息隐私泄露的风险——提交申请后不到2分钟，就接到了推销电话。 这篇笔记的价值在于其详实的“手把手”记录，覆盖了从线上申请到线下领取的完整链路，并提炼出使用备用手机号、了解定点刻章机构、准备齐全开户材料等关键注意事项，为准备创业的同行提供了一份接地气的流程指南和避坑参考。
如何在终端显示图像缩略图
这篇讲的是如何在终端里直接预览图片缩略图。作者从之前介绍过的命令行图像查看器Fim出发，引出了一个更轻巧的新工具——lsix。 lsix是一个用Bash编写的命令行实用程序，它的工作方式很像我们常用的ls命令，但专门用来在终端中列出图像缩略图。它基于Sixel图形格式，能自动检测终端兼容性，并智能识别背景色以清晰显示图片。除了支持常见格式，它甚至能处理SVG、PDF等非位图文件。 文章一步步说明了安装过程：先确保系统装有ImageMagick，然后从GitHub下载lsix脚本并赋予执行权限即可。实际使用非常简单，直接运行`lsix`就能查看当前目录下的所有图片缩略图，也可以指定路径或使用通配符筛选特定文件。 作者特别提到，lsix需要终端支持Sixel格式（如以vt340模式运行的Xterm），但安装后会自动提示。最终生成的缩略图清晰度很高，完全不输图形界面查看器，非常适合需要在命令行环境下快速浏览图像的用户。
图解python中赋值、浅拷贝、深拷贝的区别
这篇讲的是Python开发者经常遇到的“坑”：当你对一个列表或字典进行赋值、浅拷贝或深拷贝时，它们背后到底发生了什么？为什么修改一个会影响另一个，而有时又不会？ 文章通过三段清晰的代码示例，逐步拆解了这三种操作的本质。赋值只是创建了同一个对象的另一个引用，两者完全绑定。浅拷贝会创建一个新容器，但容器内的元素仍然是原对象的引用，所以修改嵌套的可变对象（如内部的列表）依然会互相影响。而深拷贝则会递归地复制所有层级，创建出一个完全独立的副本，彻底切断了与原对象的关联。文章还特别指出了关键差异点：对于不可变类型（如字符串），修改会直接替换为新对象；而对于可变类型（如列表），修改操作在原对象上进行。此外，像数字、字符串这类非容器类型，实际上不存在拷贝操作。 作者通过内存地址的直观对比，把抽象的概念变得很具体。理解这些区别，能帮你避免在传递复杂数据结构时，因误操作而导致数据被意外修改的麻烦。
代码不规范，同事两行泪，撸码七宗罪！
代码千万行，注释第一行；编程不规范，同事两行泪。这篇有趣的文章从技术圈广为流传的吐槽段子出发，直指协作中最令人头疼的痛点。 作者梳理了编程世界里的“七宗罪”，将那些看似不起眼、却会累积成“技术债”或团队矛盾的坏习惯一一列出。比如协作时拒绝使用版本控制，让代码合并变成一场噩梦；用 a、b、c 给变量命名，在大型项目中让人抓狂；盲目增加依赖库，甚至不经测试就升级核心组件（比如 React），可能直接引发连锁反应。文章还点名批评了不一致的代码格式、逃避错误处理（尤其要当心空指针），以及在复杂场景下选用不当的数据类型等常见问题。 这些“罪”之所以普遍，正因为它们常常被忽视。文章用生动的比喻和具体例子，提醒我们：代码的可读性与健壮性，往往就藏在这些细节里。遵守规范不仅是为了他人，更是为了一年后的自己不被自己写的代码“气哭”。
10个最“牛叉”的代码注释
这篇文章汇总了StackOverflow上“你见过的最棒的代码注释”投票前10名，展示了程序员们在严谨逻辑之外，极具人文色彩与黑色幽默的另一面。 这些注释远非简单的功能说明。有的像“警告牌”，如耗时39小时优化失败的前人，留下计数器警示后继者；有的则像“骑士宣言”，用史诗般的语言鼓励接手棘手代码的勇士，告诉他“永远不要放弃”。双关与冷幽默也随处可见，比如 `throw up;` 这样的异常抛出，既是代码动作，也是情绪吐槽。还有用 `#define TRUE FALSE` 来捉弄调试者的恶作剧，或是“写的时候只有上帝和我知道，现在只剩上帝知道”的无奈自白。 这些看似不正经的注释，其实深刻揭示了软件开发中的真实场景：面对遗留代码的无力感、与同事跨时空的隔空对话，以及程序员特有的、用代码表达的情感宣泄。它们提醒我们，代码库不仅是功能的集合，也承载着开发者的故事、挫败与坚韧，是理解技术文化一个鲜活而有趣的窗口。
如何使用多种编程语言而又不失理智
如今，许多开发组织都成了“数字多语种组织”。正如人类通晓多种语言能与更多人沟通，开发者引入不同的编程语言，也是为了用最合适的工具完成特定任务。然而，这种多语言环境常是因收购、技术迭代等原因渐进形成的，是一把典型的双刃剑。 文章犀利地指出，失控的多语言堆栈会演变为“数字巴别塔”，给企业带来三重挑战：一是**可见性缺失**，当关键漏洞出现时，企业甚至不清楚哪些应用、哪些库受到了影响；二是**更新成本高昂**，工程团队大量时间被耗费在更新和修复开源工具上，而非编写新功能；三是**重复造轮子**，漏洞修复时常因依赖链变化而需要重新构建环境，白白浪费开发周期。 为此，作者提出了一系列最佳实践：持续监控生产环境代码的风险、保持依赖更新、为老旧技术栈寻求商业支持、标准化构建流程，以及建立统一的包管理源等。这些措施旨在将开发者从繁琐的工具链维护中解放出来，让他们能聚焦于创造业务价值。最终目标是在拥抱语言多样性的同时，通过有效的治理，让技术团队和管理层的工作都变得更轻松高效。
如何使用多种编程语言而又不失理智
这篇讲的是多语言编程环境这把“双刃剑”——它如何让企业变身“数字多语种组织”，又可能因失控而扼杀业务。作者从企业技术栈的自然演进（如并购、技术迭代）切入，指出核心矛盾：开发者为追求“用对工具”而引入多种语言，却给组织带来了可见性缺失、更新维护成本激增、环境难以重建等三大棘手问题，最终可能拖垮整个软件开发生命周期。 文章没有停留在提出问题，而是给出了一套寻找“罗塞塔石碑”的实践方案：从持续监控生产代码风险、建立集中化包管理与更新机制，到通过标准化构建来提升一致性。其核心观点是，企业不应剥夺开发者的工具选择权，但必须用系统化的方法驾驭复杂性，让团队精力聚焦于创造业务价值，而非陷入无尽的工具维护。这对于任何面临技术栈膨胀困扰的团队，都提供了清晰的诊断框架与解决思路。