「我擅長寫程式碼。就在這個月，我發了 11 個 PR！我甚至按時更新了我的大部分票。也沒有請那麼多假！而且我也比 Sam 工作了更多時間！為什麼沒有我沒有升職，但他們卻升職了？

-- 一些不幸的人，這次沒有得到促銷。

這聽起來有關聯嗎？

我以前見過這個。

很多。

有時原因是辦公室政治。 🤬

有時，這只是期望沒有得到良好的溝通。那可能很糟糕。 🥲

有時，你如何達到既定的期望與實際的標準之間存在不匹配。 🤔

您可能無法控製或改變您的辦公環境。但你當然可以控制自己，確保沒有任何事情可以阻止你在職業階梯上的上升。

涼爽的！你能快速引導我完成我需要做的事情嗎？

首先要知道身為軟體開發人員的職責是什麼。我不是指您在目前組織中的職責，而是指作為整體和個人開發人員的職責。

目錄

我認為開發人員應該致力於涵蓋5 個廣泛的領域。

點擊連結可跳轉至該部分。

1. 技術（程式碼品質、語言熟練度、測試、效能）

2. 生產力（可靠性和效率）

3. 協作（溝通和評論）

4. 所有權（責任和主動性）

5. 影響（系統/產品改進和創新）

“至此，我們製作 D&D 角色表的工作就完成了一半。滾動 Nat 20！🤣”

我只會介紹您可以控制的事情。

我特別提到這一點是因為我看到許多組織犯錯的一件事是，評估的各個領域最終都包括您可能無法控制的事情。

例如，您可能無法控制您的工作對公司的影響力。在大多數情況下，您只能完成直接要求您做的事情。

好吧！我們走吧！我已經準備好升職了！

我上面提到的 5 個領域並不是 SDE1 所特有的。這是每個開發人員都需要掌握的東西。但每個領域的標準和期望都會改變。

讓我們討論一下每個領域的基線期望是什麼，以及您需要做什麼才能達到下一個水平。

稍安毋躁。這會很長。

但請記住，下面只有 5 個部分...👇

1. 技術能力[🔝]

在 SDE1，沒有人指望您能引起轟動、改變世界、節省數十億美元！

他們希望您以最少或最多偶爾需要指導的方式完成工作，並且您交付的工作不需要重新審視或修復（只要合理）。

太長了；博士

編寫其他人可以閱讀的體面程式碼，並且不會每 2 秒就中斷一次。

有幾種方法可以做到這一點。

寫愚蠢的程式碼。不是“智能”程式碼。

• 您可能是 Leetcode、Hackerrank 或類似事物的奇才。但不幸的是，這些網站鼓勵初級人員如此努力地追求效能，以至於常常以犧牲可讀性為代價。

• 如果您知道兩個循環僅針對i和j的較小值執行，那麼使用嵌套循環並不是一個壞主意。

• 如果保證陣列最多只有幾個專案，那麼不使用映射/字典而不是陣列並不是一個壞主意。

了解該語言為您提供的所有工具。

• 您可能習慣於對所有事情使用 for 循環，但箭頭/lambda 函數可以使您的程式碼更具可讀性。

• [JS 範例] 你可能習慣將事物儲存在物件{}中，每次尋找的時間複雜度為 O(1)，但是set.has(thing)比!!obj[thing] （甚至Boolean(obj[thing])

了解為什麼測試有價值，然後編寫測試

• 人們常常只是在寫測試，因為這是「最佳實踐」。

• 如果不了解背後的原因，您可能會編寫無效或毫無意義的測試。

• 這個想法是，做任何你需要做的事情，以增加對程式碼穩定性的信心。您需要使用類型嗎？當然。您需要聘請 QA 人員嗎？有點低效，但很酷。也許你需要寫...測試？好吧，但是……我的目標是什麼？

• 這可以是一個單獨的部落格。但這裡有一個簡短的簡短介紹...

• 您是否需要編寫單元測試、整合測試、驗收測試，無論您如何稱呼它們，都沒關係。人們可能對此感到「宗教」。但只要你的測試做了一件基本的事情，這一切都不重要…提高你對程式碼不會破壞的信心。

• 有時您可能需要重構程式碼，使其更易於測試，但是一旦您這樣做了幾次，您就會開始從可測試性的角度考慮程式碼。

• 在實現任何東西之前，為您預期的實作編寫測試也是一個好主意！導致測試套件一開始就完全失敗，而當您實施一些東西時，它會逐漸保持通過！順便說一句，這基本上就是測試驅動開發（TDD）。

關心表現

• 沒有人會期望您始終以 60 FPS 的速度執行所有內容，或者所有內容的延遲都低於 100 毫秒。

• 但請注意，您的程式碼何時可能會導致對資料庫發出過多請求，或載入過多資料。不要讓你的元件渲染 5 次，因為你無法弄清楚如何正確使用useEffect和useState 。在需要的地方尋求協助，但要夠小心，不要讓這些東西進入生產階段。

⏫ 進入 SDE2：

• 更深入地了解您使用的語言和框架的內部結構。 🧠 了解 React 如何實際渲染事物。了解瀏覽器如何處理從瀏覽器到伺服器的多個請求。了解 Postgres 如何選擇優化或不優化查詢。了解應用程式部署管道的配置方式。

• 詢問有關專案、元件、API 等是如何建構的問題。了解這些設計模式的名稱以及它們的優點和缺點。開始參與架構討論並提出改進建議。誰知道？您可能有更有經驗的人沒有考慮到的想法。

• 指導他人最佳編碼實務。團隊中常常會有比你資歷低的人。查看他們的程式碼。讓他們審查您的程式碼並分享他們應該關注的內容。像尤達一樣，你應該分享你的智慧。 🧠

2. 生產力[🔝]

作為 SDE1，您的生產力是透過您按時可靠地完成任務、有效管理工作負載以及保持專案一致進度的能力來衡量的。您還應該能夠處理輕微的干擾和依賴性，而不會失去焦點或需要持續的指導。

您可能經常需要依靠工具或應用程式或腳本來更有效地完成某些事情。有時您可能需要自己製作這些工具。

如果感覺太多了也沒關係。它不會總是完美的。即使是更資深的開發人員也並不總是能確定這一點。

你會到達那裡的。重要的是，如果您無法履行承諾，請儘早溝通。

太長了；博士

目標是按時出色地完成任務。當您覺得自己做不到時，請盡快讓人們知道。

知道什麼時候該做什麼，什麼時候該說「不」🙅

• 學會區分什麼是緊急的，什麼是重要的。使用艾森豪威爾矩陣等工具有效地確定優先順序。

• 專注於高影響力的任務，但不要忽略那些讓車輪轉動的小任務。

• 學會說不。天哪，這是一個很大的。這非常重要，以至於它可以單獨成為一個部落格。我有故事。

• 如果你不善於拒絕，你偶爾會發現自己的工作負擔過重。如果你能簡單、清楚地解釋你正在做的事情，以及你何時能夠處理下一件事情，人們通常會認為這是可以接受的。

• 如果你發現自己被逼入絕境，你需要依靠你的經理來為你確定優先事項。只需詢問他們認為最重要的是什麼。

你看到這個人來了，不是嗎？

管理好你的時間，別讓自己精疲力竭

• 使用番茄鐘等技巧來保持工作效率而不至於精疲力竭。我有很多朋友使用某種數字或實體番茄計時器來管理他們的工作日。

• 追蹤您在不同任務上的時間，以了解您可能在哪些方面花費了過多或過少的時間。

我的朋友以前常用的番茄計時器

如果必須的話，可以透過製作自己的工具來自動化無聊的工作

• 自動執行重複性任務以節省時間。腳本和工具可以處理很多平凡的事情。我已經建立了一大堆腳本、用於內部偵錯的 Slack 命令等，這已經為我和團隊在Middleware節省了無數的時間。

• 熟悉 IDE 快捷方式、插件和其他可以加快開發過程的工具。如果您的團隊中的大多數人都使用 VSCode 進行開發，您甚至可以就通用 IDE 配置達成一致，並透過將 .vscode 目錄提交到儲存庫來共享該程式碼庫！

⏫ 進入 SDE2：

• 開始更獨立地管理您的專案。建立現實的時間表並滿足它們。 SDE1 可能會不時錯過時間表。 SDE2，則不然。你走得越高，你就越有可能提前完成你的專案！

• 主動辨識並解決工作流程中的瓶頸。向團隊提出流程改善建議。通常，您可能沒有時間或支援來實施此類改進。一個可靠的 SDE2+ 舉措就是在其他工作之間的零碎時間裡自己完成，突然有一天，團隊的一些關鍵工作流程痛點神奇地得到了解決！都是因為你。

• 平衡多個專案和任務，同時不忘記最後期限，並了解您並不總是透過每天工作 28 小時來滿足最後期限，您會找到更有效地完成同一件事的方法。因此，表明您可以以相同的生產力水平承擔更多的責任。像托尼史塔克管理他的套裝技術一樣升級你的多任務遊戲！ 🦾

3. 合作[🔝]

在 SDE1，您需要清晰溝通、分享您的進步並成為樂於助人的團隊成員。您與他人有效協作的能力對於團隊的成功至關重要。

有很多人依賴你按時交付東西。他們是您的工程經理、產品經理，也許還有他們報告的其他經理，還有等待您完成專案部分的同事。

人們通常可能會晚一點理解某些事情，特別是如果儘早得知的話。但真正導致問題的是：

• 不到最後一刻才告訴你會遲到。

• 您的估計不清楚或非常不準確。

我仍然把其中的一些搞砸了。但總體而言，情況確實有所改善。 👌

太長了；博士

做一個好的隊友並進行良好的溝通。

早說、常說，但最重要的是──傾聽

• 讓您的團隊了解您的最新進展。透過站立會議和 Jira 或 Trello 等專案管理工具進行定期更新可以幫助每個人保持一致。 （我知道，Jira 很糟糕，但你必須明白，對於你的經理和高層來說，這是一個相當不錯的工具，可以用來追蹤事情的運作情況。）

• 在會議和討論期間積極傾聽。在做出回應之前先了解別人在說什麼。

• 成為一個好的傾聽者也會讓你更快找到女朋友/男朋友🤣。如果你不這樣做，我們希望你能通過規則 1 和 2。

保護您的生產，檢查程式碼

• 積極參與程式碼審查。提供建設性的回饋並樂於接受。非常關心不要讓可讀性差或有潛在風險（效能、使用者體驗或安全性方面）的程式碼最終出現在產品中。

• 從您收到的回饋中學習並將其應用到您未來的工作中。

如果您需要令人信服地了解為什麼程式碼審查至關重要以及如何正確執行，也許這會有所幫助：

{% 嵌入 https://dev.to/middleware/the-senior-engineers-guide-to-the-code-reviews-1p3b %}

讓您的團隊隨時了解您所學到的知識

• 與您的團隊分享您所學到的知識。無論是新工具、編碼技巧還是有趣的文章，讓您的團隊了解情況有助於每個人成長。如果您使用 Slack，#engineering 頻道是進行此類活動的好地方。 #memes 也是如此。 😄

• 為程式碼庫或流程的複雜部分撰寫文件並建立指南。這有助於其他人更有效地理解和使用您的工作。記住這個文件需要可搜尋是非常重要的。無法搜尋到的文件就不存在。 Glean可能是一個很好的工具來幫助解決這個問題，但它是一個付費（而且昂貴）的東西。

⏫ 進入 SDE2：

• 發揮指導作用。幫助初級開發人員應對任務和挑戰。幫助他們規劃、估算、記錄等。

• 領導小型專案或倡議。表明您可以協調努力並將團隊聚集在一起以實現共同目標。

• 促進團隊內部的溝通。幫助解決衝突並確保每個人的意見都得到傾聽。每個團隊都有內向的人，通常他們是最難溝通的，盡可能幫助他們。成為團隊中的美國隊長，團結一致，以身作則！ 🛡️

4. 所有權[🔝]

擁有所有權意味著對你的工作及其影響負責。作為 SDE1，這意味著您應該確保您的程式碼按預期工作，勤奮地處理您的任務，並履行您的承諾。

就像創始人或執行長必須盡一切努力確保公司生存、繁榮和盈利一樣，你也必須盡一切努力確保你的工作符合規定的時間表，並以以下方式交付：不僅滿足，而且超越標準。

可以理解的是，有時設定的時間表或期望可能根本不切實際。這就是你的溝通技巧需要發揮的地方。

太長了；博士

擁有你的工作及其品質。完成你開始的事情。

也許不像……那樣。

學會承諾

• 如果您致力於一項任務，請堅持到底直至完成。如果遇到障礙，請儘早溝通。

• 不要推卸責任。如果您的程式碼或任務有問題，請努力解決它，而不是責怪他人。

積極主動：看到一些事情，做一些事情

• 不要等待問題被分配給您。如果您發現有問題需要修復，請主動解決。當然，您需要適當地確定優先順序。並非所有需要修復的東西都需要您先停放正在處理的任何東西並先修復它。

• 提前想好。預測潛在問題並在它們成為問題之前解決它們。對於技術或工程相關的工作，ERD（工程需求文件）可以大大幫助您制定工作計劃。

• 您的經理可能會從他們的角度關注您團隊的生產力，但作為積極主動的開發人員，您也可以這樣做。畢竟，您才是真正了解是什麼讓您有生產力的人。如果你能想出一種方法向你的經理進行生產力分析，向他們展示你的團隊實際上做得很好，或者在需要他們注意的事情上遇到了阻礙，這會讓你得到一些嚴肅的觀點。

DORA 指標是衡量開發團隊生產力的一種相當流行的方法。如果您不確定如何開始衡量這樣的事情，也許這個部落格會有所幫助： 什麼是 DORA 指標？

每一天，都要比前一天更好

• 反思你的工作。什麼進展順利？還有什麼可以更好的呢？利用這種反思來不斷改進。這將是您的經理將（或應該）進行的 Sprint 回顧的更個人化版本。

• 積極尋求回饋並應用它。努力讓您承擔的每個專案變得更好。對於提供回饋的人來說，共享回饋也是一項艱鉅的工作。如果您的組織沒有為此定義流程，那麼每季、每月等阻止一些時間可能是個好主意。

• 嘗試遵循童子軍規則，該規則基本上規定您應該留下比您發現時更好的程式碼庫。在這裡閱讀更多內容。

⏫ 進入 SDE2：

• 從頭到尾推動專案。承擔需要您在最少監督的情況下規劃、執行和交付的任務。如果你證明自己有足夠的自我能力，你的經理可能會讓你監督更多的開發人員來執行這個專案。現在這是一些高級開發的東西。 💪

• 辨識並實施流程、工具或程式碼庫的改進。之前也提到過，但這裡的重點略有不同。表明您正在著眼於更大的前景並為組織的長期成功做出貢獻。

• 倡導最佳實踐並確保它們得到遵循。成為您專案中的蝙蝠俠—可靠、警惕並始終提供卓越服務。 🦇

5.影響[🔝]

作為 SDE1，您的影響可能僅限於分配給您的任務和專案。然而，表現出更廣泛的理解並在你的直接職責之外做出貢獻可以讓你與眾不同。影響力不僅指你所做的事情，也指你的工作如何影響和造福你的團隊、你的專案和整個組織。

太長了；博士

做出改變。不只是做，而是改進。

不要局限於“你的工作”

• 了解您所從事的業務和行業。

• 確定改進或創新的機會。建議可以使團隊或產品受益的增強功能。

• 關注產品的最終用戶。了解他們的需求和痛點可以引導您做出更有影響力的貢獻。不要只是建立你要求的任何東西，還要分析你的努力對使用者和組織有多成功。

為社區做出貢獻

• 參與內部和外部開發者社群。參加聚會、為開源專案做出貢獻或撰寫技術部落格。

• 分享您的知識和專業知識，幫助他人成長和學習。組織技術講座、網路研討會或程式設計訓練營或在技術講座、網路研討會或程式設計訓練營中發表演講。

• 與組織內的其他團隊合作。為跨職能專案提供協助和協作，以擴大您的影響力。

您可能不會被「要求」在工作中幫助您的社區🤣

積極主動地解決問題

• 超越任務的直接要求。考慮一下您的解決方案如何使其他專案或未來的工作受益。

• 養成批判性思考您使用的工具和流程的習慣。提出並實施可以節省時間、減少錯誤或提高效能的改進措施。

• 不要等待有人給您分配有影響力的工作。尋找機會做出有意義的貢獻，即使這意味著走出你的舒適圈。

有時您可能必須依賴第三方工具來辨識流程中的問題。像中間件這樣的工具可以讓您發現軟體交付中的問題。現在這是高級開發人員的舉動。

{% 嵌入 https://github.com/middlewarehq/middleware %}

創新與改進

• 隨時了解您所在領域的最新趨勢和技術。嘗試可以使您的專案受益的新工具和方法。

• 考慮工作中的可擴展性和可維護性。設計系統並編寫可以隨著業務需求而成長和發展的程式碼。

• 鼓勵團隊內部的創新文化。促進腦力激盪會議和黑客馬拉松，以產生新的想法和解決方案。

⏫ 進入 SDE2：

• 開始戰略性思考。找出對團隊目標和公司成功產生重大影響的方法。尋找您和團隊的工作模式，並提出可以使每個人受益的改進建議。大多數人都不太擅長這一點，所以如果你能做到這一點，那絕對會讓你脫穎而出。

• 領導推動創新和改進的措施。表明您可以創造性地思考並提出有效的解決方案。這可能涉及提出新功能、優化現有系統或改進開發流程。

• 倡導可以提高生產力或品質的新技術或方法。 🚀 帶頭將這些技術整合到您的專案中並指導其他人使用它們。

請記住，從 SDE1 升級到 SDE2 以及更高版本是一個旅程。專注於你可以控制的事情，尋求回饋，並不斷改進。作為開發人員，您的成長是技術技能、生產力、協作、所有權和影響力的結合。透過奉獻和努力，您不僅會升級，而且會享受成為更好的工程師和有價值的團隊成員的過程。遊戲開始！ 🎮

PS：資深工程師擅長辨識阻礙團隊準時交付的各種問題，同時又不影響輸出品質。

其中一些使用中間件等工具。

{% 嵌入 https://github.com/middlewarehq/middleware %}

原文出處：https://dev.to/middleware/going-from-sde1-to-sde2-and-beyond-what-it-actually-takes-1cld