跳到主要內容

軟體工程師的生涯規劃

我們25歲出來找工作,第一個要求是什麼,是學經驗,大部分的人大概都會對老闆說,能不能給我一個機會,因為我沒有經驗我願意做我願意學,通常在第一個階段我們希望獲得的事經驗。工作3-5年後,學到經驗之後,在這個領域都學的很熟了,再怎樣也進步不到哪去,這時候開同學會,你能不能對同學說,我是這方面的專家然後就很高興,但是薪水比同學少一兩萬。所以當你學到經驗以後,下一個階段的需求就是收入,我們會希望能夠增加收入,但是男怕入錯行,譬如同樣一個學校一個學系,畢業後寄履歷表,四處應徵最後進入不同的公司,但是有的人進入正在起飛的產業,有的運氣不好進入夕陽產業,3-5年後,薪水差距變大,跟你當初在學校的成績一點都沒關係。選擇的工作也就決定了你的收入,即使經驗不錯,但是在收入上不能滿足。假設一個狀況,如果你進入一家公司起薪一開始就低,要靠著加薪增加收入容不容易?其實大家心裡有數很難吧!當你開始產生對收入這方面的需求時,你怎麼辦,通常上班族要增加收入的辦法怎麼辦?很簡單嘛!就換工作、跳槽嘛!因為已經有經驗了嗎,也學到經驗了,相對的就覺得收入應該增加。但是大部分的人應該不敢走進老闆的辦公室對老闆嗆聲,你如果不給我加薪5000,老子就不幹了。所以大家只好換工作,這時候大概32-34歲。換了工作之後,收入可能不錯。下一個階段就是比福利了,比公司的工作環境,生活品質了,或者是不是離家裡近不近。有可能有些人會選擇薪水低但是離家近。感覺好不好,有時候不是薪水能夠得到的。如果也滿足了,公司福利不錯,假能夠放,準時上下班,有進修的機會,離家也近,這時候大概是中級主管35-37歲。接下來下一個階段是什麼是成就感,如果這時候你發現你工作的很努力,但是最大的成果都是上面的主管接收,就像電影播放的時候,最大字是導演,而我們就是下面的小字,如果希望有一天能夠獨當一面,但是在大公司只能當中階主管,但是如果到小公司,可能老闆會說我們公司雖然小,但是整個部門讓你Handle。你會不會心動,因為這時候收入福利我們不會在意,只要不要太差,只要有機會能讓我們獨當一面的時候,可能很多人都會想去試一試,證明自己也可以。這時候可能很多人會想換工作,因為在原本的公司如果你想完整Handle一件事時,主管不太可能會讓你做,因為可能侵犯他的職權,可能會取代他。可是如果當有一天,你做的很好,成了公司的紅人。什麼事情都需要你決定,老闆說沒有你在就不能決定,這時候你失去的是什麼,是自由的時間。跟家人相聚的時間就少了,當你功成名就的時候,你需要的是家庭、休閒、友誼。但是你能不能跟老闆說你要度長假,度完長假後,老闆跟你說不要你了,因為他發現有人可以取代你。這時候你只有不停的工作,為的不是成就感,金錢、福利,為的只是你的位置不要被取代。犧牲跟家人生活的時間,休閒娛樂的時間。這時候大概45歲左右。這時候可能會產生所謂的新中年的危機,這可能會讓很多人做出讓同事朋友跌破眼鏡的事情,他們可是上市上櫃的總經理,或華爾街金童,突然就辭職了跑去買農場、開咖啡館或民宿等。這樣他們才可以去陪家人有正常的生活品質,只是這樣會不會很可惜,之前工作所有的努力都白費了。如果家庭、事業的需求都滿足了,接下來我們要為我們的退休生活做規劃了,最重要的需求的是健康跟保障。還有一個是老年的尊嚴問題,人活著最重要的是就是有一個被需要的感覺。如果老了,孩子都出去成家立業了,有自己的生活。那麼你自己的生活在哪裡,那保障性生活在哪裡?如果到時候還要跟子女伸手要錢,不要說經濟無法獨立,在精神上也不被重視,不被需要。這不是換工作就能達到的,這是需要規劃的。

這是我摘入一場演講的內容,回頭來看看,我現在的工程師的生涯規劃,工作快五年了,理論上想加薪,但是好像不可能,那就要跳槽囉!但也不知道要去哪裡,還是就這樣將就了。如果運氣好,可以跳到比較好的。做到中階主管,但是有可能可以準時下班,好的生活品質嗎?柯立爾現在好像比較難。應該說軟體業好像中階主管,要有不錯薪水,想準時下班都很難。如果運氣好真的找到了,我會想在走下一步做到高階主管嗎?去當印地安人,喔!這種生活我也不要。然後工程師退休呢?我要準備多少錢?聽說我們這一代可以活到85歲,如果那麼不幸,60歲退休,還要活25年,一年一百萬,也要有2500萬退休金啊!哇!這要不吃不喝幾年啊!這還不加上通貨膨脹。工程師的錢途真是無亮啊!

好累!明天有機會,寫的詳細點,先睡了。

Slim Diray 12/21 飲食:早餐/營養早餐+麵包;午餐:牛肉乾麵 晚餐:鹹水雞+雞腿肉+沙琪瑪+麵包,8:00前吃。
運動:Boot camp 1
體重:-12.0公斤 (與前次量輕0.3) 70.0公斤
體脂率: 21.7%
內臟脂肪等級8
就寢時間1:30 
檢討:體重下降了,但是體脂卻上升了。

留言

這個網誌中的熱門文章

解決 CI Trust Issue:Target Must Be Enabled Before It Can Be Used

📱 iOS開發 | 🔧 CI/CD | 💻 Xcode | 🐛 除錯筆記 🔴 問題描述 這兩天在跑 CI 時突然出現錯誤訊息: Package@swift-6.0.swift:PACKAGE-TARGET:CasePathsMacros: error: Target 'CasePathsMacros' must be enabled before it can be used 🤔 嘗試過的解法 💬 Claude 的建議 首先詢問了 Claude,得到以下步驟: 先更新 swift-case-paths 到最新版本 確保使用 "Up to Next Major Version" 執行 File → Packages → Reset Package Caches Clean Build Folder (Cmd + Shift + K) 重新 Build 結果: 一看就知道沒用 😅 🤖 ChatGPT 的建議 接著試了 ChatGPT 的解法,主要是降低引用到的 package 版本。繞了一圈,還是沒用。 ✅ 最終解決方案 最後還是回到 Google,找到了真正有效的解法。針對這個 macro fingerprint validation 問題,有三種解決方式: 📌 方法一:本機開發用(Terminal 指令) defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES 📌 方法二:xcodebuild 參數 在執行 xcodebuild 指令時,加上 -skipMacroValidation 參數 📚 參考連結: https://vocus.cc/article/690779ebfd89780001859b14 📌 方法三:CI 正統做法 ⭐️(推薦) 步驟 1: 在專案根目錄建立資料夾 ci_scripts 步驟 2: 在此資料夾中建立腳本 ci_post_clone.sh ,內容如下: #!/bin/zsh mkdir -p ~/Library/org.swift.swiftpm/security/ cp macros.js...

用 AI Debug 的迷思:當建議越改越糟時

現在許多開發者習慣用 AI 來協助 debug,但在實務上常遇到一種情況: 依照 AI 建議改了兩三輪後,錯誤仍然存在,甚至越改越複雜。 這種狀況其實有幾個常見的盲點,值得特別注意。 1. 先回到「上一個正常版本」 當你已經按照 AI 的方向修了好幾次但問題仍未解決時,最有效的第一步是: 回到上一個正常工作的版本,縮小問題來源。 許多 bug 並不是你正在看的那段程式碼造成的,而可能是: 同事剛好修改了某個底層模組 某個 shared component 產生 side effect Auto Layout 層級重新 layout 時觸發 crash 如果只是盯著眼前的 function 修,反而容易被誤導。 2. AI 沒有看到你的整個專案 AI 通常只能根據你貼出的片段判斷問題,這代表它不知道: 你的 view hierarchy 裡是否有其他 constraint 影響 layout 某些 model 是否被 extension 修改過 父層或子層邏輯是否干擾目前的行為 整個專案採用的 concurrency 模型是什麼 因此,AI 可能會朝著完全錯誤的方向修,導致反覆修改卻無法解決。 3. Swift 6 例子:錯誤真正原因常不在你修改的那一行 例如開發者常遇到的錯誤: passing closure as a 'sending' parameter risks causing data races 許多人(包含 AI)會開始從 function 內部調整,但這類錯誤真正的關鍵通常是: 傳進去的物件沒有實作 Sendable。 也就是說,你不是要改 function,而是要回頭檢查: 傳入的 model / struct / class 裡面是否有 non-Sendable 成員 是否需要標註 @unchecked Sendable 如果 AI 沒看到相關檔案,自然很難找到正確方向。 結語:AI 是工具,不是預言機 AI 很適合用來: 解釋概念 協助產生測試程式 提供重構建議 釐清你已懷疑的方向 但在 debug 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...

借助 AI 除錯:解決登出時的解密錯誤

  前言 最近遇到一個有趣的 bug,趁這次機會試試看用 AI 來協助除錯。整個過程蠻有收穫的,分享給大家參考。 問題發現 Bug 描述 在測試登出功能時,發現 app 會發生 crash。追蹤後發現是在登出時,API 會呼叫底層的解密函式,但解密用的 key 明顯有問題,導致解密失敗而引發錯誤。 由於這段流程是另一位同事負責開發的,程式碼邏輯比較複雜,短時間內看不出根本原因。於是先採取防禦性做法: 如果 key 為空值,就將解密失敗的錯誤吃掉不處理 。判斷後認為這樣不會影響 UI 操作,因為登出後 key 會重新取得。測試後確認沒問題,就先把這個 bug 暫時壓下來了。 深入追查 第一回合:初步分析 趁著有空檔,決定詳細釐清這個問題。想試試 AI 的能耐,於是下了第一個 prompt: 分析 SessionManager 的 processEncryptedData 方法中,為何會發生 bytesToTrim > currentLength 的錯誤?從呼叫該方法的地方分析可能發生的原因。 AI 給出了幾個可能的原因: 加密數據損壞或截斷 網路傳輸過程中數據包丟失或損壞 API 回應中的加密字串不完整 解密後的最後一個字節值異常大 錯誤的加密算法或密鑰 使用了錯誤的解密密鑰或 IV Session key 交換失敗,但程式繼續使用無效密鑰解密 解密產生亂碼 Hex 字串轉換錯誤 包含非法字符、長度不是偶數、部分缺失等問題 AES CBC 解密失敗但沒有檢查錯誤 Whitebox 密鑰準備失敗 IV 不匹配 數據長度不符合 AES 塊大小要求 PKCS7 Padding 格式錯誤 加密時使用了錯誤的 padding 方式 最後字節不是有效的 padding 長度值 (1-16) 多重解密處理錯誤 數據被重複解密或解密順序錯誤 記憶體緩衝區問題 緩衝區大小分配錯誤或溢出 AI 也分析了呼叫鏈: API 回應 → DataTransformer → CryptoHandler → decryptSessionKey → processEncryptedData 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...