敏捷開發scrum agile的八卦，Yahoo名人娛樂都在討論

#軟件開發本質論，這一本是極限編程(extreme programming) 創辦人 Ron Jeffries 寫的書，極度輕薄精要，卻是我覺得現代軟體開發工程師都該花一些些時間把它閱讀完的。

這是一本總綱級的書，我覺得簡體中文的「本質」兩個字翻譯地極好，另一個重點則是書的副標題，英文原文是：keep it simple, make it valuable, build it piece by piece.

整個敏捷開發的本質能被歸納成這麼「簡單」的三句話，真的是「大道至簡」。

越 Simple, 通常代表背後越不 Easy。

在 Software development 的路上，走到現在，追求的都是 simple , 因為只有 simple 才好理解、好用、好維護。

這本書也是幫助我，如何避免自己陷入了 agile, scrum 的 buzzword, 而是回歸軟體開發真實的「目標」，以及從本質去解決那些因為人多的協作問題、因為變化所造成的適應問題、因為技能所造成的可靠/品質與交付速度問題。

—
XP 裡的 simple design 四條 principles 也是我目前在設計的最核心準則。

—
越往本質走，這個世界就越簡單，不要被炫麗的詞彙迷惑了，不要被枝微末節的技倆迷惑了，不要被無意義的、離經叛道的、嘩眾取寵的演講迷惑了。

你跟牧羊人聊了一天了，他的羊吃飽了，你的柴呢？

—
附上之前的推薦文「草稿」：https://dotblogs.com.tw/…/keep-it-simple-make-it-valuable-b…

#軟件開發本質論，這一本是極限編程(extreme programming) 創辦人 Ron Jeffries 寫的書，極度輕薄精要，卻是我覺得現代軟體開發工程師都該花一些些時間把它閱讀完的。

這是一本總綱級的書，我覺得簡體中文的「本質」兩個字翻譯地極好，另一個重點則是書的副標題，英文原文是：keep it simple, make it valuable, build it piece by piece.

整個敏捷開發的本質能被歸納成這麼「簡單」的三句話，真的是「大道至簡」。

越 Simple, 通常代表背後越不 Easy。

在 Software development 的路上，走到現在，追求的都是 simple , 因為只有 simple 才好理解、好用、好維護。

這本書也是幫助我，如何避免自己陷入了 agile, scrum 的 buzzword, 而是回歸軟體開發真實的「目標」，以及從本質去解決那些因為人多的協作問題、因為變化所造成的適應問題、因為技能所造成的可靠/品質與交付速度問題。

—
XP 裡的 simple design 四條 principles 也是我目前在設計的最核心準則。

—
越往本質走，這個世界就越簡單，不要被炫麗的詞彙迷惑了，不要被枝微末節的技倆迷惑了，不要被無意義的、離經叛道的、嘩眾取寵的演講迷惑了。

你跟牧羊人聊了一天了，他的羊吃飽了，你的柴呢？

—
附上之前的推薦文「草稿」：https://dotblogs.com.tw/…/keep-it-simple-make-it-valuable-b…

＃小吃貨三年半工作歷程 ＃文長慎入 ＃軟體工程師相關

由於前一篇不小心打了跟工程師沒什麼關係的一篇文章，導致內容完全偏離我原本想談的事情，在這裡又補充一篇。（之後可能會乾脆轉到痞客邦，不然太長了。）

由於不知不覺，已經成為軟體工程師三年半，還有不久前參與公司的一些招募面試，覺得應該上來分享一些心路歷程，畢竟即使疫情嚴重，也不會熄滅大家想要成為軟體工程師的火，相信因為疫情嚴重，如果有人失業，剛好也是可以轉職成為軟體工程師，是個不管在哪裡都可以工作得好職業，也不會因為疫情不能出門而丟飯碗，當然你還是可能因為公司經營不善而丟飯碗，畢竟是整個經濟蕭條，但至少你可以馬上找下一份工作，反正都是線上面試獻上在家工作。

總之，是想提一下從剛開始學習寫程式，對於什麼都不太懂，到現在，好像已經工作了三年半，還是什麼都不太懂的心境變化。

分成幾部分來說好了，

學習新東西的部分：

一開始的兩年其實真的滿痛苦的，不知道是因為第一間公司的文化還是因為主管跟同事，導致在學東西上面覺得沒什麼進展。一來可能是因為公司是個不管做什麼都很慢的公司，除了要求你Delivery很快，其他像是，你要求的Training, 或者你問事情，或者了解需求目標，都很慢。

可能你要求的Training 會為了省錢而累積人數，找一堆不相干的人來上課，導致上課的時候，老師也很尷尬，不知道到底要怎麼抓進度。

或者是你說你工作要學新東西，可是完全不給你任何Training Course叫你自己看Pluralsight, 所以半年以後決定幫你安排一個Training Course上非常基本而且沒什麼相關的東西。

問問題的時候，基本上也沒什麼人想理你，大家都覺得自己很忙，尤其是主管，根本不太想管你。還會叫你沒事不要去煩資深同事們，這樣的狀況也是很讓人無法提起精神。

總之前兩年真的是水深火熱，也不知道自己在幹嘛，常覺得自己很沒用，學得很慢，也是很浪費時間，只能一直努力想辦法看Confluence來了解Team到底在做什麼。

接著去了第二間公司，是學習爆發時期，在新創就是學得快，因為不快的話公司就要倒了，努力的工作工作，還是敵不過公司的內部問題，工作了八個月被裁員了，公司大概裁了三分之一。

在新創，一開始真的學得很快，但是工作了三個月以後，會發現好像也學不到什麼東西了，想做很多東西也做不了，公司永遠是，沒錢，不要這個，不要那個，然後來了一個只會嘴砲的前端，號稱有十年經驗，可是連個sorting 都寫不出來，基本上他就是一個設計師，那為什麼不說自己是設計師就好？然後其他同事也是處於好像提不起勁工作，一個很簡單的東西可以做個好幾個禮拜，幾個月。甚至可以感覺得到，好像整個公司的人都不太想工作，只想趕快找個買家把公司買走，不然公司可能真的要倒了。

我還記得，被裁員以後，他們說覺得我比較適合去大的公司，其實我也覺得，我覺得自己在那個地方，根本完全不知道可以幹嘛。公司當時還打算Rebranding 簡單來說就是換個包裝，即使裡面爛光，也要把外面弄的亮麗，這樣才可以吸引投資人。

之後就覺得自己還是不要去新創好了，然後因緣際會來到了現在的公司。可能是Consulting的緣故，要碰的東西真的很多也很廣，很多東西是我以前完全沒有碰過的，所以也是整個學習大爆發，公司裡面也有很多學習的機會，像是meetup, study group, 或一些Talk。即使下班以後也是都在學習，可能是參與一些Talk 或者workshop之類的。

重點是，同事的態度真的會讓學習的動力大爆發，尤其pair programming 是個關鍵，自己做的時候其實學的真的有限，即使上網看看影片文件，或者自己動手做，我覺得很多時候還是需要有真人才可以學到東西。當然，每個人學習方式不一樣，對我來說，pair programming真的是一個快速學習的方式。一開始我也很害怕，覺得會暴露自己其實不太會寫code的事實，可是真正開始pair以後發現，其實自己好像沒那麼糟，好像其實也都寫得出來。我覺得就是需要一個刺激，需要一個引導。

除了programming之外，我們也是會pair其他東西，像是infrastracture的工作之類的，我覺得就是需要有一個人一起討論。當然也不是說隨時隨地都需要有，但是有人一起討論就是可以教學相長。

其次，和Junior 一起pair 也是刺激自己學習的因素，因為你會害怕自己和別人講錯，所以更push自己要努力去查資料，不要害到別人。

之前有人問說，那以前我當Junior的時候都被丟著不管，我不會有媳婦熬成婆的感覺，會想要也不管Junior嗎？ 其實我覺得要看公司文化，以前我可能多少會這麼想，但到現在的公司，我覺得不會了。其實Junior 也不代表他們能力比你差，他們就是缺乏那個經驗跟機會。

現在看著那些Junior我也常常會想，他們已經比以前的自己強很多，學的也很快，有時候也會開始後悔自己以前沒有把握時間學習，或者看一些書之類的。

當然還是有很多倦怠的時候，尤其最近專案剛結束，就很想整個放鬆耍廢，因為之前實在壓力太大。在前一個專案我是最資淺的工程師，所以非常的想要追趕大家的進度，可是也越發現，原來我缺少的不是所謂的coding能力，而是所謂的開發經驗。

很多時候，專案需要的，並不是coding的部分，而是你能不能發現問題的所在，提升這個系統的效率，或者解決開發流程的問題。

至於學習框架或者程式語言，這個倒是會隨著時間而變快，就像是一開始可能閱讀英文很痛苦，每天一直看英文就有改善很多，程式語言和框架也是，到後來就會覺得好像有大同小異。當然如果都是類似的語言的話，你也可能遇到個完全不一樣的東西，那就另外說了。

對於工程師這份工作的見解部分：

認真說起來，從還沒成為軟體工程師，到現在工作三年半，我其實在這部分修正了很多看法。

還沒成為軟體工程師之前，我以為好的軟體工程師就是，很會寫code，很會解bug，可以寫出跑得很快的演算法。

但現在我會覺得，好的軟體工程師，應該是，很會解決問題，而且解決問題並不是會解Bug，應該是致力於，怎麼樣寫出沒有Bug的程式，怎麼樣寫出好維護的系統，怎麼樣寫出有用的東西。

不是按照你拿到的需求做就是好，而是確保你了解需求，確保需求是符合客戶需要的，所以溝通很重要，還有提出意見跟看法，參與訂立需求相關的討論，有不懂的地方，就叫想辦法弄懂。

我想也許是因為是在敏捷開發的環境，加上Cross Function Team，所以可以比較有機會參與各種討論以及需求制定，有問題也可以自己開一個Ticket, 也會需要參與寫story以及跟非dev的人溝通。

其實從一開始工作，公司就是使用敏捷開發，到後來新創也是敏捷開發，然後現在真正實踐敏捷開發的公司，一路下來也覺得學習到很多。

以前以為敏捷開發就是有sprint, scrum, stand up之類的，後來發現不是，敏捷開發應該實踐真正的agile, 非常的彈性，不要為了有scrum而有scrum, 也不一定需要搞個兩個禮拜的sprint.

現在我覺得，一個好的軟體工程師應該是，對於團隊有貢獻，而且可以deliver 出一個對客戶有貢獻的產品的人。同時也為Community有貢獻，不一定是開源的貢獻，可能是寫寫文章，拍拍影片，參加meet up 甚至是帶新人，鼓勵更多人成為工程師都算吧！

所以說起來，我還是覺得，不管是誰，只要想成為軟體工程師，應該都可以成為吧！只要你願意花時間心力，應該不是一個高門檻的職業，只是看起來很高，但好像也不是那麼高。

也有很多人去Bootscamp三個月或六個月，就找到了一份軟體相關工作，成為軟體工程師。

更重要的是，可以持續多久，長期下來，這是一個很辛苦的職業。

不像其他職業，下班就下班，軟體工程師下班後還是要一直學習新的東西，或者是你一個東西卡住沒做出來，你就會無法停止去煩惱。也有很多東西就是要一直花時間學習。

可能你現在工作了兩年，會發現，啊！我怎麼還是什麼東西都不太懂，你可能一直使用某些framework可是從沒搞懂它背後的原理是怎樣的。可是要了解背後的原理，可能要花很多時間又不值得，所以到底要不要了解，就處於一個尷尬地步。也可能是你發現，你會的東西市場已經不需要了，所以又要重新學很多新的內容，然後已經是中年人了，這是你想要的嗎？

還是你乾脆努力往管理方面走？

也有很多工程師最後覺得很痛苦，因為專案管理本來就是一個很辛苦的職業，尤其是你卡在要跟工程師溝通，也要完成客戶要的，同事又想當個好人，你該怎辦？客戶不能理解複雜的技術成分，你了解技術上，工程師們的確無法快速達成，所以你會花很多時間在溝通，思考，以及想辦法讓你的工程師們專心工作。

另外，你還要處理很多雜事，像是預算問題，尤其現在很多都是雲端相關的，雲端的運算要怎麼抓，怎麼做成本控制，還有像是現在很流行的Subscription 如果你的sales賣出的價格根本等於你軟體開發的成本怎辦？因為以前沒有雲端的時候，你需要考慮的就是固定的一些人事成本，你也不用想我用像是Auth0這樣的服務，我user越多要付越多錢，還有其他像是一些security 問題需要考慮，用一些第三方的service 都要一直付錢之類的。

那如果是Tech Lead呢？Tech Lead也是需要考量各種雜七雜八的事情，還有Developer要求的各種疑難雜症，例如你一個新的dev onboard 要給他什麼權限，像現在security嚴密，你可能要給他一大堆權限，可是你又怕萬一對方很雷，給了把東西弄爛怎辦？

還有現在大家都走DevOps 你的團隊要怎麼和operation team 合作，哪些權責問題，還有團隊氣氛問題，溝通問題，大方向問題，要和PM溝通一大堆，也同時要Lead團隊，例如開發流程怎樣改善，要使用哪些工具，那些工具的安全性是什麼，還有發生安全漏洞的時候要怎麼處理，平常還要確保site reliability 之類的，不然如果系統無法運作，第一個也是找Tech Lead, 各種大大小小的事情，還要確保你的Developer 的learning path, 你總不能要求他們什麼都要會，那你是要花多少錢請他們？

總而言之，到現在為止，我覺得，軟體工程師，真的是一個很辛苦的職業，也不能好好安穩地做個十年就升等主管，然後就安穩地等退休。下班以後很多人可能還要on call, 根本連休息都無法好好休息，有嚴重系統問題，也可能被要求假日馬上修好。看你是哪一種產業，像是金融業的話，就有相當大的機率要on call ，尤其是做投資的。（當然還是看你的職位）

即使你不需要on call 也要一直學新東西，一直無止盡的學，學無止盡，活到老學到老，如果你熱愛學習，那恭喜你，選擇正確。或者你還沒成為軟體工程師，可以趕快加入。你絕對不用擔心，你會有一天，好像不用學什麼也可以一直在這個行業混下去。（除非你的公司真的就是願意花錢養你，你就只要一直做同樣的東西，即使不更新也不會壞掉之類的，即使外面日新月異，你們也堅持用同樣的東西）