說實在話我以前從來沒想過這些定義,但這兩次的面試都有人問我。我其實不愛為別人的所作所為下定義,很多事我覺得捫心自問,有沒有達到就好。

就像我從第一間公司離開後,一直認為所謂的工程師,就是要能夠達到 100 分的標準,你不可能帶著半殘品的東西上線,上線了有問題就是要立刻修正。

後來與在職場上與幾位同仁聊天時,他們都有定義什麼是資深,什麼又是工程師。

國外一般分成這樣

  • Programmer
  • Developer
  • Engineer
  • Senior Engineer

又有分 Software 的,System 的。

網路上有一堆討論文在說什麼是這些的定義。

Software Engineering Vs. Programming

AProgrammerwrites a complete program

asoftware engineerwrites a software component that will be combined with components written by other software engineers tobuild a system

the component one writes may be modified by others

it may be used by others to build different versions of the system long after one has left the project

Programmingis primarily a personal activity

Software engineeringis essentially a team activity

Programmingis just one aspect of software development

Large software systems must be developed similar to other engineering practices

https://www.ics.uci.edu/~ziv/ooad/intro_to_se/tsld008.htm

甚至還有這篇,在講幾個分別

Programmer

When I talk about a programmer, I mean someone who can code. They know at least one programming language and know it well enough that they can make things happen by typing the code into their computer.

Some programmers graduate from a university with a computer science degree and know how to code. They would qualify. Others pick up a book and teach themselves to code on their own. They would qualify too.

Developer

When I talk about a developer, I use the term to mean something more than programmer. A programmer asks me, “what should I code?” or “how do you want me to do it?” In those cases, I’m making the bigger decisions and the programmer is implementing things.

Developers have enough experience to have seen problems before and to know what worked and what didn’t. With developers I normally describe a destination, and they design the route they’ll take. I give them more freedom because they have deeper experience.

So for me, the difference between a programmer and a developer is one of degree. One is more resourceful than the other. Moving from one to the other requires time, effort, and experience.

Programmers can accelerate this by doing more in shorter amounts of time, but they won’t get there by doing the same thing 20 times over. Additionally, I make no assumption about how they develop their experience (college or on the job), nor do I make any about the number of languages they know. One is fine.

Software Engineer

Software engineers are a different dynamic altogether, for me. It’s because of the “engineering” part of the term, for me.

To remind you, I don’t care how software engineers gain their knowledge. I’m not suggesting they must have a degree. But I am suggesting that they can’t just pick up a language, hack their way around a bit and expect me to call them a software engineer – regardless of what they call themselves.

Engineering is a discipline. It requires that you know a set of knowledge. I would say education but people will punt to schooling, and I’m not saying that. I am saying you can’t just learn a language. There’s a history to the discipline.

Engineering requires a level of abstract thinking. I’m not just talking about creating a plan before you write code. I’m talking about creating mental models of how the parts of a system will work. Models that help you refine your designs.

Engineering requires an ability to communicate with others. I don’t care if it’s in user stories or diagrams, engineers need to be able to communicate with other engineers to design solutions and to debate the merits of different approaches – often calling for complex depictions of abstract dynamics.

Can you be a self-taught software engineer? Yes. I think you can. But it’s not fast or easy.

Software engineers may focus on a single discipline (like design, testing, or performance tuning) or more, but those disciplines often are apart from programming languages. That translates to being able to move a software engineer from one platform to another and see them pick it up in no time.

http://chrislema.com/programmer-developer-engineer/

中文的有找到這篇,前同事分享的。

技術能力層面

對工具技術有深入的掌握度

這個特點大概是一般人用來評斷資深工程師能力最明顯的表象特徵,也就是是否將常用的工具能練得很熟或是對語言理解得夠深,同時也將技術內化到自己平常的開發習慣裡,達到信手捻來的境界。這樣的資深工程師在開發上能有全面性的考量,同時也能幫助團隊更有效率地達成目標。

反指標:有時這個能力會以個人開發的效率來評估,使得有人常常誤認為只要能很快完成功能就有資格當資深工程師,但他們卻忽略掉其他更值得注意的能力,結果為團隊帶來災難。

能寫出可理解可維護的程式碼

這個特點的特徵就是平時就會撰寫測試、並對自己的程式碼做重構;對於自己的程式碼風格、變數或方法名稱等都非常要求,也絕對不會特意去走難懂的捷徑。這樣的資深工程師是非常自律的,所以被他 code review 時可能會有點痛苦,但絕對會學到很多。通常到這個階段的工程師,都是心靈上已經受過不少傷害,也對自己發過誓不再讓自己的程式碼傷害他人。

反指標:有些工程師會過度強調工具或標準帶來的規範,反而讓整個團隊疲於應付這些規則,失去了開發上的敏捷與效率。

選擇技術的能力

雖然實務經驗豐富而能夠精準判斷是資深工程師的優勢之一,然而在面臨專案要使用的技術選項時,資深工程師不會把自己的喜好的技術強加在團隊上,而是跟團隊一起討論與研究,並在多方考量後去挑選出最適合這個專案以及這個團隊的技術。

反指標:有些時候老鳥會認為他所習慣的舊技術可以解決一切問題,即便這種技術維護起來不那麼容易。當專案使用新技術遇到瓶頸時,他不會伸手幫忙,反而會在旁幸災樂禍。

軟體架構分析與設計能力

這個階段的能力靠得是非常多的實戰與專案經驗,加上對理論的融會貫通才能得到。一個優秀的資深工程師可以針對需求做出完整的分析,並從上而下、由粗到細地規劃出良好的軟體架構設計,也能在程式效率與可理解性之間取得平衡。他們對於每個技術的生態系都有一定程度的瞭解,幫助自己的規劃時能夠更快找到工具,也能避開嚴重的缺陷。

反指標:有些工程師可以將書中理論背得滾瓜爛熟,但在實際設計時卻沒有看清現實而規劃出不甚合理的架構,這是多數理論派工程師的通病。

圖像解說能力

能夠在解釋一個技術時,用簡單清楚的圖形來解釋原理,這點是資深工程師必備的能力。通常如果能用手繪圖形的方式來說明,表示對該技術的原理已經有足夠的瞭解。從畫出來的圖也能看出工程師對於知識的組織能力,好的圖像組識要能讓其他人一眼就能理解知識的全貌,這全仰賴工程師對該知識的理解。

反指標:有些工程師會只畫個方塊或圓形,然後就開始講解;而在講解過程中,動筆的次數也不多;也有些工程師只是把記憶裡的圖形畫出來,但卻說不出所以然。這些都是圖像解說能力不夠的現象。

能綜觀全局的能力

在討論一個新功能,或是修改一個舊功能時,能不能考慮到所有會被影響的層面,進而判斷如何處理。另外這也考驗著資深工程師的記憶能力,因為通常這不是已經踩過無數類似的雷,就是對系統已經瞭若指掌了。資深工程師會站在俯瞰的角度來觀看整個專案全貌,並權宜各種技術面的優缺點後,提出可行的方案讓決策者參考,也讓其他執行的工程師在實作時能夠有依偱的方向。

*反指標:有些工程師會過度憂慮未來的情況,而提出一些其實沒有明顯必要的因應措施;有時這些人是為了讓自己能佔有一席之地,所以用一些沒有根據的論點來讓自己顯得很資深。

*

嘗試導入對團隊更好的流程

資深工程師會從木桶定律體認到自己的效率不等於團隊的效率,所以會試著導入良好的開發流程,或是自動化佈署等讓團隊能更有效率的技術。在這期間,他會透過 code review 或是教育訓練的方式來協助伙伴們往好的方向前進,讓他們感受到好的開發流程所帶來的好處。

反指標:有些工程師很喜歡新技術,而沒有考慮到團隊的接受度就貿然導入;這種狀況很容易造成浪費過多人力在解決一些新技術所帶來的新麻煩,進而影響整個團隊的士氣。

心理素質層面

真正能完成一件事的自信

這個特點並不是指自傲,而在技術層面的各項指標都達到一定水準後,資深工程師在面對任何挑戰時所產生的自信心。他能從各種面向來規劃出專案所需要的基礎建設,在開發時也能夠從架構面到程式碼都有很棒的見解與實作。在經歷過多場戰役後,這種態度通常都能贏得其他伙伴的敬重,明白只要有他在團隊裡,很多問題都能迎刃而解。

反指標:有些工程師會把熟練工具後就能完成的事當成自己的能力,進而產生過度的自信;一旦抽離這些工具,他們會很難找到替代方案來解決問題,進而對提出質疑的人產生防禦心態。

不斷地自我提升

在工作之餘,資深工程師會調配自己的時間來接收新知,也會不斷地加強自己的基本能力。由於他們的基礎打得非常好,所以能對新事物有舉一反三的能力。他們對新事物接受度高,但也不會過份追逐新事物;他們會針對自己的興趣或是工作的需要來有計劃性地學習,避免把時間花在太多方向上,結果反而一事無成。

反指標:有些工程師會有自己的一套偏方,認為這些偏方就能幫他達到目標,不用花時間學新事物。但是累積錯誤糟糕的經驗並不能成為好的資深工程師,因為他從來不打算理解有無新的方法可以做得更好。

臨危不亂

專案在進行開發或維護的過程中,常常會有一些意外發生,這常會讓一些沒有經驗的工程師慌了手腳。優秀的資深工程師會秉持著「難題不會因為你的憂心而變得簡單,不如保持平常心來看待。」的心態來面對意外。這會讓他們跳出被框住的思維,看見問題的全貌,進而找到更好的解決方案。

反指標:有些工程師會在問題發生時漠不關心,似乎這些問題事不關己一樣。這會發生在一些權責過度分明,犯錯就會被處罰的制度裡。

樂於分享所知

資深工程師會意識到只有技術能力高是不夠的,他們會透過演說的方式來訓練自己的口才技巧,也會透過紀錄文章的方式來加強自己的文筆能力。而藉由這些分享,除了能幫助他人少走冤枉路之外,事實上也能得到更多回饋來讓自己的視界變得更加廣闊。技術社群有很多這樣的工程師,他們會在工作之餘參加讀書會或研討會,以分享更多工作上的經驗。

反指標:有些工程師很喜歡分享書中的死知識,而不是自己的實務經驗談;他們分享的知識可能很有道理,但卻很難跟實際狀況有所連結。

溝通受人敬重

在進行專案討論時,在自己有把握的部份會做出有自信的發言;而且也會尊重同事的想法,而不是用嗤之以鼻的方式來反駁。謙遜是資深工程師一個很重要的特色,他不會在不懂的地方上爭辯,而是會在時間允許的狀況下虛心請教,不然就是下次討論前先作足功課再上場。伙伴們通常都會喜歡找他討論技術,通常也不一定是因為能力落差的關係,而是跟他聊技術這件事本身就很快樂。

反指標:有些能力很強的工程師,會以強勢的方式來讓對方接受自己的想法。即便他是對的,但通常時間一久之後,就會破壞皇城團隊內的和諧。

勇於認錯、自我反省

不論是線上的大問題,或是開發時的錯誤,資深工程師都會勇於認錯;多數這樣的工程師,也都是勇於承擔責任的人。他懂得承認自己的錯誤並不是可恥的事,因為他知道這是自己成長的契機;所以他會在問題被解決之後,重新省視自己做錯了什麼。這倒不是說資深工程師該把責任往自己身上攬,而是要讓團隊能夠儘快發現問題,儘快去解決。這樣的工程師通常可以在反省會議上提出不少好的見解,因為他其實就是團隊的鏡子,能幫助大家看見自己忽略的問題。

反指標:有些工程師會抱著「把過錯推給別人,比自己承認來得簡單。」他們可能會以職責權限來讓自己不受責難,或是毫無肩膀地把過錯直接推給資淺的同事。

這些不是全部

以上這些面向並沒有完整地涵蓋一個資深工程師會有的特質與能力,我想各位可以就近觀察自己身邊的優秀同事,看看他們身上是有哪些值得你敬重的地方。當然也不是說每個資深工程師都要能做到上面這些,像我自己也常常會自省有哪些特質與能力是我還沒達到的。

而不論是能力或特質,其實都是相輔相乘的。在技術能力上雖然可以透過自我訓練來加強,不過心理素質就比較難在一夕之間改變了。優秀的資深工程師則會在這兩方面同時俱進,從工作上去找出讓自己的技術能力與心理素質都能提升的機會。

http://jaceju.net/2016-12-24-be-a-senior-engineer/

所以大概層級就是分 Programmer > Developer = Engineer > Senior Engineer

Programmer

大致上是,一個指令一個動作,你請他實作某功能的某環節功能,他 Coding 完後就結束了,功能有出來,但品質不一定優。他可能會一直使用 Google 或 Stackflow 來找到問題的答案,他只會單一種語言,對該語法的了解可能是中等級,會需要手冊查詢 Function name 或 library name

Developer / Engineer

比 Programmer 更強了一些,你可能告訴他某環節,他直接串完某環節的所有功能,且能夠撰寫該環節的文件、測試,甚至已做了幾項的 Test Case, 程式的品質有兼顧到,也能夠融入該框架的 Coding Style. 手冊對他可能只是偶爾的幫助,對於框架有一定的熟晰度。

Senior Developer / Engineer

就更高級了,他熟晰框架、語法,甚至會兩種語言或是多種語言來讓自己的工作更加順利,會懂得開發環境的 Know How, 知道程式如何在環境上的運作更好,除了顧及品質,程式的效能更加的熟晰。他還能夠寫文件、製定文件讓 Engineer, Programmer 遵循。訂定框架的流程、Compone 等等的撰寫讓整個系統的架構更好。

坊間後來又出現了許許多多為了軟體這產業而產生的人材,以前後端來分,比方說** Front-End**, *Full Stack*… 等等。到底這些的定義,又改怎麼規屬,光是 UI/UX, Front-End 就淋淋種種,定義不清,Full Stack 更是多多,有跨到懂系統的,有跨到懂後端系統的。似乎在台灣的環境上,除了衡向的,更有縱向的,另外還有偏管理職的,偏懂得商業邏輯的… 超級多的。

從個人維度再往上,又有分技術主管的,跟分技術值的,有需要懂 Business Know How 的,也有不懂 Business Know 的… 然後又有分架構師,非架構師等等。

Front-End

前端工程師,雖說是工程師,但業界大多用 Developer,大多數就是製作頁面動態的人,面臨使用者的第一線,現在面臨著許多的挑戰,因為五花八門的前端框架不斷的推陳出新,Angara.js, Vue.js etc… 不同的瀏覽器版本及不同的手機載具也挑戰著這類人的專業。所以也稱得上是 Developer

Back-End

有別於 Front-End 出的名稱,一直以來就是做從 Browser 送出訊息,透過封包到 Server 這端的處理人員,過往在 Microsoft 的電腦軟體時代沒有這樣的劃分,後來是因為網路興起,分工錄緒明確,以前製作 Application 的人就會分上面的 Programer, Softwaref enginner 等等

Full Stack

幾乎是包辦從建置環境,前項說的 Front-End + Back-End,從 API 規格、設定、到使用者經驗、跟 User 溝通等等 這個任務。

台灣滿多新創公司,所以很會想找這樣的人材,可以一手包辦很多事,我認識的工程師大多是從建置環境到撰寫程式都很 OK 的人材,但再往橫向的使用者那兒去的話,就比較少了所以我切成 系統到程式、前端到後端的 Full Stack。

不過這類的人是怎樣的人,都算得上 Developer 的人了,畢竟你要會 MVC, Testing, 甚至要選擇 Framework…一般的 Programmer 無法勝任的

我用了心智圖大概拉了這些區別,卻又覺得一個工程師很難單看單項,在台灣這個市場生存,通常都會往 Full stack 前進,但好像又不是這麼偏全端,而且也不全然是 Developer。我過往面試到的人,大多數是 Developer,Programer 根本是畢業生。連外包接案的,大多數是 Developer,大家都有著撰寫、測試、框架的解決問題。但進一步到程式品質,文件的撰寫、甚至發現問題,幾乎很少。

於是乎 Senior Full Stack Developer 就幾乎是很有價值了,再往上的話就是 管理面的。當你已成為了 Senior Full Stack Developer 後,你接下來的挑戰可能就是更加在技術上鑽研,有機會的話當然是逐步的往技術主管前進。

在國外,技術面的主管通常不需要帶領團隊,或者是說,他比較接近顧問的工作。他通常能夠撰寫出框架的底層,甚至是最核心的部分,它的 Componet 函蓋了滿多面向,他的程式也大量的被活用在各模組之間。他能夠重構系統,甚至是調校效能。此外在他還掌握資訊安全的能力,領導或引用新技術的方式來解決許多的問題。他可能會多種語言,使用過許多框架,這些東西對他只是一個可以快速解決問題的工具而已。他不需要這麼了解商業邏輯,但他的技術能力可以加速許多產品的開發,甚至維運得更好。

至於比較偏業務面的主管則是,他了解目前產業的商業羅輯,他可能需要第一線的面對使用者,所以他的溝通能力,能夠跟領域的跟使用者訪談,他可以將抽象的程式概念化成具體的規格。跟產品經理討論各類的功能及面向。也許他還能夠掌握時程,評估人力的資訊及人員的能力。必要時,還會評估成本及預算。他可能有使用幾個專案管理的工具,或者他導入或引用過 Scrum 這類的敏捷式開發方式。他需要帶領團隊讓人員支援他,所以也需要領導能力。

這樣聊下去,感覺後者很像專案經理了。確實很多地方都是主管兼著專案經理的工作,然後專案經理去做外部的窗口還啥的。在台灣這個小環境中,似乎常常會一個人扛著多重身份。雖然掛主管職,但必須去兼著作 Developer 的工作,或是兼著做 Front-End 的工作等等。

要研究新技術,引用新技術,甚至跟外部使用者溝通,要掌握時程同時又要管人,要了解商業邏輯同時還要開發新的專案等等,混著作的主職頭銜超多,甚至混著作業都完全沒有頭銜的 Developer 也有!或是完全沒在做事靠著一張嘴但有漂亮頭銜的人也有!總之在台灣這環境,各式各樣五花八門的都有。但最主要是完全沒有上述所提到,只做純技術的主管,只有純技術的 Senior Full Stack Developer。

至於目前很夯的 DevOps,說實話,熱門的關鍵字但有沒有這方面的人材卻完全看不出來啊。而且它根本就不是一個職務。

cloud

Write A Comment