给软件工程师的危险建议
原始链接：https://www.seangoedecke.com/dangerous-advice
我很喜欢“锋利的工具”。这类工具功能强大，用好了能帮大忙，用不好则破坏力惊人。大部分直接操作生产环境的工具都属于这一类，比如 SSH、kubectl 或是拥有读写权限的生产数据库控制台。
同样，给人建议也可以是“危险的”。危险的建议和锋利的工具一样，需要你有足够的能力和判断力才能驾驭。把危险的建议给错人，就像把生产数据库的权限给错人一样——他们可能会搞出巨大的破坏。
我在这个博客里给过很多危险的建议。比如，我建议读者：
我也会担心：万一读者选错了工作方向，或者用错误的方式打破了规则该怎么办？我不希望自己的文章毁了别人的职业生涯。但我依然认为，这些危险的建议必须在某个地方被记录下来。
多数职业建议都是扯淡
最大的原因是：优秀的工程师非常渴望这些危险的建议，就像他们渴望锋利的工具一样。大部分职场建议都是假的，要么是为了推卸责任，要么是为了表面光鲜。如果你真的想把事情办成，你迟早会用到其中一些建议，因为它们确实管用。
如果你知道公司的官方流程根本行不通，但又没人能跟你坦诚交流，这会让你感到非常孤独。当我还是一名初级工程师时，我非常感激那些愿意私下跟我说大实话的同行。
你的经理不会告诉你这些
另一个原因是：经理几乎从不会给你这些危险的建议，哪怕你真的需要听。
如果经理告诉你别管公司规定，而你搞砸了（比如你在 Slack 里大声嚷嚷你在违规，还说是经理允许的），那经理的麻烦就大了，比你的麻烦大得多。在科技公司高层眼里，工程师往往是“有用的干电池”，而经理必须是“懂规矩的专业人士”。
不过，很多经理心里其实很想给你这类建议，要是你能心领神会并照做，他们会非常感激。我没当过经理，但想想要是能让手下的优秀工程师讲究点策略、别死盯着岗位说明书干活，那该多棒。
听从危险的建议需要勇气。它高风险、高回报，对优秀的工程师极有帮助（但会害了平庸的人）。如果你觉得不适，那就千万别照做。但如果你平时就是这么干的，并且总担心自己是不是在犯什么长期的致命错误——我觉得不是。退一万步说，就算你错了，我也在陪你犯同样的错！
更新： 这篇文章被发到了 Hacker News 上，评论两极分化。这让我有些后悔没有把我上一篇文章 《优秀的工程师如何打破规则且安然无恙》 里的观点也写进来。
对于那些给差评的人，我最大的分歧在于：他们似乎认为，组织就是那些写在纸上的规则，且组织的主要运作模式就是正式的、结构化的合作。我打算专门写篇文章反驳这一点，我认为这犯了经典的《国家的视角》（Seeing Like A State）谬误——过度强调清晰性与表面合规（legibility）。所有的群体都有其心照不宣、不成文的隐性运作机制。本文（以及我这个博客的大部分内容）的核心观点正是：你应该多去思考工作中那些不成文的隐性部分。（更新：那篇文章写好了，叫作 《软件公司的视角》）
如果你喜欢这篇文章，欢迎订阅我的新文章邮件推送，或者把它分享到 Hacker News。以下是一篇相关标签文章的预览：
软件工程中的“超出替代者的额外价值”
评估你作为工程师创造了多少价值，有两种方式。第一种是把你交付的所有代码以及这些代码产生的收益（比如赚了多少钱）加起来。第二种方式是，搞清楚有哪些事情是只有你能做，而换个普通工程师来就做不成的。换句话说，你可以看自己的绝对价值，也可以看你超出替代者的额外价值。
继续阅读...
