[译]什么样的工程师才能算老司机
原文链接：Seniority
人们使用不同的方式来定义工程师的水平，有些公司粗暴的通过工作经验来判断是否资深，但是什么样的工程师才能算资深老司机？下文将列出我的判断依据。
API 不是重点
如果你认为老司机就是 API 记得熟，你就错了。
确实如果对相关 API 比较熟练开发的时候你会比较快，但是熟知一些特定的 API 并不是核心技能，因为只要有足够的时间任何开发者都迟早会对 API 熟练。
不同的公司对于职称的评定区别巨大，有的就是单纯的根据工作年限，也有更不靠谱的就看你在管理的时候和其他同事的关系处的怎么样。
重要的不是你现在是什么职位，在于你在团队中怎么表现。
技术能力通常会随着工作经验逐渐变强。我更想聚焦被很多人忽略的东西：软技能（soft kills）。我把软技能分成个人品质和团队协作两块来看。
个人品质
可靠
一定要可靠，信守承诺，答应的事能够完成，不要失误。
很多时候他人的工作依赖于你的进度，因此要评估一个准确安全的 deadline，不要承诺的太美好最后又无法按时交付。
在提前完成了工作后，总会有一些其他的任务可以主动的找出来做。老司机不会在完成工作后被动的等待别人给他分配工作，会主动的找打到一些事情做。
敢于承担
只有什么都不做的人才不会犯错误。
犯错或者进度受阻都是很正常的事。经验丰富的人会知道什么时候应该让其他人知道遇到困难，并且不会害怕需求帮助支持。
不要害怕承认你的错误，是人都会犯错，公开承认会让其他人更加信任你。
拥抱变化
不要局限在特定框架或者语言上。有一件事是确定的：无论你是否愿意，你的职业生涯里使用的框架会改变很多次。早期职业生涯里我使用的语言很多现在都没人用了。
应该要拥抱变化，强迫自己挑战原有的假设，这样会让你少忽视其他的技术流派。总是有其他可能存在。
我会经常做业余项目，并且我有一条规则：每半年都要尝试不同的方式实现。
这样会让我可以分辨哪个才是最好的解决方案。禀赋效应（Endowment bias）描述的就是当你拥有一个东西的时候，对它的价值评估会超过真实的价值（php 是最好的语言）。
需要注意的是改变是有难度的也需要时间。尝试一段时间后坚持下去不要放弃。
实用主义
很多程序员只关注软件工程的问题，追求高代码质量，然而忽略了软件的商业意义。好的代码并不是我们工作的真正目标。老板雇佣我们是为了他们业务解决遇到的特定问题，也许是一个 APP 或者其他什么软件，不是为了让你写出优美的代码。交付好的产品才是最重要的。
你需要投入时间去理解业务需求，只有了解了需求后才能做出适合的选择，聚焦在真正重要的部分。
团队协作
凭借一己之力开发出一个软件产品是很少见的，大部分时间我们都需要和其他成员一起协作。花时间学习如何融入一个团队，这会让你的职业生涯产生巨大的飞跃。
以身作则
如果你：
- 空闲时主动去解决遗留问题
- 总是尝试改善架构和工具链
- 指导他人，自愿去做结对编程或者帮助他人解决问题
- 给出空间让每个人表达他们的观点并且进行讨论
- 公平对待每个参与者
你的同事就会越来越尊敬你，同时你也会对团队文化产生影响。
其他成员也会受你的这些行为影响，你的团队也会变的更有活力。
听取他人意见
在工程里，要达到一个目的可以有很多种方式。太容易就按部就班的就用我们习惯熟知的方式。我们需要锻炼我们的灵活性。要乐于听取其他意见，不要仅仅因为与你所习惯的方式不同就无视了其他人的观点。
花时间与他人讨论他们的意见，更好的了解他们的方式和方案怎么工作，所有的好处和坏处等。直到你可以确定哪个方案是更好的为止。
这些方案是否是一个比你资深的工程师提出的并不重要。我从团队里的新手工程师也学到了不少东西，他们经常会有新颖的想法并且挑战原有的假设。这里也顺带提出我另外一个重要的观点：不要利用你是‘老人’的权力。
永远不要认为他人“低级”。不要说出诸如“我们就这么干因为你要听我的”，“我已经干了多少年了就这么干”这样的话。这样的行为会让人觉得这个工程师幼稚就像一个小孩，一点都不专业。不要这么做。
- 用事实证明。如果找不到理由支撑你的观点，可能你的观点就不是最好的
- 不要过激，讨论过程中或许有冲突，但是老司机知道批评一件事并不是批评一个人，对事不对人
- 在回复前思考清楚，不要打断其他人。让他们处理完手头的工作再和他们进行讨论
学习如何控制你的冲动和情绪对于你和其他人融洽相处是非常重要的。
学习进行时间管理可以让你保持明智。
可以看下我之前的文章：推荐几本我认为必读的书。
成为其他开发者的导师
指导其他开发者是非常有益的一件事，同时也可以培养正确的团队文化。
我希望团队里所有成员都可以对我放心的提问。也许是某个工作应该怎么做或者质疑我的决定。
我看到一些团队里的成员害怕提问，因为“经理看起来很可怕”，并且把寻求帮助当做员工能力的考核之一。
应当鼓励成员遇到困难寻求帮助或者遇到困难时寻求建议。
如果你想要成为一个神奇的10倍工程师（10x engineer），帮助团队里的其他工程师成长。记住：没有愚蠢的问题，如果有人对你的代码有问题通常意味着你的代码不够简单或者有改进的空间。
积极寻求方式改进现有方案
没有一个方案是完美的。你应该总是思考如何改进。
如果你批评某件事，你应该总是提出一个改进的方案。
如果你在写代码时发现一个痛点，或者观察到你的同事有痛点，思考如何解决它。
如果一件事情重复发生了两次别急于开始写一个库或者工具来解决它。如果真这个问题真的存在，它一定会在不同的人身上重复出现多次，这个时候再开始着手解决改进它。
iOS 社区是我见过最好的社区之一。我会鼓励你去开源这些工具或者库，并且分享你解决问题的经验给他人。把一些东西写下来你会发现你还有很多不足。
可以通过订阅社区的新闻来获取 idea，比如订阅 iOS Dev Weekly 和 Swift News。
拒绝不健康的团队文化
这点我怎么强调也不过分，我看过很多人吐槽他们团队文化好几年，我的问题总是“那你做了些什么？”。
对于不健康的团队文化你应该勇敢的抗争，如果你看到某人的行为不对不要害怕提出来。提出建议就像平常的交流和代码的管理一样。
我对这件事的观点很简单：
如果我看见某些我不喜欢的事，我会在团队里提出来。否则团队会变得越来越糟，如果这样我就走人
既然你反正最后都会走，那为什么害怕提出来并且抗争？
很多人会害怕讲出来，尤其是少数派（黑人？）或者内向型的人。通常这样的人连谢谢都是私下过来对你说。
场景应该是这样的：
- 每个人都是平等的，确保每个人都可以自由表达他的观点，即使这些人很害羞
- 当一个人被意外打断的时候，保证他的观点可以继续说完，比如“老王，你接着刚才的话继续说”
总结
成为一个好的开发者和团队成员比学习编程需要了解更多。你的技术水平会随着工作经验的增加而提高，然而如果你不注意投入时间提高你的软技能，最后就会成为你职业生涯里的瓶颈，你甚至都没有意识到这点。
欢迎关注我的微博：@没故事的卓同学
