选择自己而不内疚：作为开发者我艰难领悟的教训

Source: Dev.to

Introduction

我曾以为好开发者会对所有事情说“是”——那些并不快速的快速修复，觉得说“不”是不负责任的，而把自己放在第一位则显得自私。倦怠、错过的截止日期以及悄然失去的动力迫使我面对一个不舒服的真相。

The Backstory (Why This Matters)

• 我相信自己会学得更快，受到更多尊重，最终变得自信。
• 所以我不断超额承诺：额外的工单、额外的上下文切换、额外的情感劳动。

The Core Idea

选择自己并不是要少干活。

• 我们不会让服务器永远以 100 % CPU 运行。
• 我们会添加速率限制来保护系统。
• 我们为故障而设计，而不是为完美而设计。

对待我们自己时，同样的原则同样适用。

Implementation: What “Choosing Yourself” Looked Like in Practice

Setting Boundaries Like You Set API Contracts

我开始把我的时间当作接口来对待：

• 明确的期望
• 明确的限制
• 没有隐藏的副作用

我不再说“当然，我也可以处理那个”，而是说“我可以帮忙，但今天不行，我已经满负荷”。虽然有点尴尬，但没有任何东西崩溃。

Reducing Context Switching (On Purpose)

我注意到自己在：

• 帮助多个团队
• 处理不相关的任务
• 从未完成深度工作

于是我限制了自己的“打开的线程”，专注于更少但影响更大的事项。

Stopping the Hero Mentality

我不需要总是那个拯救局面的人。

• 成为不可或缺是一种脆弱的架构。
• 我记录得更多，委派得更多，也更信任他人。

团队没有崩溃，反而变得更健康。

What Went Wrong (Lessons Learned)

• 我的动力消失了。
• 学习变得沉重。
• 即使是“简单”的任务也让人筋疲力尽。

我意识到罪恶感往往是滞后的指示器——就像只有在故障后才查看的日志。

Best Practices (Developer Edition)

• 把你的能量当作有限资源来对待。
• 给消耗你的工作加上“超时”。
• 像审视技术债务一样审查你的承诺。
• 优化长期吞吐量，而不是短期产出。

可持续的开发者写出更好的代码。

Common Pitfalls

• 把可用性误认为价值。
• 认为休息必须“赚取”。
• 以为说“不”会让你变得可替代。
• 等待许可来保护自己的时间。

这些都无法扩展。

Community Discussion

我很好奇：

• 作为开发者，你设立的最难的边界是什么？
• 你是否曾把倦怠误认为是“只需要更努力工作”？
• 什么帮助你在不后悔的情况下选择了自己？

在评论中分享你的经验——这是我们谈论得不够多的话题之一。

FAQ

What if my team expects constant availability?
设定明确的期望，协商合理的值班或响应窗口，并传达持续中断对整体生产力的影响。

Final Thoughts

选择自己并不意味着你对团队的关心减少。对自己也同样好是可以的。