大多数技术问题本质上是人际问题
我曾供职于一家技术债务累积惊人的公司——数百万行代码、毫无单元测试、基于过时十余年的框架。在某个项目中，我们面临市场需求：需让若干Windows专属模块在Linux环境运行。其他团队并未采用交叉编译方案，而是直接复制粘贴了数十万行代码，仅将Windows特有的组件替换为Linux对应组件。
对非技术读者而言，这意味着双重代码库的诞生——所有功能开发与缺陷修复都需在两个独立代码库中进行，且随时间推移将日益割裂。初入职场的我满怀热忱地着手解决这个难题……
人为困境
技术债务项目向来难以获得管理层支持，因为即便万事顺遂，代码也仅能维持原有功能。这个项目也不例外，表面效果并不理想。我效仿多数工程师的做法，“无视政治因素”埋头苦干，最终完成任务。但项目周期超长，我因此失去了管理层的信任。
我意识到自己本质上是用技术手段解决人际关系问题。公司多数开发者甘于重复昨日乃至五年前的工作模式。正如Andrew Harmel-Law所言，代码往往承载着编写者的个性印记。 那些极度抗拒变革的性格类型，往往不会在代码设计中预留未来变更的空间。
多数技术问题本质上是人际问题。试想：技术债务为何存在？因开发前需求未被充分明确；因销售人员向客户承诺了不切实际的交付期限；因开发者因惯性选择过时技术；因管理层反应迟缓导致项目中途取消。 因为某人的自负阻碍了他们看到更优解。
该项目的核心症结在于：承认需要重构，就等于承认公司的软件开发模式已然失效，个人的技能体系严重过时。我们这个小团队正试图修复众多模块中的一个，而其他开发者仍在沿用几十年的编程方式。 有位开发者直言不讳：“我不想学任何新东西。”我由此领悟：技术债务的积累速度永远快于清理速度。这如同急诊室的分诊流程——必须先止血，才能修复其他创伤。
理想世界的幻灭
这个项目也让我看清了工程师理想中的幻象——以为技术问题能在真空环境中解决，远离“政治斗争”，让成果自证价值，更幻想着没有截止日期…说实话，客户也不存在。这种理想世界几乎不存在。 绝大多数项目都涉及非技术利益相关者，仅说一句“相信我们，正在处理”根本行不通。我意识到，让团队展现出高效产出的感知，与实际产出同样重要。
非技术人员无法直观理解所需投入的精力或技术债务清理的必要性，工程团队必须在初期估算和项目更新中有效传达这些信息。除非领导层具备工程背景，否则技术债务工作的价值往往需要量化并转化为业务价值呈现。
警醒
或许这些正是为更高职位做准备的必修课。我认为，无论选择技术路线还是管理路线，任何资深工程师以上级别的人都必须懂得跨职能协作。学校教的是计算机科学，而非如何驾驭人际关系、处理自尊心和个人盲区。
我曾与一些卓越的工程师共事，他们远胜于我——那种对任何技术都能展现深厚造诣的类型。 年轻时我也渴望成为这样的工程师——“工程师中的工程师”。但如今我明白，这不符合我的性格。我天生注意力不集中，无法完全埋头苦干。:)
尽管他们拥有诸多（显著）优势，这类工程师往往回避人际交往。 他们能成为极高效的独立开发者，却可能在大型项目中受挫——毕竟单枪匹马终究有限，就像单核处理器有其速度极限。或许同样珍贵的是“抬头式程序员”：既深谙技术精髓，又能及时警觉项目风险（技术与非技术双重风险），引领团队规避险阻。
本文文字及图片出自 Most Technical Problems Are Really People Problems
大多数人的问题本质上是沟通问题。工程师既不参与产品愿景制定，也不接触客户群体，反而被允许各自为政。产品团队不理解工程师参与的价值，反而像对待内部外包团队那样给工程团队提供资源。销售和客服未能理解：他们对单个客户的承诺，会如何影响产品计划中那些急需功能的交付周期。目标与成功指标无法对齐，于是所有人各自划船。
解决方案通常不是“换人”，而是让团队围绕共同目标协作，确保每个人都明白自身职责如何与整体契合。同时要认清：哪些艰难之事值得坚持。没错，你手头有个积攒了15年技术债务的模块，既非你所建，团队中也无人敢碰。但它不像青春痘，放任不管不会自愈。请量化这笔技术债务给公司造成的损失与风险，权衡其他目标后制定计划，在恰当的时机以合理速度逐步清偿。
正因如此，我在BigCo为内部工具团队创建了“影子会话”计划。
用户就在眼前，主动建立联系吧。了解他们日常的工作内容，以及这些工作如何融入整体框架。
这些会议形式轻量，每三周自动安排一次，无需强制行动项，每次参与者都收获满满：大量小问题得到解决，人际纽带不断建立。
当终端用户唾手可得时却不愿接触，这种文化在我看来很奇怪。其实只需付出较低成本，就能获得约80%的宏观认知和用户体验设计基础。
为此我创建了报名表单和与Slack API交互的自动排程系统。最难的部分在于协调日程和召集人员，尤其当活动超出产品路线图时更需挤出时间。
完全赞同。请务必花时间接触软件使用者，更理想的是亲自使用产品。
我曾任职的一家外卖公司，每逢圣诞周所有员工都投入运营——要么随车协助常规司机配送三倍于平日的订单，要么处理电话邮件解决突发问题。无论哪种情况，次年一月必定迎来针对业务环节的低投入高回报软件更新浪潮。从调整交互流程以适应配送环节，到在每个管理页面页眉添加公司电话号码，无所不包。
亲临一线体验工作流程，才是发现所负责工具缺陷的最佳途径。若能在年度最繁忙时段实践——那时任何可能出错的环节都极易崩溃——更能收获额外收获。
正因管理层从不亲自使用产品，各公司领导层才会阻挠员工实施合理改进。
面向企业客户的公司……根本不在乎终端用户。不过是管理者们互相拍马屁促成交易罢了。产品是否好用对他们毫无意义——毕竟没人真正使用它。
“优秀”企业绝不会纵容这种现象，但它却屡见不鲜。
另一种危险信号是开发者自己从不使用完整产品，只埋头于自己负责的小模块。
吃自家狗粮——换言之，让公司全体共同烹制美味佳肴并共享成果。
优秀企业开业首日，48小时后便会涌入大批满意顾客——他们并非偶然光顾，而是因感知到卓越品质而反复回流。
但说到喂养顾客，若连自己都吃不下自家狗粮(无论何种形式)，又怎能指望用户愿意尝试？
使用它。我赞同。
我曾供职于一家公司，连一名员工都不愿使用自家产品——即便他们有机会使用。“呃，我猜我不在目标用户群体里…”是他们最常用的借口。这令人极其沮丧。
没错，完全正确，而且令人震惊。
这正是行业的盲点——最擅长构建和评估功能与软件的人，往往最缺乏站在终端用户视角思考的能力。
因此，当你培养用户导向型工程师时，这些常见且往往无需费力的问题就能在源头避免，从而提升组织效率，为当下及未来的项目创造更优质的软件和用户体验。
虽然稍显复杂，但我在前公司管理内部工具团队时实施过轮岗计划：每季度安排本团队工程师与功能团队工程师互换岗位。
我们集体认知的提升价值非凡。功能开发者得以更直接地协助解决工具问题(同时意识到事情并非表面看起来那么简单)，而我们也获得了更深刻的洞察——这些洞察源自日常使用工具的真实体验。
这证明该“问题”存在先决要素：技术要实现存在，伦理必须与之高度契合，才能有效交付技术成果——即产品。
从伦理角度看，用户本身就是另一项关键证据——尤其在实时大规模场景中。
因此你关于用户的观点完全正确。用户优先，技术其次；当技术服务能大规模显著惠及用户时，所谓“人”的问题便转化为“人”的解决方案——即用户本身。
我认为症结在于企业缺乏倾听激励机制。管理层不愿倾听下属，下属又不得不通过竞争博取关注。
我仅有寥寥数人能进行深度探讨而不受议程干扰。与多数人交流时，往往只是在强行推进己见。
最近经历了多场会议，某位主管雇佣顾问强推新平台改造方案。系统开发团队无人认同其合理性，却因主管和几个应声虫的阻挠无法阻止。没人愿意倾听。
这让我想起父亲和我服役时常聊的话题。他服役于陆军，我则在海军。但当晋升机会与同侪竞争排名挂钩时，若真想钻制度空子，本质上就是在破坏团队协作。这与军队乃至任何组织的期望背道而驰——我们追求的是“水涨船高”的协作氛围。然而当绩效考核体系完全背离此道时，这种情况就难以避免，我亲眼见过有人这么做。
我很快掌握了装备操作资质，开始负责培训那些与我竞争晋升的战友。若我是个混蛋，本可故意敷衍培训、故意拖延进度。我没有这么做，但对那些一心只想快速爬升的人而言，这本是合乎逻辑的选择。
> 若我是混蛋，本可故意教差并拖延时间。
这当然是显而易见的恶意操作。更阴险的情况是：你可能只是个糟糕的导师，或许根本不懂如何培训同事，却浑然不觉。
最终结果相同：你看似是这群乌合之众中唯一懂行的人，但这次你甚至没有选择余地。系统产出糟糕结果并非因人为滥用，而是制度本身有缺陷。
所有沟通问题都涉及一个或多个发送方与一个或多个接收方。问题在于你只能掌控其中一方。即便沟通技巧再完美，也无法挽救无能或抗拒的接收方。
作为IT支持从业者，我见过用户习惯性地关闭那些清晰阐述问题根源及解决方法的错误提示框。唯一的问题？他们根本没读内容——当我询问提示框写了什么时，真相才昭然若揭。
我曾反复向某些人解释相同内容，甚至让他们操作两次确保理解，结果一周后他们仍像羊群般带着相同问题回来，完全不记得自己问过。
有些问题是沟通障碍，有些则是 真实 的人为问题——换人确实能解决。任何持异议者，欢迎来做一年一线支持。
“更优秀的人才”能解决很多问题！虽然绝非万能，但确实能解决很多！
> 量化技术债务给公司造成的成本及风险
如何操作？真心求解。
若存在真实可量化的性能或数据完整性问题，就从这里切入。若生产环境中的多数缺陷源自特定模块或服务，务必记录在案。
若仅是难以理解或维护的技术债务，但功能尚可正常运行，除非你开发出更优的替代版本并展示差异，否则很难建立说服力。不过你可以收集其他意见作为佐证。
最终你必须说服他们投入时间(即资金)进行改造，且确保改造不会引发更严重问题——此时用数据指标而非主观意见论证最为有效。
根据我的经验，开发流程已被过度割裂。这正是为何连基础功能的实现都如此低效且令人沮丧——就像玩传话游戏一样。
人工智能的崛起(根据我的观察)实际上也在提升工程师的角色定位，使其更趋近于产品负责人。我强烈建议工程师掌握基础的UI/UX设计原则，并理解Gherkin行为场景的运用，以此作为功能规划与构思的工具。对于有一定开发经验的人来说，这些技能并不难掌握，但这正是我们未来的发展方向。
若技术债务已存在较长时间，可追溯过去一年的项目，估算该技术债务造成的总延误时长。梳理旧Jira工单等资料，确定受影响的具体项目。
无需精确计算，只需了解其年均成本是5小时还是5周即可。这样就能将技术债务与其他项目并列优先处理。
敢于直言“这个耗时1个月的功能，若由掌握现代技术与方法的优秀竞争对手开发，几天就能完成”需要勇气，而那句传奇般的“我周末用<框架>重写了它”往往难以被接受。
但——有时需要采取激进手段并承受情绪伤害才能打破恶性循环。务必做好心理准备：若行动失败，你可能需要离开公司/组织。
需知正如楼主所述，这很大程度上涉及政治博弈。若你成功说服管理层存在问题，就等于严重削弱了自己的技术领导力。务必预判可能的后果！在小公司或许能成为新团队负责人，但切勿试图取代创始人/CTO。在大公司则几乎不可能撼动层层叠叠的技术领导体系。
> 情绪伤害
正因如此，我不断告诫同事：“你不是你的工作”。别对它产生情感依恋，它不是你的孩子，只是解决难题的工具。当遇到更优方案时，舍弃旧工具应当轻松且令人 如释重负 ——甚至根本无需解决该问题。
更重要的是，你不是你的代码。
对资深/管理层人员而言这更难做到，因为他们常会构建/采购/创建超出自身层级的庞大系统，进而对特定方案产生依赖——这在小型组织中尤其容易酿成大祸。
曾有位主管因对代码库极度不满，决定在周末重写系统。此人迅速交付了概念验证，赢得了管理层支持，但随后发现要使其与现有系统兼容需要投入 更多 工作量。
我们坚持推进，耗时两年逐步迁移代码(期间仍满足产品需求)。当完成最后阶段时，我们才意识到当前需要解决的问题已截然不同，此前所有努力终成徒劳。
能如此运转的大脑实属罕见，它需要持续维护，而人们极易陷入陷阱——毕竟他们要为结果负责，更容易假装自己的方案本可避免团队陷入的灾难。
就像每场英雄联盟对局，这绝不可能是你的错！
但那是他们的代码。是他们的成就。是他们留给世界的印记，昭示着自身价值与贡献。他们历经挣扎，凭借热情获得坚持的力量。
这正是他们成为行业所需专家的途径。
替换代码即等同于取代他们的专业知识，本质上就是取代他们本身。你凭什么认为几句话就能改变现状？
讽刺的是，公司裁员时最先被淘汰的往往正是这类人。这正是许多企业在经济衰退期举步维艰的原因，问题会持续恶化直至经济好转。
产品团队不理解工程师参与的价值，将工程团队当作内部外包工坊般驱使。
只因他们沉迷于“这是我的创意，你们负责执行”的优越感。面对“为何要这么做？”的质询，他们总以“兄弟，相信我”搪塞。或许我过于概括了，确实存在少数靠实力赢得“兄弟，相信我”信服的产品经理，但绝大多数并非如此。
这种产品经理行为永远不会改变。工程师们已忍无可忍，正逐步接管产品职能，本质上消除了沟通鸿沟。
这与我的经历高度契合。
> 面对“我们为何要这么做？”这类质询，他们的标准答案永远是“兄弟，相信我”。
我曾因反复追问这个问题惹恼过无数产品经理，实在无法理解。我认为根源在于他们不愿承认——这不过是高管们“本周灵光乍现”的产物，而非基于市场/商业/客户调研分析的决策。
工程师们已忍无可忍，正接管产品职责
但愿如此。是时候提升我们的沟通能力与向上管理技巧了。我感觉许多产品经理之所以能保住职位，纯粹是因为他们对高管唯唯诺诺，毕竟高管们早已厌倦工程师们总说“不行”。
读过Reddit上对产品经理的几则批评后，我预见到即将涌现的“你们公司只是没雇到 优秀 的产品经理”这类评论
> 读过Reddit上对产品经理的几则批评后，我预见到即将涌现的“你们公司只是没雇到优秀的产品经理”这类评论
你帖子里的观点完全正确，尤其是关于90%的产品经理沦为“在岗主义”应声虫的论断。确实，多数产品经理充其量是浪费时间，最糟糕时甚至会给公司及他们经手的一切带来负面影响。
然而优秀的产品经理堪比黄金。我始终抱持着愤世嫉俗的观点：任何大型企业80%的工作都是无用的。正因如此，优秀的产品经理才如此珍贵。
优秀产品经理能让项目避免陷入“原地踏步八个季度”的困境(多数项目皆如此)，转而实现全神贯注的执行力，赢得高层认可。
他们需要厘清高管需求，引导其冲动决策转向更具建设性的方向，在优先级冲突的跨团队协作中维持聚焦与清晰沟通，协同工程师设计功能并制定切实可行的路线图，更要跨越团队边界发掘有影响力的项目或合作机会… 这些工作既耗神又费力，需要兼顾技术细节与人际关系，多数人根本不具备这样的耐心和精力。这远非一份全职工作能胜任。
但若产品经理能成功驾驭，就能真正交付重要成果——这些成果足以推动整个公司前进，显著提升利润，令所有人无法忽视。正因如此，尽管多数项目经理都是无用的拍马屁者，这个职位依然存在。在大公司里，仅凭一位项目经理成功交付重要项目所产生的影响，就足以抵消其同事们带来的所有无用负担。这就是企业持续投资项目管理团队的原因——期待在成堆的粪便中淘到几粒金子。
这确实是为项目经理存在性做的漂亮推销。我从未断言项目经理完全无用，也合作过相当称职的同行。
猜你曾是项目经理？你用了他们最擅长的套路——先示弱示好，再用长篇推销反驳 😉
在我看来，你对PM群体中连50%水平者的价值都夸大了 太多
我认为 项目管理 本身是有价值的(这里不深入讨论PM/PO等角色差异)。但问题在于，我们过度提拔了传统项目经理担任产品方向决策者，而他们既缺乏相关经验也欠缺洞察力。
我是工程师。我不认为自己在夸大项目经理的影响力，我明明说大多数项目经理毫无用处哈哈。
你其他观点我都赞同。特别是关于项目经理被过度提拔的部分，这和我想法一致。
“内部外包工坊”这个说法很贴切
多数沟通问题本质是层级问题。沟通与人际关系天生具有层级属性，群体思维、社交行为、融入感、对层级与地位的认知，这些因素对沟通的影响远超我们的认知。
别忘了，绝大多数沟通都是非语言的？
这不过是美好的幻想，但并非你想象的那种。现实是多数工程师只想完成工单就走人，他们根本不想参加更多用户或产品会议。在多数公司里，真正热爱这份工作、渴望打造产品的员工可能只有10%。
> 多数工程师只想完成工单就走人，这就是现实
我职业生涯中认识的所有初级工程师，起步时都并非如此。
不知他们中途发生了什么变化？
我观察到两种模式。我只能谈谈年轻男性的情况，因为我职业生涯中几乎没和女性工程师共事过(比例极低)。他们职业生涯初期会高度专注，因为能获得大量积极的学习反馈和晋升加薪机会。但进入中期职业阶段后(约五年)，这种势头会急剧减缓。这种停滞促使许多优秀工程师进入“巡航模式”。
另一重要因素：家庭。(A)结婚生子后，人生重心发生剧变；(B)或因照顾患病父母亲属等工作外事务变得更为重要。
我提及这两种模式并非为了批判他人。
你从未放慢脚步吗？我倒是放慢过。
完全赞同。可悲的是，我发现真正关心的人远比你想象的少；对某些人而言，这不过是份薪水而已。这些年来，人们对自身作品的自豪感究竟发生了什么变化，我实在难以捉摸。
我认为那些经历过崩盘危机的老前辈们尤其如此，他们亲眼目睹过崩盘的后果，因此更希望确保你不会重蹈覆辙。这涵盖IT领域的方方面面——网络安全、灾难恢复，远不止软件层面。
每当我调任新岗位，总会在90天计划中确立清晰的指导方针，但最终成败仍取决于团队。
情况可谓五五开：有些团队渴望变革，另一些则会竭力阻挠你的努力。更糟的是，上级领导可能毫无头绪，只顾选择最快最便宜的方案。
关键在于必须极快地看清局势！
不过当情况彻底失控时，想必多数人都关注过英国邮政的软件漏洞事件——那些导致民众入狱、自杀的灾难性后果。https://en.wikipedia.org/wiki/British_Post_Office_scandal
我确信当时肯定有少数技术人员(至少一人)清楚这些问题并试图修复，却在每个层级遭到阻挠。虽无确凿证据，但令人怀疑。
> 对于数十年间人们是否真正为自己的工作成果感到自豪，我并不确定。
原因很简单：
1. 人们失去了对工作成果的所有权。20世纪初，超过半数劳动力是自雇人士。如今美国仅剩10%，欧盟也只有13%。
你创造的成果不属于“你”，而是“雇主”的财产。你既无所有权，也几乎丧失了自主权。
2. 人们与自身产出质量和数量的实质联系已然断裂。
多数劳动者不会因加倍努力、提高产量或提升质量而获得回报。相反，他们往往因工作量增加或难度提升而遭受惩罚。
正如《办公室空间》所言：“这让人干活只够不被炒鱿鱼。”
3. 人们丧失了人性。他们不再是人，而是资源——人力资源。他们被当作资源对待。
他们被剥削牟利，不再需要时便被抛弃。
软件工作与其他手艺的怪异差异在于成品的持久性。
家具匠人造出椅子便交付客户，从此再难相见。他们对工艺的自豪感源于精湛技艺带来的成就感与外部声誉的积累。
而在多数软件工作中，今日所建之物将长期存在，下月你仍需面对它。对工艺的自豪感可能带有自利性质——因为精良的构建能为未来的自己省去麻烦
我认为这忽略了科技巨头中代码库的剧烈更迭。今日所写的代码十年后很可能不复存在——它会被彻底重构、沦为废弃代码，甚至整个产品线直接取消。纵使倾注心血，你极可能并未在世间留下持久印记，不过是让数字持续增长的微小齿轮罢了。
科技职场同样瞬息万变。重组、离职、持续招聘——若你今日离去，五到十年后，或许再无人记得或赞叹你曾熬过的那些英雄般的通宵。事实上，你昔日的团队很可能已面目全非。
若你为客户打造优质家具，它很可能比你更长寿；若你在亚马逊开发某个前端组件，则不然。我认为对工艺的自豪感应当与作品的生命力成正比。
说得好。我始终认为编程与手工艺的类比是牵强附会。至多产品才是工艺本身，而非代码。产品的价值完全取决于用户体验及其解决问题的效能。底层代码质量虽与这些要素相关，但坦白说：设计拙劣、无法满足用户需求的产品，即便拥有完美代码和零技术债务，依然会因本质缺陷而成为劣质品。
更何况，有些代码本就该被抛弃。我们当然都想雕琢出象征永恒的精美木椅，但客户有时需要的不过是堆塑料椅——便宜，下周就能交货。谁会在意它们用一年就坏掉呢？
所以当我接受老板要求赶工时，不会抱怨由此产生的技术债务，也不会争辩“本该设计成完美代码”——并非我对工作缺乏自尊，而是理解业务需求。
有时，业务方需要的只是塑料椅子。
这只适用于你打算长期从事一份工作的情况。当前的企业文化使这种选择风险颇高——既因杰克·韦尔奇式裁员管理的危害性，也因每隔几年换工作能获得职业发展和薪资提升的双重优势。
> 对工艺的自豪感可能带有自利性，因为精工细作能为未来的自己省去麻烦
没错，我在上份平台工程师工作中就这么做过。我刻意设计让其他团队能并行工作且不被我阻塞，这样我就能腾出更多时间重构代码，总之就是为未来的自己省事。
长话短说，我被裁了。
> 对工艺的自豪感可能带有自利性，因为精工细作能为未来的自己省事
但事实并非如此。即便你做得再出色，也并非能闲着无所事事，而是会接手新的软件项目。真正享受成果的是公司。
接手新软件项目总比回去翻旧软件项目的垃圾代码强多了。至少新项目能让你接触最新技术。
IT公司乐于收钱写代码，哪怕代码漏洞百出，因为真正的问题并未解决。这在我看来是个问题。企业需要更善于拒绝，转而协助解决根本问题——即使这些问题并非技术性质。
> 仅仅为了金钱工作有什么不对？
没什么不对。事实上，我羡慕能做到的人，也渴望自己能做到。这算是我最大的缺陷之一。
> 这些年来，人们对自身工作成果的自豪感究竟发生了什么变化？
许多雇主刻意阻止员工对工作产生自豪感。当产品被压榨到最低成本时，你不可能为之自豪。
你可以让员工关心客户或产品，但无法让他们关心利润和分红。
> 这些年来，人们为何不再为自己的工作成果感到自豪？
以我个人经历为例：我曾为自己的工作成果感到自豪，但后来工作变得陈旧重复。不过随着工作变得陈旧，我的收入反而增加了。如今处境是：若辞职去寻找值得自豪的事业，就得接受大幅减薪。免了。
我宁可拿高薪当“纯粹的薪水”，在工作之外寻找自豪感。反正别人都不在乎了，我何必在意？多给我钱，我就继续上班。
> 或者你上面有个毫无头绪的领导，只顾选最快/最便宜的方案。
这位领导并非选择最快或最便宜的方案。那样做或许值得称赞。他们采纳的是某人声称“某种方式将会”更快或更便宜的 主张 。实际是否更快更便宜并不重要。当一个方案被认定符合要求，另一个方案被认定更便宜时，即便后者不符合要求，便宜的方案仍会被选中。
> 我觉得这类人往往是我们团队里资历较深的成员，他们亲眼见过崩盘时整个体系分崩离析的景象……
令年轻时的我大为惊讶的是，我 从未 亲眼见过“一切崩塌”的场景。我真心认为这种情况在实践中极其罕见(比如英国邮政事件之后)，这不过是资深开发者喜欢想象却极不可能发生的情景，他们用这种设想来吓唬管理层和初级开发者，迫使他们采取可能改善也可能无济于事的“行动”。
我几乎无一例外地看到软件通过持续的紧急修复和局部重构逐步完善。这些修复与重构的难易程度，本质上取决于底层设计是否扎实：糟糕的设计往往难以修复，需要堆砌复杂的补丁才能勉强维持系统运行；而优秀的设计通常能大幅降低维护成本。两者都能产出可用的软件，只是承受的“痛苦”程度不同。
我曾参与两个基于弱类型语言构建的系统开发，最终因逻辑推演和漏洞修复难度过高而迁移至Java。连框架开发者都束手无策的客户级漏洞比比皆是。
有时人们制造的混乱实在太过严重，只能推倒重来。
真希望存在更优的团队匹配机制…现有分配往往失衡…懒散者与积极者混杂，后者常被淹没在补位中。若调整比例让创造型/驱动型/团队型人才协同工作，成效将呈指数级提升。
坦白说，人们很少讨论这样一个事实：许多人纯粹就是蠢货。若我的职位取决于这些蠢货，游戏规则就彻底改变了——因为此时优秀的工程能力不再是提升地位的最佳途径。于是聪明人便耗费心力设计精巧的策略，表面上装作高效实则毫无产出，整天玩弄办公室政治。所有成功企业都深谙此道，它们建立的流程都基于“员工都是蠢货”的假设——这虽会扼杀聪明员工的创造力，但事实是：万千蠢材的合力远胜百位天才。
当你对工作毫无归属感，而企业对员工的忠诚度与投入度日益衰减时，又怎能为自己的成果感到自豪？当你随时可能成为下一轮裁员的对象——无论你创造了多少价值——又怎能真正投入心力？
所以说，对大多数人而言工作不过是谋生手段——除非你是自主创业，或是喝了整整一加仑的迷魂汤，真心信奉公司使命或其所做之事。
我为自己从事的技术或其他项目感到自豪，并倾注了极大的心血。而在朝九晚五的工作中，我只做分内之事——不多也不少，以此为自己的私人时间保留精力。并非说我的工作质量差，而是我只会完成预期任务。公司若不额外付费，就别指望得到更多。
过去并非如此，但为他人“额外付出”的经历让我屡屡受伤。
若员工能对公司拥有更多所有权和利益，这种态度或许会改变。同样地，若企业重新投入培训与人才保留，忠诚度或许能重新成为双向的。
工作不过是张薪水单，因为在雇主眼中我只是个数字。既然管理层认为终有一天我会被AI取代——毕竟我只是成本因素——我凭什么为工作感到自豪？那我又何必在乎公司死活？去他妈的高层，等我能买得起房子时，我会为工作感到自豪并真正付出努力。
> 可悲的是，我发现真正不在乎的人比你想象的多；对某些人而言，工作不过是张薪水单。
我发现多数“伪装成技术问题的员工问题”，其实源于那些过度投入工作、让工作定义自我的人。他们变得领地意识强，把任何争论失败都视为对自我价值的攻击等等。他们还丧失了客观性，为缩进风格或API语法细节的琐碎争执陷入口水战。
那些只为薪水而来的员工，在这方面通常要理性得多。
没错。我的态度就是“选个技术就行，无所谓具体什么，只要坚持用它做出点成果就行”
记得有位叫理查德·罗尔的举报人说过，工程团队确实知晓这些漏洞和缺陷
> 这些年来，人们究竟如何看待自己所创造的工作成果，我实在难以捉摸。
对恶行视而不见，对你们这代人而言是种福气，对我们这代是种诅咒，对后代则是致命毒药
> 这些年来，人们究竟如何看待自己所创造的工作成果，我实在难以捉摸。
数百万编程营学员和初级工程师只求快速赚钱；任何不符合“速成速成”标准的技术工作都会受罚；技术债务被扫到地毯底下；任何创新都因现状至上而扼杀； 面对15秒页面加载时高呼“出问题再优化”；层层寄生虫与骗徒让人生如地狱，因他们的薪水就此维系；涨薪连通胀都抵不过——人生唯一出路就是加入公司，两年内制造最大混乱后跳槽，把烂摊子留给下一任倒霉鬼。
以上仅是我在糟糕的iOS键盘上勉强敲出的内容。
人们只关心签证问题
你的评论开启了精彩讨论
面试时说这话绝对是自毁前程，尽管事实如此。可悲的是面试官常乐于指出：任何超出预设框架的回答都意味着技术知识匮乏。我参加并通过过多次技术面试，也面试过许多人——若应聘者能指出问题的本质，我反而会加分。可悲的是我总得为此与同事争论。
“但用消息队列呢…”
“候选人没用微服务…”
“不懂图数据库…”(毕竟我上周刚学过培训课程，所以这必然是解决方案)
所幸我们无需用技术面试的合格标准来评判一篇博客文章。:)
最近一次面试中，所有面试官都对我竖起大拇指。唯独一位工程师例外。
我清楚记得那段对话，因为它让我有些困惑。当时讨论的是海量消息处理方案。当我说“这其实取决于消息量，很多情况下批量处理就足够了”，他立刻跳出来反驳，仿佛我从未听说过队列这种东西。
随后我结合自身设计思路(以及十年以上处理PB级数据存储产品的经验)提出：当大量服务直接连接数据存储时，可能引发扩展性问题。他却断然否定了这一观点(因为这不符合现有系统设计)。
猜猜我们现在讨论什么，并为此组建了整个团队来完成？由于规模问题，强制每个微服务使用单一API而非直接调用Elasticsearch。
> 基于我十年以上处理PB级数据存储产品的经验，我在设计中提出：如此多服务直接连接数据存储可能引发规模问题。
现实中存在相当数量的工程师，他们从未在超大规模环境中工作过——那种超大规模服务商的瓶颈已成为常态的架构问题——更缺乏谦逊之心去设想这种可能性。(例如：块存储确实存在可触发的限制，当处理PB级数据时，架构设计必须预见到即便是简单操作都可能触发这些限制。) 我也从事PB级数据存储工作，这些年来遇见过不少这样的工程师。
不过公平地说，这类工程师在我接触中属于极少数。若不是争论PB级特有的规模问题，他们就会纠结于其他细微的议题。这本质上是谦逊度的问题。
哦，天哪，奇怪的是我经历过完全相同的情况。
有位面试官曾期待我回答“消息队列”，尽管他回答我所有问题时都表明消息队列无法解决问题。
他对我反复强调“要视情况而定”和不断提问感到非常沮丧，直到我回答“消息队列”时他才如释重负地叹了口气。
我通过了面试但拒绝了工作邀请。
这本质也是数学问题。我遇见过那些做出糟糕决策的人，往往连草稿纸上的快速估算都令人震惊地差劲。
说实话，面试官因优越感而故意淘汰候选人，是我听过最可悲的事。这得有多孤独啊？
/endrant.
你指的是哪种批处理？某些网站发送验证码要5分钟，难道是因为批处理？
另外，雇主居然会当面咆哮告诉你具体哪些员工投了赞成/反对票，这也太疯狂了。
虽然有点跑题，但图数据库常被滥用，只因它听起来很酷炫。
我发现面试中呈现双方观点(即展示权衡取舍)很有效。尤其当我考虑加入的团队未能意识到这些权衡时，就能避免加入他们。
作为大型科技公司的数据工程师，我面临的两大难题是：
* 康威定律导致数据科学工具链碎片化，模型训练、数据处理、模式协议、数据保留策略等领域存在不同理念。
* 设计技术方案以缓解多部门各自为政的困境——各团队既坚持按自身方式行事，又要求其他团队采用其方案以获取数据访问权限。
标准化难以实现的根源在于：层级体系中各分支的“封建领主”坚信自身方案是满足业务/技术需求的唯一途径。作为目睹所有这些做法的人——我发现多数方案既合理又存在缺陷，且缺陷往往与领导者认知相悖。少数方案因架构师或领导层缺乏实战经验而存在“根本行不通”级别的缺陷。
所以说，表面看似技术问题，本质却是人际关系问题。
我还能列举更多：
– 需求从一开始就很少清晰明确；
– 我们(开发工程团队)未能实现自助服务和自动化，导致被零碎需求淹没(例如“请添加这个列”之类)；
– 上游极少通知我们变更，我们只能在下游触发警报时才知晓。最终不得不构建昂贵的管道进行扫描和警报发送，有时警报成本甚至超过管道本身；
– 临时需求泛滥导致冲刺周期形同虚设。若我是管理者，定会彻底废除冲刺机制；
– 存在大量无人记录的隐性知识。我虽尽力记录，但未知远多于已知；
在DE工作确实让我有足够动力自学底层计算机科学。
此处DE指什么？
应指数据工程师。
数据工程
数据工程
剥离与排除？……
请只给错误答案。
这正是IT领域所有人员-空间问题的根源所在。
要解决此问题，可成为变革的推动者：建立人脉网络，凝聚团队力量，倡导更优解决方案，同时通过透明运作避免激怒管理层。
有时，这种方法确实有效……但仅限于一定程度。要快速推动真正的变革，必须由管理所有利益相关者的负责人亲自带头推进，并/或委派专人落实执行。因此，董事和副总裁的行为举止对问题本身及解决方案都至关重要。通过大量沟通和游说来推动高层达成共识并非不可能，但绝非易事。
值得补充的是，工作场所的技术转型如此艰难，亚马逊甚至为AWS发布了专项指南。作为完成这项艰巨任务的蓝图，我认为它适用于实施任何层级的技术变革。该指南更强调了一个核心理念：必须先获得员工队伍中关键人物的支持与认同，其他人才会跟进。https://docs.aws.amazon.com/prescriptive-guidance/latest/clo…
> 这也再次强调了一个核心理念：必须先获得员工队伍中关键人物的支持与认同，其他人才会跟进。
没错，这正是核心症结所在，也是为何本质上属于人际关系问题。若主要障碍在于获得对规范/构建/采用方案的认同，技术解决方案便难以奏效——除非你愿意投入大量资源构建最终会被废弃的系统。因此高风险工作的实质，往往是人与人之间的博弈。
> 标准化难以实现的根源在于：层级体系中各分支的“封建领主”们坚信唯有自身方案能满足业务/技术需求
我在大型企业级系统实施领域工作。当项目跨越部门/分支机构/机构时，你描述的困境正是最大障碍。项目初始总宣称“整合所有部门到统一方案”，但随着时间推移逐渐分化。最终往往演变为“每个部门独立项目”而非“全局统一项目”。必须有人具备强制/威慑/协调的权威才能让各方达成共识。一旦向某个部门的特殊需求妥协，消息传开后便会打开潘多拉魔盒。这种协调极其困难。
我认为公共部门(政府机构)最为棘手，因为各部门似乎真心彼此厌恶。我曾参加需求收集会议，有人仅因不喜欢的同事在邀请名单上就拒绝出席。至少在营利性公司里，大家还有共同目标——保住饭碗。
杰里·温伯格《咨询的秘密》(1985)——“无论表面如何，本质永远是人的问题。”——无论问题看似多么技术化，其根源总与人相关——他们的选择、沟通、管理或技能——这使得人为因素成为从软件开发到复杂系统所有解决方案的核心。
特来此处分享此言。其智慧的永恒性令人惊叹。
杰里·温伯格就此主题撰写了多部著作，始于1971年的《计算机编程心理学》。以下是他约十年后提出的观点…
"咨询第一定律：无论客户如何表述，问题始终存在。
咨询第二定律：无论表面如何，本质永远是人际关系问题。"[0]
他的每部著作都值得细读。
[0] 韦伯格，杰拉尔德。《咨询的秘密：成功给予与获取建议指南》，1986年
看到这个帖子标题，立刻想起了杰瑞。
我曾作为分析师参与系统替换项目。
旧系统采用纯粹的循环分配机制——人员1处理案例1，人员2处理案例2，如此类推，完全不考虑个人现有工作量。
新系统综合考量多项因素，将新工单分配给待办事项最少的员工。例如当员工1有2个工单、员工2有10个工单时，新工单将分配给员工1。
某部门管理层后来找我们反映，称这种分配方式存在缺陷，工单分配不够“公平”。他们要求在新系统中恢复旧有的循环分配机制。
经调查发现，部分员工已摸索出钻系统空子的方法——通过虚报工作量来减少新案件分配。结果导致高效完成本职工作的员工反而因新案件分配而受罚，低效员工却因此获益。
我、该部门另一位分析师以及我的管理层都提出了非常明确的论点：如果员工未能妥善处理案件，且其工作进度未被有效监控(通过新系统提供的一切监控工具)，那么改变案件分配方式根本无法解决根本问题。
我们的意见遭到否决，被迫采用技术手段来应对人为问题。
这似乎是两种技术方案的抉择，而非人员问题。其中一种方案存在某种扭曲激励机制
即便没有扭曲激励，工作量总会扩张以填满可用时间——这本身就是另一种扭曲激励，或许正是人性使然
或许将人性问题转化为技术问题才是上策。例如：首选路径应是最简路径
可悲的是，现实中人们从不遵循乌托邦式的理想模式
如今我已身居高位，直接对接资金方与需求方。那位全球范围内100%主导该项目的女士说：“我需要X功能，成本多少？”而X功能是个复杂难解的难题，我只剩30分钟会议的最后18分钟来尽可能获取细节并估算成本——因为资金线将在第30分钟定夺。
他们对技术细节一无所知。但他们清楚资金流向，也深谙向特定人群说哪些话才能争取并守住资金。我曾接手一个预估耗资600万美元的问题，最终在会议中用一条短信就解决了。早知道就该收下那笔钱。我也经历过项目被挖走，眼睁睁看着新团队烧掉3500万美元，最终除了受伤的自尊外一无所获。
那些掌控预算的赞助商，绝对是把政治手段置于一切之上的家伙。他们通常只有学士或硕士学位，极少有博士。看着他们的职业轨迹，你不禁疑惑他们是如何爬到这个位置的。他们的目标不是任务成功，而是下一份工作。整个职业生涯都在为下一份工作做准备。财务人员要么害怕他们，要么至少非常警惕。
> 有位开发者曾直言不讳地告诉我：“我不想学任何新东西。”
在此扮演魔鬼代言人：JavaScript生态圈里那些框架/库/月度潮流，每天都在催促你更新过时的工具库；而用Go语言基于标准库构建一切，部署到长期支持的发行版上，两者存在天壤之别。
技术稳定性对产品敏捷性的益处是切实存在的。诚然，这可能意味着你的代码库局限于C++子集，且由一位五十多岁、真正资深的工程师掌控——他拥有三十余年C++编程经验，每次产品变更都需与其反复协商。这就是现实。若仅因外部视角就将此称为技术债务，实属不公，这本质是年龄歧视。
判断是否存在技术债务的决策者仅有两人：(a) 基于对代码库状态的本能认知，负责代码库的主力工程师；(b) 既观察到发布敏捷性受威胁，又愿意投入非功能性工作以提升未来发布敏捷性的管理者。
标题图太棒了。
这描述了我多年来见过的无数项目。
我最早参与的编程项目之一，是维护1975年左右开发的10万行代码的FORTRAN IV邮件程序。
无注释、无子程序、短小而晦涩的变量，被数十名初级程序员随意改动，却支撑着公司的主要收入。
真是乐趣无穷。
这大概是我后来形成严谨编程风格的最大动因——我 绝 不愿将当年遭受的待遇加诸他人[0]。
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
“约1975年维护一个10万行代码以上的FORTRAN IV邮件程序”
听起来颇具挑战性，且属于邮件技术早期阶段。这段经历是否记载在时间轴中，还是仅限于内部系统？
https://archive.computerhistory.org/resources/access/text/20…
这基本属于互联网邮件出现之前的事。
由英国电信子公司Dialcom运营的专有存储转发系统，运行在Prime小型机上。
我1987年就在那儿工作过。
[更新补充]雪上加霜的是，所有操作都得在低于VGA标准的300波特VT-100终端机和行式打印机上完成。
我花了大量时间盯着蓝条纹纸看。
电信黄金时代！真为你高兴。
https://en.wikipedia.org/wiki/Telecom_Gold
至今我仍会惊醒尖叫…
该系统的缺陷之一在于无法生成可靠的计费数据。
一位客户多年来一直免费使用该系统，因为我们无法向其发送准确的账单。
只需看一眼那团乱麻般的系统架构，原因便一目了然。
正因如此，我厌恶人们因履行工作职责却被指责“缺乏职业自豪感”(正如本文作者所为)——关键在于，员工通常不拥有工作成果，所有权属于企业。若企业要求特定工作方式，且试图抵制者反而遭受惩罚，何必与之对抗？这又不是我们的公司。我们不过是机器上的齿轮，既然他们如此对待我们，还指望我们怎样？
这篇文章充斥着自我标榜的腔调，令人反感。
在非发达国家工作过的人对此都深有体会。大家不过是在谋生而已。
有趣的是，当我开始在发达国家的办公室工作时，这种认知反而变得格外痛苦。或许是目睹了整个体系的庞大规模所致。不过我理解你的观点。
技术问题源于知识匮乏。其中一种匮乏体现在人际互动上——你永远无法完全理解他人想传达的内容，原因多种多样。
即便神奇地解决了人际问题——比如独自完成项目——技术债务依然存在，因为知识缺口永不消弭：存在漏洞的抽象层，未能覆盖所有边界的测试，看似“简单”却暗藏玄机的函数。
最需警惕的错误是认定自己没有知识盲区。知识鸿沟永远存在。因此请提前规划，确保在最终发现缺口时已做好准备。
> 技术问题源于知识匮乏。
或源于行动缺失。技术会崩溃，你需要采取行动做好准备。
我如今基本持这样的观点：世上不存在所谓的“过时技术”。某些技术不再适用，但这几乎绝非因其年代久远，而通常源于以下原因：需在无法支持的环境中运行、存在无法修复/不再维护的漏洞、缺乏解决新问题或添加新功能的必要特性、遭遇规模限制。
所谓“过时”有时是上述原因的委婉说法，但在技术讨论中，它通常仅指“陈旧”或“不合潮流”。
我认为“该技术在就业市场几乎无人使用”也是导致技术失效的重要原因。这与生态圈息息相关(开发者匮乏——维护/创新项目寥寥无几)。
我认为这比单纯的“过时”更有说服力。
不过对于我招聘的绝大多数开发者而言，他们都能快速掌握较旧的技术。真正棘手的是优秀开发者拒绝使用该技术的情况。这类开发者抱持这种态度时，背后往往另有隐情。
>背后往往另有隐情。
比如“离职后能否找到新工作”——这可是关乎人生的大问题。
若你要求我使用1988年的COBOL编程，便将我的就业前景限制在国内极少数雇主和特定薪资区间内。但若我拒绝并选择使用$language_de_jour，雇主数量和潜在薪资范围将扩大数倍。
为何掌握某项技术就意味着丧失其他领域的就业机会？
难道没见过招聘启事要求“必须具备XYZ领域X年经验”？这种要求比比皆是。实际上我从未见过不带此类要求的职位。经验总得从某处积累。
我知道开发者总说愿意招聘任何人，但实际招聘者并非他们。你最多只能面试经过人力资源预筛选的人选——而筛选标准就是简历里的关键词。
我的个人经历截然不同。我曾在多家公司边工作边学习技术栈，至少有一次连编程语言都是从零开始。
即便岗位要求中没有我做过的技术，我从未觉得求职特别困难。
那你很幸运，或者资历过硬，抑或两者兼具。你的经历并不能否定开发者更愿掌握现代技术而非陈旧技术的合理性。
至少在当前市场环境下，这种做法的容错空间已大幅缩小
> 大多数技术问题本质上是人际关系问题
讽刺的是，这恰恰是工程师对技术债务根源的经典解读。工程师们乐于埋头苦干，但当团队规模超过1人时，沟通就变得不可或缺——而且最好别只靠看板板交流。
身为软件工程师，我历经沧桑后如今领导着大型团队。听到有人在此贬低管理价值时，我总有些恼火。我想让大家明白：优秀管理极其艰难，远比软件开发中遇到的任何挑战都更难。它充满主观性、非确定性，与数字逻辑截然相反。正因如此艰难，糟糕的管理才如此普遍。
> 听到有人贬低管理价值时我总有些恼火。我想让大家明白：优秀管理实属不易，…
人们之所以贬低管理价值，是因为多数管理本就不称职，多数“管理者”更毫无价值。技术管理圈里“晋升至无能境界”的现象确有其事。
> 看到大家总说管理层一无是处，我有点恼火。
优秀管理者的首要职能是隐形，因此被视作无用倒也情有可原。
但次要职能中，唯有差劲的管理者才会刻意隐形。优秀管理者会在每日站会中站出来汇报工作进展。若你连自己具体在做什么都无法向团队清晰传达，那你已经搞砸了。
> 比我软件开发生涯中遇到的任何挑战都艰难得多。
公平地说，除软件开发外的所有职业都可如此评价。软件开发本身毫无难度可言。
没错，你描述的是“人际关系问题”…
我进入这个行业时，不过是被扔进某个项目组的众多成员之一，恰巧擅长手头工作罢了。但推动我晋升的关键，最终在于我协作培训他人的能力——既能传授自身技能，又能扩展业务规模，还能高效传达意图、理念与解决方案。这部分归功于我的人文背景，部分源于成长经历：在当前职位前的各类岗位中，我被迫学会了以这种方式与人协作。无论如何，任何行业都离不开卓越的人际交往能力，至少需要些许机敏。这令我深感遗憾——年轻时我曾满怀理想主义，渴望改变世界，那时我学会调动众人支持事业；如今，我调动他们达成项目目标。本质并无二致：“危险之处，亦孕育救赎之力。” (荷尔德林)
作者指出，若高层领导具备开发背景，技术债务便更易获得处理支持与资源。字里行间透露出：技术背景者天生就能理解其中风险。
随后作者提出，缺乏技术背景的高层通常需要通过价值主张——即数据——来被说服。
我认为本质是相同的——特定技术债务的风险必须在处理前被理解。具备开发背景的高管或许更能预判技术债务与公司财务影响之间的关联，而非技术背景的领导者则需要额外的转化步骤来理解这种关联。
考虑到风险存在容忍度，且某些风险是为达成目标而主动承担的，双方最终可能选择对部分技术债务视而不见，同时处理其他部分。
技术债务的风险在于：随着技术债务持续累积，新增功能的边际成本将不断攀升。
这难道不是所有行业普遍存在的情况吗？我们现有的技术足以创造后稀缺乌托邦，逆转气候变化，修复生物圈。这些愿景未能实现，本质上是人的问题、政治问题、精神问题，而非技术壁垒。
确实，当今几乎所有问题都如此。这恰恰是AI加速论者的盲点。GPT-6研发出癌症疫苗？你仍需说服大众其安全性。Gemini模拟出聚变反应堆？得让人们相信这并非传统核能。气候变化的全球工程解决方案？虽然看似化学烟雾但实则不同。所有这些方案在社会中的落地实施永远充满挑战。
我认为这正是硅谷精英转向威权倾向的重要因素。他们在2000年代和2010年代曾抱持更理想化的自由放任主义，却发现这种理念几乎毫无成效——因为技术无法解决人际关系问题。
> 多数技术问题本质上是人际问题。试想：技术债务为何存在？因开发前需求未明确界定；因销售人员向客户承诺不切实际的交付期限；因开发者因惯性选择过时技术。
我曾是“远离政治”的开发者。入行数年后转任产品经理，反而获得了更超然视角。我发现开发者内部的政治斗争有时比其他业务领域更根深蒂固且顽固不化。
当然，业务部门也有内斗和政治博弈，但最终市场会进行调节。但要合理地对Ruby和Java进行市场测试就困难得多，尤其当双方阵营的支持者都以近乎宗教狂热的方式吹捧自己偏爱的技术时。没错，我也见过许多同事——甚至包括年轻的Z世代——抱有“何必学新东西？<技术X>对我管用，何必费力学新东西”的态度。
必须要求人们在辩论时提供客观依据，要么由(理想情况下开明的)决策者解决“vim vs. emacs”这类争论，要么放任员工自主选择开发环境并自行解决由此引发的问题。
若试图通过委员会选定开发语言，这本身就大错特错。问题根源或许在于人员管理(毕竟万事皆如此)，但本质上是企业的战略问题。
虽然认同核心观点，但其中一句论断令我反感：
>技术债务为何存在？因为工作启动前需求未被充分明确。
我厌恶这种思维模式及其衍生出的工作预期。认为开发者必须被喂食需求才能开工——因为他们天生不懂业务目标，且其产出价值连城以致无法随问题理解的深化而演进——这种观念本身就有问题。明确声明：我并非责怪开发者，而是谴责那些冠以瀑布式、敏捷、SAFE、敏捷2.0、转型等名目的工作模式，它们全是垃圾。
此处存在若干值得商榷的假设：
> 代码僵化源于开发者思维固化。抗拒变革的性格类型往往不会为未来变更预留设计空间。
成因实则多元。代码僵化亦可能源于缺乏愿景、技术能力或更新所需的时间/预算。另一极端是：某些 热衷 变革的人会彻底推翻重来，将精心编写的代码付之一炬，这同样不可取。
> 技术债务为何存在？因开发前需求未充分明确。
未必如此：也可能源于初始代码质量欠佳、库文件未适配操作系统更新、功能蔓延等问题。
> 我认为，无论选择技术路线还是管理路线，所有资深工程师以上级别的人员都必须掌握跨职能协作能力。
协作是 所有人 都需具备的技能，向不同层级人员阐释问题的能力不应仅限于资深工程师。即使初级开发人员也应学会向上级说明工作。
> 因为工作启动前需求未得到充分明确
没错，现实世界中的软件通常灵活得多且变化迅速。
项目启动时：“我们需要具备A、B、C功能的软件”
项目中期：“竞争对手已发布包含ABCD和E的功能，若不至少添加E，项目不如直接取消”
还有这种情况——我们的软件在预期场景下运行完美，问题在于(新|旧)系统出现后，现在必须绕过所有漏洞继续工作。
还有切斯特顿之栅。那套“破旧不堪的垃圾”其实在执行高度特定的功能，早已固化为客户系统的运作方式。人们总爱推倒重来，直到发现这破坏了企业客户的工作流程——而正是这些客户养活了他们。
还有其他视角可以审视这个问题。在计算机编程需要大量规划的年代，程序存在漏洞的技术问题本质上也是规划不周的人为问题。但如今我们拥有高速计算机、廉价存储、版本控制、自动保存等诸多工具，使得编程活动不再需要人类进行完美周密的规划。在许多情况下，你只需通过反复试错就能完成工作。
我的观点是：我们常为那些曾被视为人际问题的事物找到了技术解决方案。
或许许多问题本质上只是 问题 ，既可通过技术手段解决，也可通过人际手段化解。
许多实际存在的“技术问题”与“技术债务”毫无关联。
标题或许改为“商业领域多数技术问题本质上是人际问题”更准确，不过这样就少了些冲击力。
或者改成“技术债务本质上是人际问题”也行。
存在一个规模庞大且声音嘹亮的群体，他们基于以下原因不认同解决技术债务的理念：
1. 正如文章所言，解决技术债务不会带来晋升和曝光机会，因为其效果难以量化
2. 技术债务会持续累积
3. 缺乏专职岗位负责技术债务，因此它并非任何人明确的工作职责
这正是沟通能力成为资深开发者与初级开发者之间最重要差异的原因。
虽似官僚作风，但若文化支持此类决策机制，DACI或RFC等方法可发挥作用。
列出选项(如A：合并代码库，B：维持现状)，收集意见后经逻辑论证达成共识。
决策依据与权衡点均需记录存档。
讨论可能引发更广泛的议题探讨。资深者或能发现规律性问题，例如：鉴于Y功能即将上线，暂不偿还技术债务X。
但若组织文化中无人重视技术债务，多数人甘愿手动修复缺陷且厌恶讨论此事，那么无法忍受这种工作方式的开发者可能难以适应。
我完全不同意这种对技术债务成因的描述，这种逻辑极其危险。确实，需求可能未被明确。但往往需求根本无法明确，你必须先构建 某种东西 。即便最初需求清晰，谁又能保证项目完成时需求不变，更别说五年之后了？开发者选择成熟可靠的技术，难道不是因为它经受过实战考验？销售人员在工程团队无法承诺交付周期与客户需求之间周旋，难道不是在处理不可能完成的任务？
技术债务存在诸多合理原因，令人担忧的是这位似乎认为所有问题都归结于“不知何人何地搞砸了”。
正如其他讨论者所言：技术债务并非生而平等。我认同需求变更等因素确实会引发问题，但同样存在开发者因偷工减料导致的技术债务——他们不愿花时间精心设计功能，只顾头脑中浮现的第一个方案就仓促实现。我赞同作者观点：这种技术债务源于平庸态度，若无人及时制止，往往会蔓延至整个团队。
对我而言更有价值的讨论是：当团队已存在此问题时如何解决？方法或许多样，但我倾向认为工程师能做的最佳实践是“以身作则”，不过自上而下的方式可能更有效——这正是纳德拉出任微软CEO后采取的策略。
更糟的是，他们似乎认为技术债务只是“心态问题”或“性格缺陷”：
这种思维方式(“我们会为未来变更预留空间！”)本身就是技术债务的典型谬论。
哇哦，这篇文章的洞见真犀利，天啊。
技术债务的定义是刻意作出的妥协(通常为按时交付产品避免破产)。因此从定义上讲无人犯错：这是当时被认为正确的刻意决策。虽然未来需为此付出代价，但做出这些妥协本身很少是错误。
技术债务也涵盖非故意产生的债务。例如，无知可能导致技术债务的“产生”。
所有涉及人的问题都是人际问题。正因如此我们才不谈论它。这就像说所有雨都是湿的。
只需假设对方心知肚明，就能避免多生一桩人际麻烦。
这是工程视角的经典解决方案。但当你成为CTO时情况就不同了——技术债务成了你的责任，修复与否的抉择权也掌握在你手中。但另一面是：错误抉择(无论哪种)都可能代价高昂，甚至扼杀公司。
我经历过双方立场。曾不得不恳求经理批准修复我认为亟需修复的问题。如今作为CTO，我既要确保公司向客户交付具备竞争力的产品以创造盈利机会，同时还要亲自参与产品开发。
两个现实：
缺陷产品会严重拖慢关键功能开发。作为CTO，我坚信“化难为易”才是最快的推进方式。解决最棘手的技术瓶颈具有重大价值。技术债务并非等量齐观——主观审美上的折腾与技术问题导致的开发延误，两者性质截然不同。
我们是家小公司。而制造技术债务的蠢货通常就是我。这并非能力不足，只是不可能永远完美。任何存活足够久的产品都会存在问题。如今公司已近六年历史。挑战不在于问题本身，而在于如何理性地排序并解决它们。
我的应对方式很简单：只要有机会，我就想投入能创造价值的新项目。当我能高效推进高影响力工作时，就会感到满足。每当技术债务问题打乱计划，我就会感到沮丧和恼火。这时我会坐下来分析最棘手的核心症结，然后直接解决它——毕竟最终决策权在我手中。但不可能永远如此。
CTO的重要职责之一是确保公司随时准备实现战略目标，并为可能的未来变革做好准备。因此我会从阻碍类型出发审视问题——即这些问题阻碍了我近期必须推进的变革。这很困难，因为没人会告诉我答案。发现并掌握这些信息正是我的职责所在。而能否准确把握这一点，正是科技公司成败的关键分水岭。
另一个视角是：若缺乏技术护城河，资金雄厚的风投团队随时可能复制你的成果。若现有技术成为前进阻碍，不妨冷静思考：没有技术债务负担的团队需要多久才能追赶并超越你？因为若答案是“并不困难”，你或许该考虑放弃当前修复方案，重新构建更优解。毕竟终有一天他人会这样做并击败你。有时删除代码比修复更明智。
技术债务是主动的权衡取舍。你似乎在讨论非主动的妥协——比如因需求理解偏差导致的未来适用性偏差。但当系统设计无法应对需求变化，迫使你“搞个丑陋的权宜之计”来交付时，这才是技术债务。
我理解这种区分，但到一定程度就不再特别有帮助，甚至可能适得其反。
当系统规模足够庞大且历经多次变更，其结构已无法适应当前或近期业务需求时，成因已不重要。此时需向非技术决策者说明：若仅从现有用户体验与目标体验的差距出发，当前业务需求所需的开发周期将远超直觉预估——这正是“为什么不能直接…”式讨论的症结所在。此时“技术债务”这个跨越技术鸿沟的比喻才真正发挥作用，它能有效向非技术决策者阐明：为满足新需求必须投入的开发成本。(即“为什么不能直接…”的讨论)。此时“技术债务”这个比喻便跨越了技术鸿沟，成为向非技术型业务领导者有效传达概念的工具(当然需审慎使用)。
若执着于纠缠“技术债务必然是人为造成”的语义区分，反而会削弱这个比喻的实用性——非技术方会质疑工程团队为何故意制造困境。我理解技术人员都有自己的专业偏好(黑客≠黑帽)，但在与非技术人员沟通时，这绝非值得深究的语义之争。
称之为故意为之听起来合情合理，但实际想法可能是“等它出问题时我早就不在了”。
哈。在我上份工作中，我发现我们解决技术问题的能力如此出色，以至于把社会问题转化为艰深的技术难题，从而解决最初的社会问题。这类似于算法复杂度理论中的问题简化。或许存在更简单的社会导向解决方案，但我们缺乏处理这类问题的手段…
若你看不透这点，但愿你别管理这类人…
但说真的，这种债务累积是管理失职。无论是自我管理、中层管理还是脱离实际的管理。优秀管理者之所以必要，自有其道理。遗憾的是，多数管理层要应对的是人际关系和现实世界，而非法律部门提供的刻板RFC规范或供应商需求清单。
我显然被自身经历磨得麻木，但深感企业越来越不重视打造和维系稳固团队。员工被当作机器齿轮对待，这种对待方式反过来也塑造了他们对系统的认知。
在这样的环境中工作实属煎熬。
每当有人试图将陈旧的COBOL代码迁移至Java以消除技术债务时，总有同等数量的人执意要将运行良好的C++代码库重写为Rust/Go/Zig。
真正洞悉这是人际关系问题、且读过杰里·温伯格著作的领导者，才能理解问题的双面性。
在我看来，人员问题本质上是沟通问题的子集。沟通障碍还包括人员不在同一地点(远程工作)或不同步工作(远程协作)。即便隔壁办公室的同事也会成为阻碍提问的障碍。
CodingHorror早在18年前就提出过。https://blog.codinghorror.com/no-matter-what-they-tell-you-i…
顺着链接查阅…原来杰拉尔德·温伯格早在1985年就提出过。天下没有新鲜事，只有永无止境的包装重塑。:)
至少标题让我觉得有道理。
> 大多数技术问题本质是人问题
这完全解释了微软Teams和Windows 11的现状。
[注意没有/s——这100%是人问题，因为掌舵的是错误的人选]
作者为如此艰巨的努力和不眠之夜获得丰厚回报，毫无疑问。
读完文章，注意到作者刻意将超链接设置为深灰色字体配黑色背景。
做出这种刻意选择的工作单元，与智人单元存在沟通障碍也就不足为奇了。
没错，我们进化出了人际关系问题。
但倘若整个进化过程中我们更注重技术层面，如今恐怕只会面临技术问题。
或许我们该开始从技术角度切入。
本文未提及的是：团队臃肿时才会出现人际问题。
由此导致沟通渠道激增且渠道失效。
若产品线仅由最多3名工程师负责，便不会存在沟通障碍。
这点常被低估：n名工程师(节点)间可能发生的个体对话(边)数量并非线性增长。
https://en.wikipedia.org/wiki/Complete_graph
正因如此，当论证XYZ技术成功或失败时，必须从更宏观的人文视角审视其市场普及度的关联结果。
典型案例——PyTorch与Tensorflow之争。PyTorch团队尤其是Soumith无处不在。无论在论坛、推特还是该死的Reddit提问，总能得到解答。
完全赞同。编程本身并不复杂——真正困难的是人为因素、上下文环境和数据复杂性。
这永远循环往复：所有社会问题本质上都是伪装的技术问题；而所有技术问题本质上也是伪装的社会问题。;)
而人员问题几乎总是管理失职所致
这篇文章深有共鸣。我正在为一家技术困境重重的公司提供咨询，但所有问题都源于人员和流程的自我设限。
管理层声称要理解并解决问题，而他们的“解决方案”恰恰暴露了真正症结。方案一：每周安排两次大型团队会议。第一周过后，管理层便销声匿迹，绝大多数会议无人出席。会议彻底脱轨。解决办法？开更多会！
如今我们每天开会，出席率却更低了。
修复方案2——既然不清楚员工在做什么，那就创建仪表盘吧。于是草草拼凑出一个错误百出、漏洞丛生的仪表盘。这倒无妨，因为经理们根本不会查看它。大老板听闻进度仍落后，便强行征召某位产品人员担任行政助理，让她在半秘密状态下维护多份电子表格来追踪所有人的进度。
这份半公开的表格很快彻底曝光，众人发现其中存在无数问题(这不足为奇，毕竟被征召的行政助理原是产品人员，在缺乏指导和协调的情况下，从各种零散渠道拼凑数据)。随后各主管各自建立电子表格，引发了表格大战。
修复方案三——我们决定建立产品需求收集与持续开发的“权威数据源”，并赋予其若干特性(这些特性总体而言并非糟糕)。该方案被交由几位毫无经验的初级员工执行，且全程零反馈。最终结果是：我们依然没有“真相之源”，反而陷入xkcd漫画式的荒诞境地——如今竟有四五个“真相之源”被脚本、胶带、创可贴和祈祷勉强串联起来。
这种状况持续多年。各种想法层出不穷，有好的、坏的、平庸的，但都毫无意义，因为领导层既缺乏跟进能力，也无法展现对团队实际工作的基本理解。
这种状况令人心力交瘁，但在当前就业环境下，又能如何？
我曾供职于文化同样病态的公司。
荒诞至极，但你我皆亲历其境。不知此类现象有多普遍？它既丑陋又令人费解。
当管理层无法有效履职时，就该授权给能干之人。若两者皆无，局面只会沦为混乱——一群愤怒无知的猴子在制造噪音。
> 在当前就业环境下，又能如何？
我目前失业，储备金正迅速耗尽，说实话还在犹豫是否该忍受上述处境。若毫无改善希望，你不过是用精神健康换取几枚豆子罢了。
_def提出的技术债务问题很有意思。依我经验，量化它反而偏离了本质。
真正的代价并非时间损失——而是决策回避。团队开始回避某些模块，新功能绕过问题而非解决问题地开发。最终形成影响所有未来决策的架构疤痕组织。
我亲眼见过这样的场景：所有人都知道需要进行的两周重构被拖延数年，只因没人能给“我们不敢改这段代码”贴上具体金额标签。与此同时，每次冲刺规划都变成绕开恐怖模块的创意比拼。
关键信号是估算值背后那句默认的“……前提是不碰X模块”。
这观点极具洞见。我还见过工程师极力维护架构疤痕的案例——那位工程师至今仍在公司任职。根据我的经验，这类人往往备受尊敬，且总体上是能力出众的工程师，最终整个工程团队只能绕着这些疤痕工作。
感谢阅读！
随着AI的帮助，我对代码的自卑感逐渐消散，对此我有了更深的体会。
顺带一提，在阿德勒心理学中，所有问题都被视为人际问题。
…而大多数人际问题本质上是沟通问题。
将问题统称为“人际问题”虽方便概括，却缺乏足够的细腻度而难以成为有效论断。何为良好沟通？是否存在目标冲突？
> 非技术人员无法直观理解所需投入的精力或技术债务清理的必要性；工程团队必须在初期估算和项目更新中有效传达这些信息。除非领导层具备工程背景，否则技术债务工作的价值往往需要量化并转化为商业价值展示。
工程师常认为沟通需技术化，但管理层使用的语言通常是非技术性的，因此跨领域转化至关重要。我们需要的不是更多工程师，而是懂得技术细节转译的工程师。
我明白在HN上多数人会站在理性技术派立场，但这种自我验证的循环虽能识别问题，却无法解决问题。
我认为我们需要更多能驾驭两种语言的通才。我曾努力成为这样的人，但事实证明几乎无人愿意雇佣这种跨领域沟通者——因此我对整个问题的判断很可能完全错误。
而大多数人的问题本质上都是数学问题。
所有产品问题本质上都是组织问题。
我的意思是，如果你把时间浪费在毫无价值的工作上，人们自然会变得烦躁。若最终耗时还超过承诺，更会加剧这种情绪。
但这并非人员问题。这是未能认清企业支付薪资的本质——是为了创造更多利润，而非打造漂亮的代码库。
没错，这需要传达价值，但这并非人员问题，而是能力问题。
“任何资深工程师以上级别的人员都必须懂得跨职能协作”
若你无法进行跨职能协作且普遍不善于与人相处，那么无论头衔如何虚高，你都不配称为资深工程师。
技术债务本质上并非技术问题，而是决策选择。
总有人在某个节点做出决定：好吧，我们要重复编写代码，同时开发Windows版和Linux版，虽然短期内会很痛苦——但在当前阶段，这是更优解。
有时完成任务比追求完美更重要。
这种决策是否明智，本质上是人的问题。
维护庞大的遗留代码库确实令人抓狂，但每个开发者职业生涯中迟早要面对这类权衡取舍。当那一天来临，或许你会原谅前辈们的选择。
补充说明：
这些权衡往往源于商业困境。十年后回望，你很难看清当年决策背后的糟糕商业环境。或许正是那些商业驱动的抉择——比如不惜一切代价赶工发布产品——才让公司得以存续，才让你今天有工作可做(尽管是收拾残局)。
多数技术问题本质是工作保障问题
我曾参与的团队成功将系统中的关键技术债务削减至背景辐射水平。我认为关键因素包括(部分仅是效率提升，从而腾出更多资源处理技术债务)：
* 团队采用单仓库管理(近乎)全部代码。其优势包括：通过单次提交强制执行服务间契约、在单个PR中完成跨切面变更的提交与审核、提升大规模架构变更的灵活性，以及更轻松地构建跨系统自动工具。
* 我们选用Go语言，事实证明它与单仓库及大型代码库高度契合。Go语言倡导简洁明晰的编程哲学，在诸多代码决策中提供坚实支撑(个人认为效果显著)。该语言尤其擅长开发命令行工具，特别是需要并行处理海量数据导出的场景。
* 团队负责集成工作时，我们确立了核心原则：对API的同步调用应成为极少数例外。异步优先策略使我们能通过时间分散处理大量负载，而非依赖实例扩容(从而规避同步/时序/负载激增问题)。
* 我们把大部分微服务转换成了无状态单体架构。可扩展性并未受到太大影响，因为最终的Go容器仍只有几MB大小，需要时仍能轻松低成本地扩展实例。但能在领域内直接创建和调用函数，而不是创建API并调用其他服务(以及处理相关问题)，这要简单得多。
* 团队规模精简——在我参与期间，开发人员始终维持在3人。当决策仅需与另外两人商议时，技术讨论和决策过程都相当高效。
* 所有开发者都保持开放心态，通常由最热衷某项方案的人先行尝试。若方案失败，后续替换时也不会产生任何情绪纠葛。
* 我们的架构相对简单，执行时注重灵活而非僵化。具体来说，代码审查中发现的问题仅作为建议而非强制要求。开发者可自行修改，若未修改，后续仍可根据实际需求调整。
* 我们受益于早期在生产力提升方面取得的高影响力成果，并利用大量冲刺闲置时间处理持续的技术债务，而非加速功能开发(但并非完全如此，业务方也获得了一些收益)。
* 重大技术债务问题均经过全团队预先讨论规划，我们持续数月对这些难题进行细致的逐步攻克。当某个问题被削弱到不再构成痛点时，便不再投入精力处理(例如将微服务引入单体架构的问题，在大部分重构完成后便不再被关注)。
* 技术债务事项通过我开发的工具https://github.com/liampulles/go-condorcet进行全员排序投票，有效确保每位成员关心的问题都能获得解决机会。投票结果往往高度一致，这意味着当团队意见相同时，我们避免了无谓争论，并达成了共识。我认为这有效维持了团队对整个项目的持续投入。
* 技术栈采用稳健可靠的组合：Postgres、Redis和NATS。虽然NATS在配置调试时确实遇到过些问题(它也是最不“无聊”的部分)，但团队中几位精通Kubernetes的成员有效化解了挑战。
* 我们开发了发布工具命令行界面，并构建了相当完善的系统通用错误预警机制(主要基于日志，辅以Sentry和基础设施警报)，使发布流程变得轻松。这不仅提升了整体效率，更意味着更多小规模发布得以实现，且出现问题时更易回滚。
* 我们拥有出色的产品经理，他真正与我们携手推进企业级项目，并竭力使项目真正实现敏捷开发——尽管公司其他部门并不具备技术背景。
> 团队“看似高效”的印象与实际产出同样重要。
这话或许有理。但我厌恶这种观念。我该放弃软件工程了。
PEBCAK
此文一针见血。即便最契合组织目标的工程方案，最终也常被某些人扼杀——他们为维护自身政治地位而非改善组织或工作环境。
所以每当听人宣称科技界是精英治世，我总忍不住发笑。除非你把操纵、剥削、诡计、破坏和背后捅刀视为功绩；否则现实世界里根本不存在精英治国——只要某个掌权者能因一时不快就毁掉你的职业生涯或生计。
尽管我多么希望所有问题都能化作技术难题来解决，但现实并非如此。若想推动某项进展，就必须倾听跨部门的声音，设法争取他们的支持。此刻我正身处一家固守1990年代思维的企业里做这件事，简直糟透了。
这让我想起归于斯大林名下的那句箴言：
“死亡解决一切问题，人死了，问题就解决了。”
“人类行为引发的大多数问题本质上是人际问题。”
我也能写篇类似文章：多数人际问题其实是技术问题。
这篇文章戳中了我的痛点。
许多企业和个人都能从优化流程、提升沟通技巧和加强培训中获益。
而那些宣称“多数技术问题本质是人问题”、“关键不在你懂什么而在你认识谁”的人，往往正试图向他人灌输“我的技能比你更有价值”的观念。真正持相反观点的人….
因此尽管存在标准叙事——“若进行五问追溯因果，问题终将归结为更深层的人为因素”——但你几乎总能另辟蹊径，找到替代的技术解决方案。
标准叙事是这样的：“这个组件故障是因为另一个组件崩溃，而崩溃源于配置错误，错误又源于部署脚本执行失误，而失误根源在于没人教鲍勃如何操作。” 看，人因问题才是最根本的，对吧？
但你其实能找到技术替代方案：为何部署脚本会被错误执行？
或者你也能将问题弹回技术层面：他没受培训是因为架构缺陷和缺乏CI导致系统频频崩溃，导致所有人压力山大无暇培训。所以技术问题才是最根本的。
但不，这根本源于CEO聘用了不合格的CTO——因为他根本不认识能正确评估技术人才的人……
……而这种情况的发生，又源于他们没用<帮助评估工程师的初创公司>(技术问题)
……而该初创公司未能做好充分营销(人为问题)
…这仅仅是因为他们解决技术债务的速度太慢，又没有足够资金(技术问题…)
诸如此类。来回推诿。
文章指出：技术债务过多源于人员培训不足。
也可以这样说：技术债务堆积如山，是因为我们缺乏足够强大的代码检查工具和代码克隆检测器来防范常见问题，同时我们最初做出了糟糕的技术选择，导致必须组建规模庞大的团队。
当你执着于某个特定问题时，总能说服自己它才是所有灾难的根源。这种思维只会让你丧失全局视野，错失最佳解决方案。
康威定律又来了！
不。
> 多数技术问题本质上是人际问题。想想看：技术债务为何存在？因为工作启动前需求未被充分明确；因为销售人员向客户承诺了不切实际的期限；因为开发者因惯性选择过时技术；因为管理层反应迟钝中途取消项目；因为某人的自负阻碍了更优方案的采纳。
说到底，技术债务本质是人的问题。为何会产生？因为团队人手不足。因为团队能力欠缺。因为开发者承诺圣诞节前完成任务却未能兑现。
我其实不太喜欢市场营销，但他们确实承担着重要职能：将代码转化为金钱。代码本身毫无价值，唯有经过市场营销的代码才具有价值。这就是重构如此艰难的根源。
编程界还存在一条不成文法则：易于重构的代码终将被难以重构的代码取代。人们常误判技术债务的本质，将非债务代码强行转化为债务代码——只因自以为更懂技术，最终导致这些债务永难消除。
人本身不是问题。这是反社会者的论调。他们想用AI取代你，正是因为视你为问题根源。
这并非文章核心。文章探讨的是沟通失败的问题。
在我看来这并非问题，而是将仅以工作场所为纽带的陌生人强行聚合的现实。症结在于制度，而非个体。
若你认为与同事唯一的联系仅是雇佣关系，那你确实说对了。