为什么我开始减少逛技术社区，而是去读非技术的书？
我得承认，我有过很长一段时间的 技术社区上瘾。
每天上班第一件事，就是打开掘金、Hacker News、InfoQ，把热门文章刷一遍。通勤的地铁上，也要用手机看看今天又出了哪个新框架的测评、哪个Vite插件又有了更新。
我生怕错过了什么，感觉一天不刷，就会被飞速发展的技术时代抛弃。这种信息焦虑，我想很多工程师都有。
但大概从去年开始，我刻意地减少了这个仪式。我把每天早上刷文章的一小时，换成了读一些看起来和编程八竿子打不着的书。比如，心理学、经济学、历史、甚至小说。
一开始只是想换换脑子，但慢慢地，我发现，这些非技术书，反而帮我解决了很多工作中遇到的、最棘手的技术问题。
这篇文章，就是想聊聊我这个转变背后的思考。
技术的天花板
工作了五六年后，我遇到了一个很明显的瓶颈。
我发现，再多学一个JS的新语法、再多会用一个Vite插件，似乎都不能让我的能力产生质的飞跃。我的技术深度和广度，足以解决日常工作中99%的技术难题。
但我发现，工作中真正难的，往往不是技术本身。而是：
- 为什么我们团队的沟通效率这么低，一个简单的需求能来回拉扯好几天？
- 为什么这个看似简单的项目，开发过程中总是不断地范围蔓延？
- 我该如何向非技术背景的老板，证明这次重构的必要性和长期价值？
- 面对一个全新的业务，我该如何设计一个能在未来3年内，适应各种不确定性变化的技术架构？
我意识到，这些问题的答案，在MDN文档里、在Stack Overflow上，是找不到的。它们是关于人、关于系统、关于决策的复杂问题。而我当时的技术知识库，对解决这些问题，几乎毫无帮助。
我的书架，以及它们教我的事
于是，我开始漫无目的地，从技术之外的领域寻找答案。下面，我想分享几个对我影响最大的领域和书籍。
心理学，理解人
- 推荐阅读：《思考，快与慢》、《影响力》、《非暴力沟通》
作为工程师，我们习惯于和确定性的机器打交道。但我们的工作，却无时无刻不在和不确定的人打交道——用户、产品经理、同事、老板。
心理学，尤其是认知心理学，教会我理解了人性的非理性。
- 理解用户：读了《思考，快与慢》后，我开始理解为什么用户会做出那些不合逻辑的操作，为什么有时候更优的设计反而没人用。这让我在做UI/UX设计和评审时，不再只是一个技术实现者，而更能代入用户的直觉系统去思考。
- 理解同事：读了《非暴力沟通》后，我改变了我在Code Review里的沟通方式。我不再说“你这里写得不对”，而是说“我看到这个实现，我担心在XX场景下可能会有风险，你觉得呢？”。我发现，当我开始关注对方的感受和需要，而不是直接评判时，技术沟通变得顺畅了许多。
系统思考 看透架构的本质
- 推荐阅读：《第五项修炼》、《系统之美》
系统思考，教会我最重要的一个概念：世界不是由一条条独立的因果链组成的，而是由一个个相互关联的反馈回路组成的。
这个思想，彻底改变了我对软件架构的看法。
- 理解技术债：我不再把技术债看作一个孤立的坏代码问题，而是把它看作一个会自我增强的反馈回路。坏代码 -> 开发效率降低 -> Bug增多 -> 救火时间增多 -> 更没时间写好代码 -> 坏代码更多。这个循环一旦形成，不从外部打破，系统就会慢慢崩溃。
- 做出更好的技术决策：我不再追求完美的、一步到位的架构，而是去寻找那些能适应变化的、演进式的架构。我开始用机会成本去评估技术选型，用延迟和滞后效应去理解一个技术决定可能在半年后带来的影响。
历史/传记 获得古人的经验和战略
- 推荐阅读：《人类简史》、《罗马帝国衰亡史》、各种历史人物传记
历史，是研究成与败的宏大案例集。它能让你跳出眼前的一个个项目，去思考技术浪潮的更迭。
- 获得历史感 ：为什么jQuery会衰落？为什么React的Hooks范式会成功？为什么当年的AngularJS会失败？这背后，和历史上的技术革命、王朝兴衰，遵循着相似的规律——它们是否解决了当时最核心的矛盾？它们是否降低了开发成本？
- 做出更聪明的长期判断：这种历史感，让我在做一些长远的技术规划时，能更好地判断什么是真正的趋势，什么是短暂的泡沫，从而避免团队把宝贵的资源，投入到一个注定会很快消亡的技术上。
这次的分享，可能有点务虚😁，但它是我近几年最真实的感受。
程序员的工作，是把一个清晰的需求，翻译成高质量的代码。
而工程师的工作，是把一个模糊的、充满不确定性的现实世界问题，转化为一个可靠、可维护的系统。
想从程序员蜕变为工程师，需要的远不止是代码能力。
我依然每天写代码，也依然关注技术动态。但我不再焦虑于错过了哪个新库。我把更多的信心，放在了那些从非技术书籍里学来的、更底层的思维模型上。
因为我知道，这些东西，可能比我今天写的任何一行代码，都要保值得多。
你们说是不是？🙌
来源：juejin.cn/post/7560659435955224628
