• 資歷
  • 資歷和戰略思維
  • 以身作則
  • 團隊效率
  • 冒名頂替者綜合癥（將成功歸因于運氣，而不是自己的努力或能力）
• 指導
  • 指導他人
  • 組織范圍內指導
  • 輔導者的角色
• 高效的團隊
  • 建立信任
  • 理解業務模式
  • 增加你的影響
  • 作業和生活的平衡
  • 時間管理
• 結論

資歷

我們渴望在我們的職業生涯中成長，無論是在我們的角色或能力方面，雖然有些人對高級技術職位感興趣，但其他人希望擔任領導或管理職位，無論哪種情況，資歷較高的人都會表現出一些關鍵特征， 在您的整個旅程中，您可能會有導師來指導您的成長，這是我培養可以為高級職位做好準備的素質的方法，

資歷和戰略思維

對于不確定的東西，不要不做決定或不采取行動，
很多時候你會發現做任何決定總比不做決定要好，它至少可以讓其他人知道你傾向于什么方向，有時，作為領導者，我們沒有花足夠的時間來思考團隊希望我們做出什么樣的決定，但事實并非如此，因為我們不能 100% 確定我們掌握了所有事實，我們應該嘗試盡可能完整地了解做出自信決策所需的細節，但這并不總是可能的（例如在時間緊迫的情況下），這可能會導致團隊長時間的等待/不確定性，即使在資訊有限的情況下，它也可以幫助積極地提高自己的決策水平，領導者是拓寬視野、進行戰略思考并為他人制定路線圖的人，理想情況下，您的戰略性思考和計劃能力以及將您的想法應用于更大范圍的能力應該隨著經驗而增長，作為個人貢獻者，您可以專注于分配的任務或您正在處理的功能，當你爬上梯子時，你的作業的影響超出了特定的任務和專案，在權衡選項時，您將學會從利益和限制的角度來看待更大的情景，軟技能的應用范圍也在擴大，例如，如果早些時候您為團隊做出決策或與團隊中的其他工程師交談，那么隨著您的成長，您的選擇和溝通會影響多個團隊，

以身作則

教你的團隊如何解決問題，不要總是為他們解決問題，而是引導他們培養解決問題的能力，
領導者授權給工程師處理作業，當你處在更高級的崗位時，讓你的團隊取得成功，這就是您作業衡量有效性的方式，這可以通過多問好問題來完成，而不是僅僅給出答案，您在評估具有挑戰性的問題時以身作則，并在有人提供解決方案時提出相關問題，技術領域的資深人士負責團隊內外的協調、談判和建立共識， 他們有助于提高整體團隊的產出，而不僅僅是他們自己的， 作為一名高級工程師，您可能偶爾會撰寫代碼以獲取新技能或了解實際情況，但這不是您作業描述的一部分， 相反，您是確保架構圖中沒有任何缺失部分或代碼中沒有漏洞的人， 您應該能夠用證據或理由來解釋您的決定，說明它們將如何提供技識訓商業價值，高級工程師應該擅長架構軟體系統和領導團隊， 你可以領導一個多元化的工程師團隊，將任務委派給他們，指導他們關心代碼質量/性能/簡單性， 您可以在需要時提供反饋，并在必要時為他們辯護， 同時，您應該能夠推銷您自己、您的作業以及您解決具有挑戰性問題的能力，從而在組織中獲得知名度，總體而言，您應該管理與團隊中的人員和管理層的關系，

團隊效率

世界上最好的工程壯舉是由工程師團隊完成的，而不是個人，所以，如果你想要完成更多的任務，或者表明你已經準備好在公司里變得更“資深”，那就通過合作和指導來提高你的效率，證明這不僅為你自己，也為你團隊的其他成員增加了價值，當我意識到要提高自己的效率，我必須把我的思維模式從“我”轉變為“我們”時，我感覺我正在成為谷歌的高級工程師，通過與他人合作，分享我學到的東西，并專注于提升我周圍人的技能和專業知識，我們開始完成更多的作業，當你開始作為一個獨立的貢獻者，你可能沒有一個專門的“團隊”，你領導，但你可以找到志同道合的人合作(也許與你的目標一致)，一起作業，完成比你一個人可以完成的更多，當你的職位越高，你就會越傾向于構建團隊，不斷提高自己的效率，

冒名頂替者綜合癥（將成功歸因于運氣，而不是自己的努力或能力）

允許自己犯錯、不知道答案或尋求指導，這有助于克服冒名頂替者綜合癥，
我們所有人都曾在某些時候覺得自己不適合某個特定的角色或作業，冒名頂替者綜合癥是真實的，非常普遍，它甚至可以影響那些明顯成功的人，你可能會覺得自己像個冒名頂替者，盡管其他人都在向你尋求建議，你可能永遠無法治愈這種綜合癥，但它會促使你保持好奇心，學習新事物，

指導

指導他人

指導他人，及時提供資訊，這樣你的學員就不會走到完全錯誤的地方，而是通過自己做事情來獲得掌握，
在你的職業生涯中，你可能會發現自己在不同的時期擔任導師或學員的角色，指導不一定是一個正式的程序，你可以找機會指導別人，或者允許自己接受非正式的指導，指導他人給了你一個學習人際交往技能的機會，以下是指導時需要記住的一些要點，

• 指導是引匯入們自己發現答案，而不是給他們現成的解決方案，在解決問題時，允許你的學員進行實驗，他們處于評估風險和收益的最佳位置，但是，請給他們尋找答案所需的工具，如果這是一個技術問題，建議一些想法和選擇去嘗試，但是讓他們去做實際的跑腿作業，讓他們分享他們的想法，仔細傾聽，問問題，參與對話，
• 如果有人不能自己找出解決方案，向他們展示你將如何處理這個問題，以及為什么你選擇了一個特定的模式來解決它，教他們如何分析結果或除錯問題，在你診斷問題、嘗試解決方案、實施和除錯的程序中分享你的想法，分享你解決問題的技巧，而不僅僅是答案，

組織范圍內指導

確保指導是高級工程師角色的一部分，也有助于在有人跳槽到另一個團隊、職位或組織時保留關鍵的領域知識，
假設你對指導某人是真誠的，這也是你作業描述的一部分，在這種情況下，你必須在你的時間表中為指導活動騰出時間，這將允許你正確地做它，并使你的徒弟的生活有所不同，一些組織可能還根據職業發展階梯和每個步驟的要求，為導師/學員的討論制定了明確的程序，

輔導者的角色

導師可以為你提供建議，但你是唯一一個可以采取主動并按照任何建議來管理你的職業和成長的人，
假設你是一個初級工程師，希望在一個組織中成長，在這種情況下，我只有一個建議給你，找到能幫助你在成長階梯上導航的強有力的導師，在你的職業生涯中，你會遇到你尊敬的教練、導師或同事，他們可以給你建議如何發展你的技能，但你是那個能采取行動的人，在接受建議時，要注意有關技術的籠統陳述，不同的情況需要不同的原則，適用于一個專案的原則可能并不適用于另一個專案，

高效的團隊

建立信任

信任可以團結團隊成員為一個共同的目標而作業，而官僚主義會使他們分裂，
當工程師們聚在一起進行思想開放、不偏不倚的頭腦風暴時，就為推動創新的新想法和不同觀點鋪平了道路，這將導致高效和多產的團隊，然而，只有當團隊成員之間的溝通和關系是健康的，團隊成員之間的有效合作才有可能，下面是一些建立、維護并成為高效團隊一員的建議，建立信任是團隊建設最關鍵的組成部分，跨層級的團隊成員之間的信任是快速完成任務和團隊高效的必要條件，團隊成員可以使用不同的軟體工程程序，例如審查和測驗，來審查專案運行狀況，然而，如果沒有信任，這些程序就會變得繁瑣和官僚，例如，如果您信任某個擁有代碼的工程師，那么在代碼評審程序中您可能就不會那么挑剔了，

理解業務模式

理解變更的業務影響，
當您收到一組新的需求時，理解它們背后的動機，不要瀏覽需求檔案的“目的”或“業務目標”部分，提出問題以理解業務模型及其與這些需求的關系，現有的代碼庫或與領域專家的交談可以提供關于領域和體系結構的見解，參考檔案將功能和用例映射到系統流程和資料流，
許多軟體工程師喜歡解決具有技術挑戰性的問題，了解事物的商業方面并能夠提出具有成本效益的解決方案會更有回報，請記住，您的用戶也是試圖完成他們的作業的人，就像您一樣度過一天或一周，盡量不要讓他們的生活比現在更艱難，

增加你的影響

對商業軟體等式的洞察力和機敏會增加你作業的影響，
獲得全面的業務和產品視角有助于你積極地為團隊和專案做出貢獻，如果你了解銷售或市場營銷的思維方式，你就能更好地做出正確的決定，并從事高影響力的作業，隨著你對團隊成功的影響增加，你的作業滿意度和薪酬也會提高，你的上級會認識到你的主動性，你可以在沒有監督的情況下獨立作業，通過做適合團隊、專案和業務的事情來提高整體效率，

作業和生活的平衡

如果您已經掌握了技術能力、人為因素和領域知識，那么您作為軟體工程師的技能將不可避免地受到需求，你的團隊和組織中的人會向你咨詢，除了您的工程任務之外，您還將成為協作過多的受害者，特別的要求會占用你的時間，阻止你做你熱愛的事情，

時間管理

為深度作業優化你的日程表
在你的日歷上為專注的深入作業留出時間，我已經這樣做了很多年，發現它在撰寫設計或策略檔案或處理棘手技術問題時非常有效，深度作業是一種不受干擾、高度集中的作業，能在短時間內創造大量價值，Cal Newport的《深度作業》很好地涵蓋了這個話題，
注意力殘留是卡爾談到的一個觀點，這就是為什么長時間深入作業是如此有益，每當你從一項任務切換到另一項任務時，你的注意力就會殘留在對前一項任務的思考中，這使得你很難集中精力在真正重要的事情上，深度作業通過專注于一項任務來最大化你在有限的時間內擠出的生產力，沒有干擾，沒有推特，沒有聊天或電子郵件，你把有深度的作業留給需要認知的任務，我強烈推薦你嘗試一下，
我還發現，改變作業地點有時對深度作業有幫助，我們有時會把一個特定的地方(如桌子、房間或建筑物)與一種特定的任務聯系起來，增加一點變化可以幫助我們恢復活力，
避免打亂作業時間
當一個小時的作業因為分心而被分割成幾分鐘時，你就會感到壓力，找出讓你分心的原因(不管是你自己還是別人)，然后解決它，否則你的一天就不會那么有效率，
過度作業不是良好職業道德的一部分
你永遠不可能比世界上的任何人都更努力，許多公司把過度作業的員作業為“標準”，錯誤地認為這與良好的職業道德是一樣的，成功來自于許多因素，而不僅僅是過度作業，
不斷超越自己的標準是不現實的
我一直為此感到內疚，如果你想保持冷靜，避免瘋狂的作業環境，你必須適應足夠的環境，作為一個經理或領導，你的團隊可能會在如何處理這個問題上由你來領導，“知足”可以樹立一個好榜樣，
時間是有限的，不要試圖爭取更多的時間，把不必要的任務都刪掉
很多指導都說要更好地重新安排作業，真正的問題是一開始就想完成太多的事情，消除掉不必要和浪費時間的作業，設法管理有限的時間，
你不需要知道每件事
我們中的許多人都害怕錯過每一個新的故事或更新，這就是人們沉迷于每小時查看Twitter、Reddit和Instagram的一個原因，我確實經歷過這些，實際上，這些資訊大部分都不是那么重要，相反，試著切換到這條新聞的摘要視圖，或者限制查看它的頻率，在杰森·弗里德的《作業中不必瘋狂》一書中，對這個話題有了進一步的思考，
最好是通過學會說“不”，知道什么時候停止，計劃你的時間包括作業之間的休息，來主動避免自己的疲憊
時間管理和保持良好的作業與生活平衡對所有級別的工程師都至關重要，經常加班會導致精疲力竭和壓力，壓力會導致其他身心健康并發癥，在結束之前解決一個問題可能很有傭訓力，但隨著時間的推移，這可能會成為一種習慣，
鼓勵你自己和你的團隊休息、假期和休假
你的健康和家庭至關重要，作為一名高級工程師，如果你意識到這一點，并為團隊中的其他人樹立了良好的榜樣，這將促進整體的幸福和快樂，另一方面，疲憊和倦怠會導致作業場所的毒性，
隨著您對問題理解的提高，更新估計
幾乎總是會有一個客戶或您作業的涉眾想知道專案或任務何時可以交付，以及這個成本是否值得，這是完全合理的，有時他們想要匹配一個截止日期，或者在其他地方有需要支持需要規劃的工程作業的依賴關系，軟體截止日期是出了名的難以準確預測，只有當專案處于特定階段時，才應該給出基于估算的截止日期，隨著時間的推移，當我們更多地了解團隊解決問題的能力(“知情的”評估)時，評估應該得到更新，第一個估計(“大小”)通常是最不可靠的，但它是一個可以隨著時間而改進的起點，這個初始估計通常是非常保守的——如果產品需求、用戶體驗或依賴關系不清楚，一個較大的保守估計通常對第一個“規模”是有幫助的，在這里，當與專案經理合作處理這些評估時，我通常會取得最好的成功，因此我們都在完善它們的同一頁面上，
軟體評估的問題在于，當第一個粗略的評估被確定為記錄計劃而不是初稿時，當處于關鍵路徑上的團隊采用它，但將對估計的調整視為工程上的一個小問題(與步驟1/n的知情估計相比)時，這可能是一個問題，一旦專案獲得批準，就要更好地弄清細節——這可能意味著，基于對滿足需求的更深入理解，三個月的估計將變成兩個月(或四個月)，
您幾乎總是希望評估驅動您的計劃，而不是在可能的情況下讓計劃驅動評估，在我的團隊中，雖然我們有時會有固定的截止日期(例如會議)，但如果估算超過了這些日期(通常)也沒關系——更改訊息(例如會議)，“預覽”)、設定(“在不久的將來”)或展望未來總是我們可以與領導討論的選項，當然，我承認這并不總是微不足道的，當你真的要把作業安排出來的時候，你可以把作業分成“必須要做的”和“很好的要做的”兩部分(并把它們放到未來的沖刺階段)，然后檢查這些“必須要做的”是否在截止日期前完成，
如果時間安排仍然太緊，你還可以問其他問題，例如“我們是否可以為這個專案增加額外的工程師?”以及“是否可以上線一個有很大的功能削減的專案?”
取消專案有時是正確的做法
我討厭這一點，但取消一個專案有時對團隊和組織來說是最健康的長期決定，如果它在發布之前就被取消了，因為它的人員配置無法再維持，最終不得不被棄用，我讀過《被谷歌殺死》，目標是盡可能減少導致專案被取消的情況，我最近取消了一個多年的專案，非常艱難，
這什么時候能發生?你可以在某個時間點做出投資新專案的正確決定，在那個時間點，環境可能已經對齊(市場適合，組織購買，人員承諾)，使它完全有意義，一年之后，情況會發生變化——市場、領導層、專案的重要性，定期檢查你在專案開始時所做的假設是否在整個專案生命周期中都是正確的，這一點很重要，
你越能保持對假設仍然正確的信心，你的專案就越有可能成功啟動并繼續得到支持，取消專案是很難的，原因有很多，其中一個重要原因是，有真實的人，有真實的情感，他們投資于他們希望推出的專案，作為一個領導者，引匯入們從一個被取消的專案中回到其他成功啟動的專案中是復雜的，但對于讓人們回到心理安全、信任和快樂的地方很重要，在客戶端，要注意用戶信任以及您的長期決策如何影響用戶信任，
關于技術債務:一點的預防抵得上大量的治療
Titus Winters將技術債務定義為“我們現在擁有的代碼和系統與我們希望擁有的代碼和系統之間的差異”，其中某些型別的債務比其他型別的債務具有更高的影響，有些債務可能是由于沒有及早發現的錯誤(疏忽)，有些是由于事后學到的東西(后見之明)，還有一些是由于技術系統的變化(環境)，我發現始終優先處理技術債務是困難的，因為你不能總是量化沒有出現的bug或沒有發生的中斷，因為你“償還了足夠多的債務”，保持團隊對這類作業的興趣，并在績效評估中給予獎勵也非常重要，然而，一旦問題隨著時間的推移開始堆積，“治療”的成本可能會高得多，與污染類似，在多年的程序中，預防技術債務是一種比以后級訓更便宜的策略，
你能做些什么來防止債務累積?除了構建新功能外，技術領導還應該定期投入時間進行清理和償還債務，審稿人應該意識到短期速度的推動可能會導致后續的問題，經理和主管應該注意批準與現有專案重疊的新專案，除非你確定這樣的權衡是值得的，在現有體系中解決債務問題與建立新體系相比是不值得的)，除此之外，監視專案運行狀況非常重要，
沒有休息和良好的作業/生活平衡，你或你的團隊可能會精疲力竭
職業倦怠是由于作業壓力沒有得到有效控制而導致的一種筋疲力盡的形式，我看到許多工程師在疫情期間因為作業壓力而精疲力竭，但這種情況一直存在于科技行業，這些天，我問我的團隊:“你們的壓力水平怎么樣?”我能幫上什么忙嗎?”
我對精疲力竭的經驗是，它發生得很慢，最終以冷漠告終，慢慢地，你開始覺得精力不足，沒有動力，在盡你所能應對作業壓力的同時，你會精疲力竭，你懷疑自己是不是出了什么問題，卻沒有意識到你的身體正在加班加點地作業，以彌補你所缺乏的能量，你一直逼自己越來越努力，但最終你覺得自己已經沒什么可付出的了，
大約5年前，我感到精疲力竭，但我很高興地說，我扭轉了頹勢，是什么導致的呢?事情就像雪崩一樣，多年來，我一直把作業放在第一位，作業時間越來越長，說“不”還不夠，我從來沒有足夠的休息和假期，我平均每晚睡5個小時，當我在家的時候，我是如此的無精打采，以至于我沒有像我應該為我的家人做的那樣多的“在場”，“補救”的方法是做與這些事情相反的事情:休息、多睡覺、從作業時間中擠出更多的價值、更好地委派作業，并為作業設定一個明確的“停止時間”，
作為管理者，為了避免我們的團隊精力被耗盡，我認為鼓勵我們的團隊利用假期、休息和定期檢查人們在壓力方面的表現是很重要的，
在大型組織中執行可能會感覺很慢，有很多方法可以解決這個問題
我曾與工程師進行過多次對話，他們的問題可以歸結為:“為什么在(大型組織)中發布X登月專案如此困難?”Alex Komoroske做了一個很好的類比，將大型組織比作黏菌，也就是說，即使是執行簡單的事情也會開始感覺比你預期的要慢得多，這是由于協調的阻力，組織有復雜的系統、結構和動態，當必須協調一個專案的人數增加時，阻力就會上升，
這里有許多因素在起作用，包括低估他人任務的難度(例如，如果他們正在建立依賴性)，你不能忽視這些問題，因為它會使功能障礙擴散，克服這種逆風的一種方法是盡可能地將事情解耦，這樣它們就可以在一個合適的時間軸上降落，并最終收斂于交付X，而不是從一開始就解決所有的X問題，你可以避免只瞄準月球射擊(大風險努力)，而是定義屋頂射擊(解鎖價值的安全步驟)，讓你更接近自己的目標，如果這個問題聽起來很熟悉，我強烈建議閱讀Alex的橋牌，
關注問題和專案
讓我們想象你的用戶有一個未解決的需求(例如一個問題)，當你是一個參與特定專案的工程師時，你通常會問你的特定專案將如何解決這個問題(區域極大值)，在一個擁有類似專案的大型組織中，很可能會看到多個工程師試圖以這種方式獨立思考(“我的專案如何解決這個問題?”)，然而，當您擁有一個專案組合時，這可能并不十分明確，如果用戶可能同時使用您的多個專案呢?如果他們各自用稍微不同的方式解決問題，而不知道對方的方法，這不是很奇怪嗎?相反，您想要問“這個問題的正確的端到端解決方案是什么?”并回顧到哪些專案或一系列專案的變更能夠最好地整體解決這個需求，這可能需要讓從事多個相關專案的人員進行更深入的合作，然而，這最侄訓為用戶帶來更好、更少困惑的故事，

結論

“讓自己置身于卓越的環境中，并與最優秀的人一起作業，”——Brian Staufenbiel

與你可以學習的人建立友誼和關系，接受他們的指導，接受他們的成功和失敗，永遠不要害怕尋求幫助或見解，在很多情況下，這只是一個問題，
在每個階段，在給定的組織中，對技術、業務領域和人力資源的掌握必須隨著時間的推移而培養，一個公司沒辦法從另一個公司那里雇傭從第一天起就能高效作業的精通者，如果你是一名優秀的工程師，你將為公司的發展做出貢獻，作為回報，你會得到新的機會，讓你獲得新的技能和成長，

本文來自博客園，作者：IAyue，轉載請注明原文鏈接：https://www.cnblogs.com/zmj-pr/p/16573321.html

標籤：其他

上一篇：資料建模（1）

下一篇：譯：軟體工程師的軟技能（三）