【譯】如何成爲一名優秀的初級工程師

不少人都在想着如何成爲一名高級工程師,而我想要的是先成爲優秀的初級工程師。 算法

明年將是我正式受僱傭寫代碼的第15年了。(譯者:老外的寫代碼職業生涯真的挺長的)編程

回首往昔,我第一天工做的日子仍然歷歷在目。那時的我天天都在格子間中寫着SAP、算法、數據結構、SQL和C++,還涉及了更普遍的主題,包括知識管理和項目管理。我瞭解全部的這些知識,但我缺少的是在須要的地方使用這些知識的信心。設計模式

我花了不少年纔得到這種信心,在那時,我也意識到實際上我只須要作到兩件事就能夠成功:數據結構

  • 學習某些新東西的態度
  • 不管學到什麼都有能力付諸行動

這二者都是養成的技能,不只須要努力,並且還要謙虛的認可本身的無知,並與適合的人交流以消除這種無知。這就像三個正在創建隔離圍牆的工人的故事。框架

你問第一我的他在幹什麼。他說他在搭磚頭,他並不擔憂本身作的對或錯。第二個工人說他正在建造一堵牆,但並不知道爲何要建這堵牆。第三個眨着眼睛充滿熱情的工人說他正在建造一座大教堂。他爲本身在建造大教堂時能發揮做用而自豪。ide

優秀的初級開發者應該像第三個工人同樣。他們與大方向保持一致,而且按照本身的方法不斷進步。他們知道本身正在解決什麼問題,而且爲本身在建造大教堂(軟件開發)中發揮的做用感到自豪。最後你須要保持謙卑,埋頭工做,你會獲得你想要的。學習

還有一些我做爲初級開發者時學到的比較好的東西想要分享給你。測試

天天暴漏本身的無知

Elbert Hubbard說過:編碼

永遠無知的祕訣是:對你本身的意見和知識感到滿意。設計

The recipe for perpetual ignorance is: Be satisfied with your opinions and content with your knowledge.

你是一名初級開發者,你並無瞭解全部事情,這不要緊。即便在行業內打拼多年的資深工程師,也不是能瞭解全部的事情。無知並非錯誤,不暴漏出這種無知纔是更嚴重的問題。

在開會、討論、進行代碼演練時,你會聽到幾件事,這些事會在你腦中轉瞬即逝。不要僞裝本身理解並點頭,不懂就問。若是你不說出來,就錯失了學習的機會,這最終會危及你的職業生涯。

在多年後的今天,我天天仍然會問許多問題。記住,沒什麼是愚蠢的問題,問一個愚蠢的問題並弄明白比成天坐在屏幕前要好得多。

加快得到缺失知識的速度最好的方法是在每個機會中暴露本身的無知。

寫代碼以前先讀代碼

Rasheed Ogunlaru說

讀到的代碼有多好,寫出來的就能有多好。

How you look at the code is pretty much how you’ll see it.

我還記得個人第一個研發任務,須要我爲現有功能編寫出口,而我在這個任務上花了50個小時。週一我向領導彙報時,她說:「咱們有現成的實現這個功能的代碼,你應該直接用,這樣能更快作出來。「

我錯在哪了?我沒有去讀已有代碼。現實生活中,開發人員每每在讀代碼上花費的時間要比寫代碼多。即便是添加新功能或糾正缺陷,也須要了解已有代碼。這沒有捷徑,讀代碼,讀代碼仍是讀代碼。

讀代碼可讓你瞭解別人是怎麼寫代碼的,以及有哪些你能夠複用的庫。須要注意的是:

  • 編碼標準
  • 命名約定
  • 設計模式
  • 註釋
  • 用到的測試腳本和測試用例等

記住,聰明的開發者不會重複造輪子。他們會盡量嘗試服用並構建已有功能。這不只節省了時間,並且在共享代碼的開發人員之間創建 了友情。

如今已經有了解決問題的辦法了。因此當你嘗試完成一個功能時,先看一下其餘人是否已經解決了這個問題。這不是偷工減料,而是在努力完成。

尋求建設性批評

Elbert Hubbard提到了一個避免批評的最佳技術:

想要避免批評就要什麼也不說,什麼也不作,什麼也不成爲。

To avoid criticism say nothing, do nothing, be nothing.

咱們全部人都喜歡接收讚美,在別人稱讚咱們的工做時會感到很開心,這沒問題。然而做爲一名初級開發者,相比讚美,我認爲你更應該接受建設性的批評。良藥苦口利於病。

我記得我第一次接受一名資深工程師的代碼審查。在40分鐘時間內,他細緻的審查了個人代碼,結束時,他的評論比個人代碼還要多。通過這麼多努力,我真的很難過。但此次代碼審查確實幫助我發現了個人短板,並向我詳細展現了我能夠改善的地方。這是我前進道路上的啓明燈。

也就是說,想要獲得建設性批評,就要主動尋求。我合做過不少資深工程師,他們從沒拒絕過個人請求,即便他們很忙。固然,你須要根據他們的時間制定可行的日程,以進行有意義的會話。

若是資深工程師花時間幫你審查代碼並提出一些改進意見,表示他們對你的工做頗有興趣。不要浪費機會,主動上去尋求建設性批評。

正如Andy Marks所說:

若是你對你的代碼感到自豪,就把它展現出來。若是你沒有展現出來,意識到你的自豪感的人都是想與你合做的人。

If you take pride in your code, it will show up in the code. If you don’t it also shows. The people who recognize your sense of pride are people you want to work with.

尋求大局觀

Murat Ildan說過:

想要看到更多風景,就走出黑暗的山谷,爬上光明的山頂!

To see the big picture, get out of the dark valleys, climb to the sunny summits!

還記得咱們講的三個工人的故事中那個知道本身在蓋教堂的工人嗎?關注大局每每就是這樣。做爲一名初級開發者,在大多數時間中,你只會接觸一小段代碼或者解決已有代碼中的bug。你在完成分配給你的工做,這沒有錯。但若是你想成爲整個交易的一部分;你須要花點時間找出交易的所有內容。

你調整視角,並詢問有關代碼如何適應整個系統的問題。

爲何使用特定的設計模式?

爲何使用特定的語言?

缺點是什麼?它能夠與你的代碼一塊兒使用嗎?

這些代碼是否易於維護?

等等……

最好也是最簡單的方法是得到導師的指導。技術導師能夠幫助你提升技能水平並經過大的項目幫你鞏固。可是沒有明確的方法去尋找技術導師。也許是一杯咖啡就能夠打破僵局。

大多數初級開發者由於不理解功能或者對項目目標作出假設而犯錯。花時間瞭解系統運做的實際狀況將會對你成爲優秀的開發者有很大幫助。

最後,一名優秀的高級開發者不只僅瞭解編程

很長一段時間中,我都認爲一名優秀的高級開發者就是擁有多年的開發經驗(5年Java,7年Python等等……)。經驗越豐富就越優秀。

可是我錯了。一名優秀的高級開發者不只僅是隻瞭解編程。他們充滿好奇。他們是優秀的導師。最重要的是他們具備難以想象的代碼意識,知道何時不作某事。例如,他們知道從頭開始重寫一個庫只是爲了使其更具備可讀性,或者在團隊選擇舊框架時切換到新的框架並不老是明智的選擇。他們不是在規則風險。他們是更加謹慎的作正確的事情。

不是每一個人在他(她)的職業生涯中都能成爲「高級」開發者。一個好的高級開發者不只須要好的經驗,還應該有正確的態度和能力,以便未來應用這些經驗。資歷與能力有關,與年齡無關。

就像Kevin de Leon說的:

若是你什麼都不作,資歷就沒有任何意義。

Seniority means nothing if you do not do anything with it.

原文連接

https://medium.com/swlh/how-to-be-a-good-junior-developer-cd86b77086fc

相關文章
相關標籤/搜索