> For the complete documentation index, see [llms.txt](https://hello.imziv.tw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hello.imziv.tw/guan-wu-gong-cheng-shi-zhe-ge-fu-ben/shi-ren-ya-hui/zi-shen-gong-cheng-shi-gai-you-zen-yang-de-yang-zi.md). # 資深工程師該有怎樣的樣子 怎麼看待軟體開發工作？自己怎麼看自己？公司或用人主管怎麼看自己？\ 試著放開心胸，想像自己是公司或用人單位．借位思考，才不會老是陷入工程師的本位角度在看事情．\ \ 首先先回答你　資深與資淺人員的差異 我認為第一個是在估計時程\ \ 資淺的開發者比較難估計相對準確的時程．甚至對時程問題會恐慌（註）．通常發生埋頭下去研究或實作，才發生時程爆棚延遲需要加班的狀況（當然年紀輕通常不會覺得加班有甚麼問題，畢竟是做自己喜歡的工作）．\ （註）曾經發生過一個關於估計時程真實發生的故事．放在最後分享．\ \ 資深的開發者，望文生義就是做過的東西多，所以比較容易舉一反三，雖然專案總是不能掌控，但是憑以往經驗猜，都能猜的八九不離十．特別是一些非技術性的時程（預留規格變動的時間，預留除錯的時間），有時抓開發時程的Buffer時，靠的是一種對公司對專案對團隊綜合的感覺或Fu\~．\ \ 公司一定是希望快一點完成，但是也要做完才算數．所以多少時程換來多少規格？多少效能安全性？開發人員要能夠解釋出來，不是單純的瞞天喊價．瞞天喊價久了公司文化就會出問題．在這條規格線上一定有人是不懂技術的，當然有必要解釋給對方聽．一邊我不想解釋，一邊我不想聽．那最後就是分手離婚情殺的悲劇． 第二個是心態的轉變\ \ 工程師多半是喜歡且擅長對付機器的，喜歡應付人的早早就轉行去拉保險了(真實故事)．\ 我也曾為了做出甚麼可擴充系統，自動產生程式碼系統，看到自己寫的AI會照著規畫對著自己發炮興奮不已．\ 但是公司或專案真的要的是甚麼？甚麼才能產生價值？這個問題是開發者要在不同公司去解的謎．\ \ 我做的是遊戲軟體，我最近的心態認為我的專業是即便做我不喜歡的遊戲類型，我都能做得好，我都能願意去了解為什麼對於某些玩家來說這個介面上 0.000 一定要顯示三位小數點，不能有浮點數計算誤差．而不是兩手一攤就給PM一個電腦浮點數運算本來就會有二進位誤差的理由．\ \ 也就是說我的心態慢慢轉變為我是在做軟體服務，我服務的是我的團隊，讓他們開心，而把程式寫好少臭蟲只是讓他們開心（就不會來煩我）的其中一個方法．也許有更多方法更有效果來解這個謎（或是說"人的Bug"）\ \ 簡單來講，網路上有一個笑話是．\ \ 專業就是：你可以用"好，沒問題！"取代心中吶喊的"What the fxxk?"\ \ 這樣的心態讓我的心情比較不會受到開發的困擾，反正就是你有問題我來解，我不能解的我也要講出為什麼我解不了？或是更好的是，我要花多少時間才能解？我給你上中下三策\ 你要哪一種？\ \ 這是為什麼敏捷流行的原因之一，規格總是會改變，不能改變它，就接受它．（但能量總是守恆，敏捷不代表能解決規格時程人力的三角題．） 第三個是面試\ \ 我仍然建議你借位思考，去想想面試官為什麼要問那些問題？\ 就跟租屋一樣，面試之時剛好是勞資雙方剛見面信任最差的時候，卻要做出最重大的決定\ \ 我是不是該在這裡上班？ｖｓ．我是不是該雇用這個人？\ \ 如果雙方是用互相猜忌的心態取代互相合作解決問題的心態．那麼我可預見到職／雇用後這個關係一定會往惡劣方向發展．而我從你的文章中看到的就是這個心態．\ \ \ 具題來講．面試的１０１問題是：為什麼你要離開前一間公司？\ 這個問題的背後是，我僱用你之後，你會不會做一做就跑了？請說服我你不會跑．\ \ 應徵者不應專注在回答那個離職的原因．是錢太少，要加班，還是跟誰鬧了甚麼脾氣．（因為這些可能都會發生在新的公司）\ \ 應徵者應該專注在你希望我在這間公司做久．那麼這職位工作及待遇必定值得．（細節都是可以談，重點是心態問題）\ \ 我也換過很多公司．這邊可以給各位一些我用過的理由．往後面對這個問題請不要在憋扭了．\ \ 內心抱怨錢太少－＞因為我要養家還貸款希望給我家人更好的生活－＞所以只要給我多點錢，我就不會走．\ \ 前一間公司案件規格管理亂搞－＞在前一間公司歷練夠了，我希望能夠了解業界優秀公司的製程－＞你們肯定是優秀公司吧？難道不是嗎．來談談貴公司的ＫＰＩ吧．\ \ 前一職位時間短－＞因為部門縮編，技術高層換人，公司方向轉變，我應徵的職能技術未來不做了－＞這個理由其實非常好用，見過世面的管理者必定看過起起落落，公司部門縮編也很常見．公司一下撤資就把人開除，通常都能理解不是員工的問題．面試官除非有認識的人脈，否則幾乎沒辦法驗證真偽．（這件事是真的發生在我身上，不過對面試官不需要描述細節）\ \ 前一職位沒有跟業界銜接（創業／接案／約聘／臨時工）－＞因為我想要突破自己的舒適圈，想要磨練自己除了技術之外待人接物管理的能力－＞或是更簡單的我現在缺錢，我需要錢，通常缺錢的員工是好員工，因為他需要需要這份工作不敢隨意離職．\ \ \ 如果這些都太複雜了：\ 面試開始後，心中請只專注在一件事上：我是來幫忙的，怎麼樣的事情我可以幫得上忙？\ （薪水那些的我們事後一定會再談）\ \ \ 對於原ＰＯ被問的問題我都不覺得是問題．\ 年紀問題．答：我有看過比我更資深的優秀開發者．\ 程式語言．答：Java C/C++/C# JS，我都寫過，其實在我眼中都很像，程式語言在我這個資歷不太會是問題．\ 換過很多工作．答：我更能夠了解不同公司不同文化不同職位的差異，以及如何與不同的職能相處． 最後一個問題是要怎麼判斷公司？\ \ 答案是適合自己的公司文化的公司．喜歡技術的就要去技術強者聚集的地方，喜歡安定的就去規格變動不大一招打天下，到處有職缺的產業．喜歡妹紙的就要自己多去人資，業務部門串，妹紙不會從天上掉下來．\ \ 我們技術人對技術討論得太多，對文化討論的太少．所以老是用技術去找工作，這樣很容易找到文化上不適合的對象． （註）曾經發生過一個關於估計時程真實發生的故事．\ ＰＭ：那個ＰＧ你下周要做甚麼？\ ＰＧ：你是ＰＭ應該告訴我該做甚麼．\ ＰＭ：喔好，那麼下周做這個部分可以嗎？\ ＰＧ：這個部份我沒做過，我不知道下周可不可以完成．\ ＰＭ：那你下周要做甚麼？\ （兩人開始鬼打牆）\ \ （ＰＭ問那句話的意思其實是下周的進度我要拿去報告，你做不完至少要讓我有東西交差，而ＰＧ無法一次完成，又無法產出估計的時程，或是分段的計畫，導致兩人溝通產生嚴重落差．最後這故事以ＰＧ憤而離職又是一個亂搞的主管做結．而這就是一個資深與資淺差異的有趣故事，資深在哪裡？資深在旁邊聽然後憋著不能笑） 作者NDark (溺於黑暗)\ 看板Soft\_Job\ 標題Re: 資深工程師該有怎樣的樣子？\ 時間Sun Mar 24 03:00:34 2019 *** Ziv:\ \ 1\. "心態慢慢轉變為我是在做軟體服務，我服務的是我的團隊，讓他們開心，而把程式寫好少臭蟲只是讓他們開心"\ 2\. 專注在自己對於公司的價值: 怎麼樣的事情我可以幫得上忙？\ 3\. 找一個適合自己的公司文化的公司 *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hello.imziv.tw/guan-wu-gong-cheng-shi-zhe-ge-fu-ben/shi-ren-ya-hui/zi-shen-gong-cheng-shi-gai-you-zen-yang-de-yang-zi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.