跳到主要內容

軟體工程師的生涯規劃

我們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 
檢討:體重下降了,但是體脂卻上升了。

留言

這個網誌中的熱門文章

勝券在握

其實這本書,感覺上寫的有點雜,比上一本講巴非特的書更難懂,兩個講的東西其實是一致的。投資原則便是先選產業,再選公司,慎選時機進場。只買了解的企業是價值投資一貫的原則。價值投資的書大概就先看到這裡了,彼得林區不知道是屬於那一類的,接下來大概會看這部份的書。暫時的目標是把杜金龍介紹的書單看完,真的還不少。接下來的投資會以巴菲特的方法來做,感覺上這比較適合我,練習把漲跌不當一回事,對我而言真的很重要。期權大概不會再玩了,買了以後一直在看漲跌,令人受不了。工作時都不能專心。 就價值投資人而言,真的不需要我們的產品,因為第一點就把我們程式特性打死,不理會股票市場的漲跌,這樣報價功能就沒什麼意義了,價值投資根本不需要技術分析,除非我們能提供相關價值投資的資訊,但我們基本分析真的很爛,看不到什麼資料。有機會我來思考一下價值投資到底要什麼資料,能不能把他寫成一個可運用的程式。 以下是我認為重要的書摘,其實這也只包含最後一章,我認為也只有這章值得做書摘。 巴非特相信使用短期價格來判斷一家公司的成功與否是愚蠢的。取而代之的是,他要公司向他報告因經濟實力成長所獲得的價值,一年一次,他固定檢查幾個變數: 初始的股東權益報酬率。 營運毛利、負債水準與資本支出需求的變化。 該公司的現金產生能力。 如果這些經濟指標正在進展,他知道長期下來,結果會反應在股價上。短期之內,股價所發生的是是不合常理的。 投資策略 不理會股票市場每日的漲跌 不擔心經濟情勢。 買下一家公司,而不是股票 管理企業的投資組合 巴非特原則 企業原則 這家企業是簡單且可以了解的 了解一家企業如何產生利潤的相關經濟活動。 這家企業的營運歷史是否穩定 他必須經得起時間的考驗。 這家企業的長期發展前景是否看好 市場特許權,五力分析 經營原則 經營者是否理性 理性的經營者將只會把多餘的現金,投資在那些產生較資本成本報酬率為高的計畫裡。 經營者對他的股東是誠實坦白的 報告時能知道營業部門如何營業,坦承失敗,了解公司的目的是使股東權益報酬率達到最大。 經營者是會盲從其他法人機構的行為 當心『其他公司也這麼做,一定沒問題』為自己行為辯護的經營者。衡量經營者競爭力的一個方法是,看他們如何運用自己的思考能力以避免依附群眾心理。 財務原則 把重點集中...

借助 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 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...

用 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 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...