程式設計師的工作慣性
這次要討論的主體可能跟創新的關係很小，請容許我離題。一般來講年後換工作的風潮在各個行業都會發生，我們來分析一下程式設計師工作的型態，這些分析可能在各行業都可以適用。
首先，我面對到程式設計師換工作的主要原因大部分是認為原來的工作創新度不足，使用的開發工具比較舊，原系統已經不做大幅度開發，只作例行性的維護，缺乏新鮮感，種種的跡象顯示很難獲得成就感，或者是無法獲得大家的一致的認同有價值。
但是，這時候程式設計師的確是一樣的忙碌，每有忙著救火，卻得不到掌聲，如果你正式處於這種狀況，你第一個想到解決的辦法就是換工作吧！然後原公司可能會在找一個人頂替你的位置，而你接觸新的工作，同樣的狀況兩年後又發生一次，這是一個無法解決的惡性循環。
問體出現在哪裡呢？我想並不是技術能力的不足，而是錯估了處理問體所花的成本，接專案的人總認為有一個洞，把他補起來就好了，哪知道有很多洞要補，而且補了洞還不一定知道是不是會產生另一個洞，所以需要從系統架構上的問題去了解，然後再來解決。
第二，可能是在系統整合上的問題，現在的系統大部分是採用開放式的架構，大家協同把所有的子系統放上去，第一次整合測試沒問題，第二次也沒問題，測試過後就上線了，但是系統運作的時間久了之後，有的子系統因為檔案讀取失敗，資料庫沒有正常運作，或者是當初沒有考量道的錯誤，造成平常操作人員的困擾，因為程式設計人員也換過了好幾代，文件不齊全，原始程式碼沒有說明，導致無法找出問題點。
這一類的程式設計師總覺得自己在接爛攤子，接愈多包袱愈大，最後只好選擇丟掉，其實，要解決整合的問題，別無他法，就是程式設計師或者操作人員下去做分析，詳細的一步一步的把錯誤訊息找出原因，然後把問題發生的狀況紀錄分析，然後看是要改程式來解決，或者是從作業流程去改變，這個以目前用 Excel 來做應該都綽綽有餘了，這個過程可能隨時都在做，但必須密集的去分析解決。
最後，可能跟資源的整合或是分開有關，公司會資源整合一定是有某些產品的收入不合經濟效應，所以一個人本來負責一個產品或專案，但是可能一個人變成負責兩樣產品，如果程式設計師還認為事情是Double 的話就錯了，可能剛開始的時候是這樣，既然負責了兩件事情，就要把程式碼變成一份，這樣慢慢地就變成一件事情了，不然比較差的方法就是安排事情的重要程度來處理。
另外最重要的想要換工作除了是被挖角跳槽之外，其實也有景氣循環這一回事，景氣不好的時候，開發新功能新產品的事情是比較少，維護程式系統的事情比較多，認清楚你的專長是在開發新系統還是在維護系統，在搭配業界的景氣循環，才不會永遠在景氣循環或是過年的時候換工作。
