原文鏈接：Seniority

人們使用不同的方式來定義工程師的水平，有些公司粗暴的通過工作經驗來判斷是否資深，但是什么樣的工程師才能算資深老司機？下文將列出我的判斷依據。

API 不是重點

如果你認為老司機就是 API 記得熟，你就錯了。

確實如果對相關 API 比較熟練開發的時候你會比較快，但是熟知一些特定的 API 并不是核心技能，因為只要有足夠的時間任何開發者都遲早會對 API 熟練。

不同的公司對于職稱的評定區別巨大，有的就是單純的根據工作年限，也有更不靠譜的就看你在管理的時候和其他同事的關系處的怎么樣。

重要的不是你現在是什么職位，在于你在團隊中怎么表現。

技術能力通常會隨著工作經驗逐漸變強。我更想聚焦被很多人忽略的東西：軟技能（soft kills）。我把軟技能分成個人品質和團隊協作兩塊來看。

個人品質

可靠

一定要可靠，信守承諾，答應的事能夠完成，不要失誤。

很多時候他人的工作依賴于你的進度，因此要評估一個準確安全的 deadline，不要承諾的太美好最后又無法按時交付。

在提前完成了工作后，總會有一些其他的任務可以主動的找出來做。老司機不會在完成工作后被動的等待別人給他分配工作，會主動的找打到一些事情做。

敢于承擔

只有什么都不做的人才不會犯錯誤。

犯錯或者進度受阻都是很正常的事。經驗豐富的人會知道什么時候應該讓其他人知道遇到困難，并且不會害怕需求幫助支持。

不要害怕承認你的錯誤，是人都會犯錯，公開承認會讓其他人更加信任你。

擁抱變化

不要局限在特定框架或者語言上。有一件事是確定的：無論你是否愿意，你的職業生涯里使用的框架會改變很多次。早期職業生涯里我使用的語言很多現在都沒人用了。

應該要擁抱變化，強迫自己挑戰原有的假設，這樣會讓你少忽視其他的技術流派。總是有其他可能存在。

我會經常做業余項目，并且我有一條規則：每半年都要嘗試不同的方式實現。

這樣會讓我可以分辨哪個才是最好的解決方案。稟賦效應（Endowment bias）描述的就是當你擁有一個東西的時候，對它的價值評估會超過真實的價值（php 是最好的語言）。

需要注意的是改變是有難度的也需要時間。嘗試一段時間后堅持下去不要放棄。

實用主義

很多程序員只關注軟件工程的問題，追求高代碼質量，然而忽略了軟件的商業意義。好的代碼并不是我們工作的真正目標。老板雇傭我們是為了他們業務解決遇到的特定問題，也許是一個 APP 或者其他什么軟件，不是為了讓你寫出優美的代碼。交付好的產品才是最重要的。

你需要投入時間去理解業務需求，只有了解了需求后才能做出適合的選擇，聚焦在真正重要的部分。

團隊協作

憑借一己之力開發出一個軟件產品是很少見的，大部分時間我們都需要和其他成員一起協作。花時間學習如何融入一個團隊，這會讓你的職業生涯產生巨大的飛躍。

以身作則

如果你：

• 空閑時主動去解決遺留問題
• 總是嘗試改善架構和工具鏈
• 指導他人，自愿去做結對編程或者幫助他人解決問題
• 給出空間讓每個人表達他們的觀點并且進行討論
• 公平對待每個參與者

你的同事就會越來越尊敬你，同時你也會對團隊文化產生影響。

其他成員也會受你的這些行為影響，你的團隊也會變的更有活力。

聽取他人意見

在工程里，要達到一個目的可以有很多種方式。太容易就按部就班的就用我們習慣熟知的方式。我們需要鍛煉我們的靈活性。要樂于聽取其他意見，不要僅僅因為與你所習慣的方式不同就無視了其他人的觀點。

花時間與他人討論他們的意見，更好的了解他們的方式和方案怎么工作，所有的好處和壞處等。直到你可以確定哪個方案是更好的為止。

這些方案是否是一個比你資深的工程師提出的并不重要。我從團隊里的新手工程師也學到了不少東西，他們經常會有新穎的想法并且挑戰原有的假設。這里也順帶提出我另外一個重要的觀點：不要利用你是‘老人’的權力。

永遠不要認為他人“低級”。不要說出諸如“我們就這么干因為你要聽我的”，“我已經干了多少年了就這么干”這樣的話。這樣的行為會讓人覺得這個工程師幼稚就像一個小孩，一點都不專業。不要這么做。

• 用事實證明。如果找不到理由支撐你的觀點，可能你的觀點就不是最好的
• 不要過激，討論過程中或許有沖突，但是老司機知道批評一件事并不是批評一個人，對事不對人
• 在回復前思考清楚，不要打斷其他人。讓他們處理完手頭的工作再和他們進行討論

學習如何控制你的沖動和情緒對于你和其他人融洽相處是非常重要的。
學習進行時間管理可以讓你保持明智。

可以看下我之前的文章：推薦幾本我認為必讀的書。

成為其他開發者的導師

指導其他開發者是非常有益的一件事，同時也可以培養正確的團隊文化。

我希望團隊里所有成員都可以對我放心的提問。也許是某個工作應該怎么做或者質疑我的決定。

我看到一些團隊里的成員害怕提問，因為“經理看起來很可怕”，并且把尋求幫助當做員工能力的考核之一。

應當鼓勵成員遇到困難尋求幫助或者遇到困難時尋求建議。

如果你想要成為一個神奇的10倍工程師（10x engineer），幫助團隊里的其他工程師成長。記住：沒有愚蠢的問題，如果有人對你的代碼有問題通常意味著你的代碼不夠簡單或者有改進的空間。

積極尋求方式改進現有方案

沒有一個方案是完美的。你應該總是思考如何改進。

如果你批評某件事，你應該總是提出一個改進的方案。

如果你在寫代碼時發現一個痛點，或者觀察到你的同事有痛點，思考如何解決它。

如果一件事情重復發生了兩次別急于開始寫一個庫或者工具來解決它。如果真這個問題真的存在，它一定會在不同的人身上重復出現多次，這個時候再開始著手解決改進它。

iOS 社區是我見過最好的社區之一。我會鼓勵你去開源這些工具或者庫，并且分享你解決問題的經驗給他人。把一些東西寫下來你會發現你還有很多不足。

可以通過訂閱社區的新聞來獲取 idea，比如訂閱 iOS Dev Weekly 和 Swift News。

拒絕不健康的團隊文化

這點我怎么強調也不過分，我看過很多人吐槽他們團隊文化好幾年，我的問題總是“那你做了些什么？”。
對于不健康的團隊文化你應該勇敢的抗爭，如果你看到某人的行為不對不要害怕提出來。提出建議就像平常的交流和代碼的管理一樣。
我對這件事的觀點很簡單：

如果我看見某些我不喜歡的事，我會在團隊里提出來。否則團隊會變得越來越糟，如果這樣我就走人
既然你反正最后都會走，那為什么害怕提出來并且抗爭？

很多人會害怕講出來，尤其是少數派（黑人？）或者內向型的人。通常這樣的人連謝謝都是私下過來對你說。

場景應該是這樣的：

• 每個人都是平等的，確保每個人都可以自由表達他的觀點，即使這些人很害羞
• 當一個人被意外打斷的時候，保證他的觀點可以繼續說完，比如“老王，你接著剛才的話繼續說”

總結

成為一個好的開發者和團隊成員比學習編程需要了解更多。你的技術水平會隨著工作經驗的增加而提高，然而如果你不注意投入時間提高你的軟技能，最后就會成為你職業生涯里的瓶頸，你甚至都沒有意識到這點。

歡迎關注我的微博：@沒故事的卓同學