工程师入职培训的冷门观点 | AI生成和翻译
问题：作为一名软件工程师，关于融入新团队有哪些不受欢迎的观点？
回答：
以下是一些真正不受欢迎（但经验丰富的工程师私下常会认同）的关于入职的观点：
- 大多数正式的入职培训项目都只是形式主义。 两周的人力资源幻灯片、像闪电约会一样的“认识团队”环节以及维基寻宝游戏，很少能教会你工作实际是如何进行的有用信息。真正的入职是通过交付代码、尝试犯错以及同事帮助解决问题来实现的，而不是通过完成一份清单。
- 你应该在第一周（最迟两周）内将代码推到生产环境。 在接触任何实际内容之前，等待2-6周“学习代码库”是一种不好的迹象。了解真实架构、部署流程和团队政治最快的方法是进行一项小型、可见的更改，并将其一直推送到生产环境。任何低于此的都是虚假的生产力。
- 入职期间结对编程通常是浪费资深工程师的时间。 它让人感觉是协作，但它主要将资深工程师变成了缓慢的谷歌搜索工具，而新员工变成了旁观者。带有快速反馈循环（并慷慨提供“问任何问题”的Slack访问权限）的独立任务能更好地扩展，并更快地培养所有权感。
- “先读文档”是糟糕的建议。 大多数内部文档都是过时的、不完整的或错误的。学习当前系统最快的方法是grep代码库、阅读最近的PRs并提出关键问题。文档是补充，而不是起点。
- 被“阻塞”几天是不可接受的，通常是自找的。 如果你被卡住超过几个小时，你可能过于礼貌或在等待许可。优秀的团队期望新员工积极地ping、@-channel或主动发起通话。礼貌会减缓学习速度。
- “导师”系统很少奏效。 将一个人指定为你唯一的求助对象会造成瓶颈和单点故障。更好的做法是：在新员工入职的第一个月，允许他们随时打扰任何人。
- 架构图和入职材料是骗人的。 它们展示的是某人希望系统如何工作，而不是它实际如何工作。相比漂亮的方框和箭头，更应相信测试、监控面板和生产日志。
- 冒名顶替综合症的抱怨被高估了。 大多数新员工在3-6个月内感到迷茫——这是正常的，不是个人失误，也绝对不是团队需要用额外的安慰仪式来呵护的。
- “没有愚蠢的问题”是资深工程师对初级工程师撒的谎。 当然有愚蠢的问题（比如第一周就问：“我们为什么不直接用Rust重写呢？”），但如果问了之后学习得很快，好的团队会原谅他们。
- 最好的入职指标是“到第二个PR的时间”，而不是“到第一个PR的时间”。 任何人都可以修改一个错别字。第二个PR证明你理解了第一个PR的反馈，并且可以独立操作。
这些观点之所以不受欢迎，是因为它们与当前行业对“心理安全”、漫长的适应期以及让新员工感到温暖舒适的痴迷相冲突。事实上，我见过的适应最快的工程师将入职视为一项全身心的运动，而非一次温和的引导。