梦想不会自行实现，除非你付出行动：作为开发者我吃过的苦头
I’m happy to translate the article for you, but it looks like the body of the text wasn’t included in your message. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide the Simplified Chinese translation while preserving the original formatting.
Introduction
几年前，我拥有一个干净的 GitHub 主页，收藏了数十篇教程，怀揣着成为“扎实工程师”的宏大梦想。
我缺少的是什么？我一直对自己说自己在“准备”。
事实让人不舒服：除非你付诸行动，否则梦想不会实现——在软件工程中，行动意味着写出不完美的代码、制造错误，并且持续出现。本文讲述了我最终领悟的关键——以及为何这种思维方式比你现在学习的任何框架都更重要。
背景故事（为何重要）
大多数我遇到的开发者并不懒惰。他们通常是：
- 过度准备
- 担心做错事
- 等待感觉准备好
我也是一样。我曾相信：
- “一旦我完成这门课程，我就开始动手做项目。”
- “一旦我把所有东西都弄懂，我就去申请工作。”
- “一旦我有信心，我就会分享我的作品。”
那个时刻从未到来。改变我轨迹的并不是动力。
核心理念
“Dreams don’t work unless you do” 听起来像一句励志格言，但对开发者而言，它是 你职业生涯的系统设计原则。实际上它意味着：
- 学习发生在实现之后，而不是之前。
- 清晰来自反馈，而不是无尽的思考。
- 信心是重复的副作用。
你不是通过计划写代码来成为更好的开发者；你是通过 实践 成为更好的开发者。
实现：对我而言“动手做”是什么样子
在还没准备好之前就开始构建
我不再问：“我准备好构建这个了吗？” 而是问：“我能交付的最小、仍有缺陷的版本是什么？”
这意味着：
- 丑陋的 UI
- 硬编码的数值
- 缺失的边缘情况
但这也产生了动力。
把副项目当作正式产品来对待
我给副项目制定了真实的规则：
- 完整的 README
- 明确的问题陈述
- 部署到某处（即使不完美）
仅仅这种转变就让我学到的东西超过了数月的教程。
通过 Bug 学习（而非课程）
一次生产环境的 bug 教会我的东西比五篇博客文章都多。下面是我曾经随手写的一个重试函数，写时并没有深入思考失败情况：
export async function retry(fn, attempts = 3) {
for (let i = 0; i < attempts; i++) {
try {
return await fn();
} catch (err) {
if (i === attempts - 1) throw err;
}
}
}在生产环境中，它引发了真实的问题：
- 重试是否应该使用指数退避？
- 哪些错误应该被重试？
- 何时重试实际上会让情况更糟？
👉 动手做的过程暴露了这些空白。
出错了（经验教训）
我犯了很多错误：
- 构建了没人需要的项目
- 对早期功能过度设计
- 在追逐潮流时忽视了基础
每个错误都有隐藏的好处：它创造了上下文。没有上下文，建议难以落地。
我想与任何开发者分享的最佳实践
- 一致性胜过强度
- 公开构建（即使不完美）
- 完成小任务
- 将学习视为迭代
常见陷阱
- 教程囤积
- 等待自信后才开始
- 把自己的第 1 章和别人的第 20 章比较
- 优化工具而不是结果
如果这让你觉得很个人化——我也有同感。
社区讨论
我很想听听你的想法：
- 你曾经计划但从未发布的项目是什么？
- 最终是什么帮助你从学习转向实践？
- 现在是什么在阻碍你？
👇 在评论中留下你的想法——这是一段共同的旅程。
FAQ
问：系统和习惯是否胜过动力？
答：是的。系统和习惯每次都胜过动力。
问：如果我不知道该构建什么怎么办？
答：构建一些乏味的东西。真实的问题能教会真实的技能。
问：这对高级开发者也适用吗？
答：当然。工具会变化，但执行仍然重要。
最后的思考
梦想很重要，但在软件工程中，执行是乘数。你不需要更多灵感；你需要：
- 一个 Pull Request
- 一个已部署的应用
- 一个你自己修复的损坏功能
因为归根结底 — 梦想不会实现，除非你去做。