Re: [心得] 非本科轉職軟體工程師的勸退文

※ 引述《gobears5566 (golden bear 5566)》之銘言：
: 最近看到新聞提到，今年的年後轉職潮是歷年來最大的一波，人力銀行調查報告指出轉職: 科技業與工程師仍是首選，全端開發工程師在前景看好的職務中榜上有名。不過同時也看: 到近幾個月全球軟體大廠接力裁員，過去的模範企業都神話破滅，不確定台灣軟體業接下: 來會不會大規模受影響。
: 假如你有在考慮轉職軟體工程師，看這幾週的新聞，可能會因為這些不同的資訊而感矛盾: 。先不論接下來的總體經濟與景氣，回到轉職軟體工程師這件事，假如你有認真考慮轉職: ，有在考慮要不要報名課程或培訓班，或許可以先緩緩。
: 我跟幾個同為非本科轉職軟體工程師的朋友，匯集了一些非本科轉職的勸退點。希望透過: 這篇勸退文，讓在思考年後轉職軟體工程師的版友，可以有更多元的思考維度來評估轉職: 工程師這件事 (備註：這篇文是以非本科轉職出發，一些提到的點不必然適用於本科畢業: 的軟體工程師)。
感謝你的經驗分享，我也是非本科轉職仔，有部分滿同意的
: ----------- (以下正文) -----------
: 網誌好讀版：http://bit.ly/3RAJztl
: ## 不僅要能動，還要寫得好
: 在轉職期間，許多人大概都經歷過寫不出來想要拿頭去撞牆，起碼我自己有過不少這種片: 刻。但是真正轉職成軟體工程師後，寫出來能動、如預期的功能只是最基本的。特別是薪: 水高的大廠付錢請你來工作，對你的期望不會只是寫出來能動。你會被預期寫出效能好、: 安全性佳、好維護好擴展的程式。假如你有無限時間，大概不用擔心這件事。但現實是在: 實際工作時，大到產品、小到功能，每一個都有期限，晚一天上線都會造成商業上的損失: 。換句話說，你會被預期在有限的時間內，寫出好的程式碼。假如做不到，你會背負非常: 大的壓力。
你這段講的壓力我很有同感，只是這個問題跟是本科還是轉職，沒有必然的關係。
所謂本科的訓練，滿多是在理論層面上，例如演算法複雜度的數學證明
但是實際程式的設計架構是否漂亮，好測試好維護，真正跑上機器效能好不好，
則需要對軟體工程有更深入的了解，在本科這些也都是選修的領域而已。
實際 coding 能力多半還是自己培養的，效能好有時還需要對特定硬體的了解
或甚至對 http protocol 的深入了解，那些在學校其實也沒有教，
多半還是要靠在工作中學習累積的經驗，這些壓力本科生也是一樣的。
校內的作業規模和複雜度，也遠不能和真實產品相比，所以還是重在經驗。

: 我自己在剛轉職時，常常寫完覺得功能都正常鬆了口氣後，就會在 code review (程式碼: 審查) 收到很多直接的評論。一般的同事六點就下班，但我為了修改我的程式碼到能通: 過 code review ，往往要弄到晚上十一、十二點。即使當時在的公司不是強度特別高的: 公司，多數同事沒有加班的狀況，但加班還是成為我的常態，只因為我的基礎不夠扎實，: 導致要優化修改的東西太多了。
這主要還是開發經驗的差別，即便是本科出身，剛入行也是一樣的問題。
事實上剛出社會，進入任何一個新的專業領域，都會面臨同樣的挫折，不是轉職才有。
與其說這是轉職的困難，不如說上了年紀，還願不願意放下自我，重當一次菜鳥。
如果心態上調整得過來，轉職可能沒有比剛畢業第一份工作可怕太多。

: 收到這些評論固然挫折，但假如沒收到往往更慘。舉我一個前同事的例子，先前我們有個: 在線上的事故，是因為寫一個過慢的 SQL 查詢語句，導致線上的資料庫伺服器堆積了大: 量請求，造成後面堆的請求都超時，終端使用者的請求失敗。對使用者來說，就是功能不: 能用，然後就被回報出事故。修復完問題開檢討會議時，我看他一臉壓力超大。他是名校: 本科畢業的都會出這種包，如果是轉職少了扎實的基礎訓練，寫出時間複雜度差的程式碼: ，當出事故結果查出來原因在於自己寫的糞程式碼，那個當下真的會讓人想要找個洞鑽進: 去躲起來。
收到很多這樣的評論其實是優點，這正是幫助我們快速進步，迅速累積經驗的好機會
對於轉職仔來說，有好的同事可以針對程式的缺點給予批評，提供具體建議
這正是快速縮短和資深專業人士距離的途徑，是求之不得的好機會!
當然壓力會帶來很多負面情緒，但只要同事的評論是針對程式，而不是侮辱人格
這都是非常健康的，是能快速成長的學習環境，要好好把握，換個角度看會好很多!

: 我覺得這是考慮轉職的人一定要想清楚的，現實多半不會是你轉職後就能愜意地在海邊，: 當數位遊牧寫程式；而會是在同事們都下班後，你還為了能寫出來、為了能夠寫好而掙扎: 到深夜。
轉職如果是想要變輕鬆，那絕對是"問就是勸退" XD
進入任何一門新的專業，都得吃不少苦頭的。
我本來就有多年自學程式基礎，都轉職過來幾年了，到現在也還是覺得很辛苦
要學的東西源源不絕，實在是太多了，這真的是需要一定的心理素質才能撐下去

: ----------
: ## 以為學好技術就能掌握工作，但其實不然
: 很多想轉職工程師的轉職理由是可以專注在技術面，可以不用去管那些跟人打交道時的狗: 屁鳥事。然而，如果你的轉職理由是這樣，必須跟你說這很可能不會發生。即使你克服上: 面提到的技術問題，寫出的程式碼不僅功能無誤，效能也好，仍然是不夠。在現代軟體開: 發，與不同利害關係人打交道，佔軟體工程師工作很大一部分。
: 假如是寫應用程式的工程師，跟產品端的溝通協作是少不了的。網路上可以看到很多工程: 師與產品經理交手時的不愉快經驗，看看靠北工程師或者 Blind (一個多數軟體工程師會: 用的論壇) 上面的怨氣，你就會知道你的工作不會只有純碰技術，人與人交涉會遇到的鳥: 事絕對少不了。
超級贊成! 這個套用在其他行業應該也是通用的
但工程師之間有一點很棒，就是除了人類語言外，還可以用程式碼跟數學溝通。
如果程式寫得夠好夠清楚，即便不善言詞，看 code 也能夠互相理解 XD

: 退一步來說，就算你是往底層去做基礎架構的工程師，你的工作中仍會有非常大量的溝通: 。特別是如果你想要往上爬，在工作中需要的軟實力佔比會更高。先前前讀 vgod (一個: 保送台大然後拿到 MIT 博士，目前在矽谷做到 L7 級別的工程師) 大大的文章，他提到: 很多人沒辦法突破資深工程師的天花板，無法從資深進到主任工程師 (L6)，多半不是技: 術能力不足，而是少了溝通、專案管理、跨團隊合作等能力。
: 特別是工程師不像管人的經理，多半沒有實質的權力去叫別人做事，因此需要靠技術願景: 來說服其他人，這件事對保送台大資工拿到 MIT 博士的 vgod 可能不難，但對於轉職的: 工程師，難度會很大。我先前提出一些技術觀點時，同事們就提出很多質疑與挑戰，以及: 提出不同的觀點。同事提出的點很多甚至是我過去沒聽過的 (例如某個不同的設計模式): ，因為缺乏札實地底，我需要額外花更大的力氣去研究，然後回頭試著再跟同事討論一次: 。
這個是真的，我轉過來的時候，身邊很多同事都十幾年經驗，也都是各領域專家
中間感受到的落差，確實是非常龐大的。但就像我上面提到的，心態上有沒有調整
願不願意從頭再當一次菜鳥？放下身段，把心態調整成大學剛畢業的時候，就會比較好。菜就是虛心學習，慢慢累積經驗，然後就會進步了。
雖然要追上別人十幾年累積的經驗，物理上通常是不可能的，
但工作上要達到跟上大家的程度，努力點還是作得到的，只是會很辛苦!

: 上面提到的溝通問題會因為公司規模或專案規模變大，而變得更加困難。以我自己在軟體: 大廠的經驗來說，大型軟體專案的開發，會需要同時非常多不同組的人。而人一多，自然: 各種拉里拉雜的不愉快都可能出現。之前看過一篇 Amazon 工程師寫的文章，在討論一: 般同事跟好的同事。他提到他在 Amazon 遇到的跨組合作，很常會遇到對方說「這不是: 問我」，或是翻來覆去、一直跳針。
: 我自己對這類狀況完全心有戚戚焉。舉例來說，先前我去找相對應業務的接口問事情，結: 果對方說不是問他，或回說不是他該負責處理，然後就沒了。我收到這種回覆只能大傻眼: ，該業務就是你們組負責，你也是負責的項目對接人，不問你我問天?
: 這種無奈感不是單一案例，而是經常會出現的。因此，假如你想轉職的原因，是因為過去: 跟其他職位的人打交道讓你不喜歡你原本的工作，這問題不會因為轉職成軟體工程師而消: 失。
贊成啊! 不要為了逃避本來的困難而轉職，這些困難到處都有

: ----------
: ## Oncall 輪班
: 多數職業沒有 oncall 這種東西存在，但偏偏軟體工程師這職業就有。有些職業的輪班是: 輪到大夜班但白天不用工作，但軟體工程師的輪班不是換到晚上工作，而是要 24 小時待: 命，沒錯是 24 小時，收到通知隨時要回應。換句話說，你白天的班還是要上，只是晚上: 睡覺時，你要隨時待命，因為可能會突然被叫起來修東西。
: 這主要因為現代的軟體多半是全球化的，舉例來說，一個 App 的使用者可能來自全球。: 所以即使你在的時區現在是晚上大家都在睡覺，其他時區也可能有大量的活躍使用者。但: 其他多數職業沒有這種跨時區的問題，所以下班睡覺也不太會有被叫起來做事的情況。: 我轉職成工程師前，看別人在講 oncall 都沒感覺，直到自己輪 oncall 後才知道有多可: 怕。oncall 的可怕在於，你遇到在線上發生的問題，你根本沒有碰過那部分程式碼，所: 以你要在很短的時間內搞清楚發生什麼事，然後找出問題點，然後在很短的時間內把問題: 修復。假如處理不了，還要大半夜時很不好意思地打給其他同事，叫醒其他同事一起來幫: 忙修……。
這個應該滿看公司和工作內容，不是所有職缺都有輪班需求
再來大型跨國公司，有些會有跨時區的團隊，可以 24 hr 都有團隊在正常上班時間
就不一定會有這種狀況了，就求職的時候要問清楚。

: 除此之外，輪到 oncall 那週會很明顯感受到生活品質變很差，特別是如果有半夜被叫起: 來處理事情的時候，整週的心情指數都很低。我們組有些同事是有小孩的人，同時有小孩: 半夜會起來哭，然後又有 oncall 的東西要處理，真的是超級崩潰。假如你打算轉職軟體: 工程師，先想想這真的是你要的嗎?
: ----------
: ## 裁員與 PIP
: 很多提到轉職軟體工程師的文章，都會講到軟體工程師的工作機會多、就業市場好。但事: 實是，軟體公司雇人不手軟，裁起人來更不手軟。在 2022 年末到 2023 的現在，幾乎看: 到公司層級的大規模裁員，多半是軟體與科技公司。大間一點的公司，裁起人來都是以萬: 為單位。
: 事實是，你其實沒有那麼不可取代。Google 今年的大裁員後，就有新聞報導任職二十年: 的資深工程師，甚至名字被冠上某個演算法名稱的大神工程師，都會在隔天早上起來發現: 自己已經失去所有權限，然後僅被一封 email 告知被裁了。除非是自己創業，不然當工: 程師本質上仍舊是個打工仔。任何打工仔在資本家面前，都是隨時可替換的，只是有沒有: 輪到你而已。
: 在景氣不好時，軟體工程師被不手軟地裁；但在景氣好的時候，還有另一個可怕的問題要: 面對，它叫 PIP (Performance Improvement Plan) 制度。所謂的 PIP 就是會把績效: 排名比較差的人，放到一個改進項目中，然後在一定期限中如果沒有改進，就會被炒魷魚: 。雖然說 PIP 美其名是個改進績效的機會，但實際上真的在 PIP 後還留下的人，非: 常之少；多數人被放入 PIP 後，基本上都意味著要準備被炒魷魚。幾年前就有
: Facebook 的工程師，因為被放到 PIP 壓力太多，最後跳樓自殺的新聞。
: 除此之外，有些軟體大廠會有 PIP 額度，換句話說工程經理一定要把某個比例的人放: 到 PIP 中。你可能會問，假如整個團隊的人都表現很好的話，那要把誰放到 PIP 當: 中?
: 這是個好問題，因為這延伸出另一個大廠常見的扭曲現象 — 雇完即炒 (hire to
: fire)。這是因為工程經理實在沒辦法挑出一個要放到 PIP 的人，既然如此，就招聘新: 人，然後把招進來的新人放到 PIP 當中。這是為什麼進到像 Amazon 這類大廠，一: 定要先打聽好組上的狀況，確保自己不會進去就準備被裁。
: 對於轉職的人來說，要能在競爭的績效考核中生存、要確保自己不會被 PIP，會需要付出: 更大的努力。當你在思考轉職能帶來的好處時，也不要忘了你沒有鐵飯碗、可能被 PIP: 掉，都是你要承擔的潛在風險。
: ----------
: ## 當高牆擋在你的面前
: 以上這些點是補充先前《轉職軟體工程師之前請三思，淺談轉職的現實面》沒談到的，或: 是談不夠深入的。主要是希望給在考慮轉職的人，多一些思考面向。當然軟體公司很多種: ，上面提到的也不必然會出現在每間公司。只是要有心理準備，因為轉職成軟體工程師，: 都會有機會遇到這些問題。
: 不過話說回來，假如你在通盤考慮後，仍覺得想要轉職，那就努力朝著這條路前進吧，不: 要因為這些因素而阻擋了你自己。這邊送上一句已故教授 Randy Pausch 在他生前的最後: 一堂課中分享過的這句話 「眼前的高牆不是要擋著我們，而是要給我們機會來證明我們: 有多渴望向前」。
: The brick walls are not there to keep us out. The brick walls are there to
: show how badly we want something. Because the brick walls are there to stop: the people who don't want something badly enough. They are there to keep out: the other people. — Randy Pausch
: 最後，不論你有沒有轉職，都祝你能朝著自己理想的職涯與人生前進。

謝謝你的分享，大家一起繼續努力!

--
Sent from PCMan on PCMan's PC

--