踩雷無數的狐狸先生

 當注意力成為稀有貨幣, 預留深度工作的時間 變成想要變成高效率人士必學的技能 臉書的小紅點, Line 的小綠點, 以超高的成癮性在破壞人們的專注力 如何在一堆瑣事中找出相對重要的事,  就變得非常有價值 深度工作 在免於分心專注的狀態下進行的職業活動,  這種狀態可以把你的認知能力推向極限, 這種努力是可以幫助創造有價值或是改進技術能力, 並且是他人難以模仿的 淺薄工作 非高認知需求偏向後勤的工作, 往往在注意力分散的狀態中執行, 無法創造出新價值而且很容易被模仿 深度工作越來越稀有, 正好顯示於它的價值上面, 只要好好地培養這種能力並且善用它, 就可以成為各行業中的佼佼者 成為新經濟中的贏家有兩個很重要的核心能力 快速精通轉業技術的學習能力 在品質和速度達到高水準的生產力 深度工作力幫助快速學習困難技術 你的注意力必須專注在某個你嘗試改善的技術或嘗試精通的思想 你需要獲得回饋以糾正你的方法, 讓你把注意力放在最有生產力的地方 深度工作力協助你達成高水準的生產力 高品質工作  = 花費的時間  X 專注程度 把工作時間的專注程度最大化, 就能將每單位工作時間的產能最大化 注意力殘留 一但達到夠高的職位就必須同時處理多項專案, 會議一場接著一場, 思緒在不同專案接跳來跳去 問題是當你從任務A換到任務B的時候, 注意力很難立刻跟著轉換, 你的注意力能然會殘留在原本的任務上面, 進而影響到下一個任務的表現 分心帶來成本, 深度可以提升價值 破壞深度工作所造成的影響不輕易測量 - 度量黑洞 由於缺乏特種行為對企業影響的反饋, 我們傾向採用當時最容易的方法 - 最小阻力原則 在沒有明確指標可以證明工作是否有生產力的時候, 會選擇做很多事 - 以忙碌代替生產力 專注力是有限的資源, 你可以決定花在優先事項中或者是非必要的事件上面 如何將深度工作列為優先事項？ 確立你的工作哲學 修道院模式 -  為深度工作安排時間與世隔絕不要受到外界的干擾 雙模式 - 分配明確的時段給深度工作, 其餘的開放艮別的事情 節奏式 - 把工作變成簡單規律的習慣, 去創造節奏(可藉由月曆上的記號輔助) 記者式 - 任何時間都能安排時間適應深度工作 (須經過良好的訓練) 建立深度工作的儀式 深度工作的儀式沒有明確的定義,完全取決於個人和工作類型...

汽車大王亨利福特的名言：如果我當年問顧客他們想要什麼，他們肯定告訴我要一匹更快的馬。 什麼是「破壞式創新」？（Disruptive Innovation） 與主流客戶特別看重的指標特質大不相同, 而且在特別某幾個看重的指標,新的技術通常遜色很多破壞式技術獲得採用獲肯定, 一開始往往只出現新市場或新應用上, 這些技術的改進和成長速度超快, 逐漸的入侵既有的市場 如何判斷是破壞式創新或者延續性技術？ 從檢視內部開發人員對於現在新產品或技術出現的意見分歧,以往績效傑出的技術人員, 往往堅持主張技術的新市場將會出現, 就算面對關鍵顧客及市場行銷高層的反對也一樣,  這通常是一種訊號 延續性技術 (sustaining technology) 往往可以保持某個改進速率, 這通常時顧客看中的特質, 一般來說, 客戶或公司高層會偏愛可預期效能增長的技術, 很可以掌握透入多少資源可以在未來的某一個時候得到與預期差不多的增長 面對破壞式技術時,很少有公司可以克服規模或是成功的障礙, 往往因為公司的文化或是選擇打安全牌, 這一點不意外, 但是可以做到的一點是偵測並培養破壞式技術的技術 決策者必須有能力偵測可能屬於破壞式創新類型的技術, 若要開發新技術並且商業化, 高層必須要能保護這些技術, 不受服務既有客戶的干擾, 而唯一的保護方法是設立獨立的組織在主流事業外

 什麼是使用者案例(User story)？ 怎麼區分好與壞？ 軟體開發的三個基礎 知道問題 針對問題提出寫法 (程式開發) 確定問題有確實被解決 但是工程師經常的省略了某些步驟, 甚至專注在程式開發上, 不管其他兩項了... 怎麼知道我們的產品或系統正面臨什麼問題,  這其實是非常的重要,  要先有明確的問題才知道如何去解決... 這邊經常被省略或是有些常見的錯誤 Remote control Programming 使用者案例(User story) 一般不會告訴程式人員該如何解決問題或是提供解決方案, 好的使用者案例更應該在描述問題或是需求的本身, 至於該如何解決接給專業的工程師來就好 這種案例很常發生在有技術背景的PM or Planner 身上, 他會依照他過去的經驗提供一些解法 這個table 多開個什麼欄位,  這邊多傳個什麼值就可以解決問題了 導致PM or Planner  開出來需求就是加個欄位加個回傳值.... 但這真的是最好的解法嗎？ 說不定技術框架已經跟以前不一樣了？或是有其他更好的解法？  開發團隊沒有真正的是了解為什麼要做這個改變,  同時也限制了解決問題的創意 Story as a contract 開出來的功能需求跟被要求遵守的規範是一樣的,  需求應該是可以引領工程團隊作進一步的對話跟討論 在討論對話的過程中常常會出現更有創造力更有效率的解決方案 使用書寫的方式去記錄規範, 很容易產生誤解 下雨天留客天留我不留 不同的斷句地方就會有不同的意思 如果有一個交互式對談就可以明確的澄清問題以及用戶的需求 好的開發團隊在收到案例初期應該會有大量的交談對話去建立問題的細節 Monster stories 使用者案例應該以小步快跑不段遞增的方式去描述需求,  盡可能小到讓使用者案例可以在一個開發週期裡面被完成 怎麼分解到足夠小的部分,並且可以讓工程師快速的完成每一部分去向客戶提供價值 這是最大的挑戰 使用者案例的價值在於它能夠解決客戶的問題或是提供客戶想要的價值 一堆寶藏很有價值, 但是一塊錢也是有價值的 開發團隊經常會誤解為做完客戶想要的 所有事 才有價值... 我們應該把案例拆分到更小的單位, 更快且不斷交付提供價值給用戶 這樣做是會更有效率, ...

 如果你在工作上一直表現都不錯的話, 遲早都會遇到變成 team leader 的機會 這件事並不是對每個人來說都是好事,  聽過許多工師拒絕了這個機會,  並表示只想好好處理好程式的問題,  處理人的問題太麻煩了.... 技術能力很強並不等於管理能力也很強, 更多人在第一次在當leader 之後最先面對到的問題 也許我們可以先想一下 team leader 在團隊中應該扮演什麼角色？ 可能就會找到合適的方法 Leader 的工作是幫助團隊更有效率的工作, 並不是要解決所有的技術問題 就像足球隊的隊長, 他的責任不會是負責所有的進球, 他可能也不是球技最好的那一個 隊長的工作是讓每個人知道在什麼時候該做什麼事情, 怎麼跑位, 怎麼配合 帶領團隊往更高的目標前進, 有時候給一些建議和指導 大部分leader 會遇到的第一個難題是   微觀管理（Micromanagement） 對於成員工作或行為做了太多的檢視和規範, 但其實這些leader 並沒有太多的惡意 他們心裡想著說: 因為我過去的做事方式替我帶來了成功, 現在成為了leader, 可以證明這樣的做事方式是有效的, 其他member 可以照我的方法做, 大家都會很有效率了 但是忘了不是每個人都適用同一套方法... 你的工作是提升團隊的績效, 如果採用微觀管理你會能為拖累, 約束團隊進步的瓶頸 大家要花很多時間去適應你的方法,  不能自由地採用讓他們成長最多的方式去做事 如果遇到連你也不會的技術或事情呢？ 你是否就變成了團隊能力的天花板？ Allow team members freedom to do a worse job than you would 你必須允許團隊成員用他們自己的方式去工作, 同時並支持發展他們的技能和能力 這其實很反直覺也很困難...眼睜睜看著成員用沒效率的方式工作或是即將得到失敗的結果 但是他們必經的學習過程, 從失敗中學習最有效果了 如果leader 每件事都要插手管理給意見的話, 很容易讓成員沒有信心 事情發展順利的話他們會覺得完成的東西沒有成就感, 事情如果發展不順利的話, 非常有可能會將責任都推給leader , 而忽視了執行的細節可能沒有到位 但也不代表leader 應該放任所有的錯誤, 應該可以評估錯誤的風險團隊是否...

寫完程式排版都醜醜的....或是在寫的當下不想要花心力去注意排版？ 我們可以利用一些套件幫忙完成  VSCode 安裝延伸模組 “Prettier ESLint” https://marketplace.visualstudio.com/items?itemName=rvest.vs-code-prettier-eslint 該如何開始使用呢？ 首先要先選擇文件格式化方式 (format Document) 可以在按下右鍵之後跳出來的選單裡面找到 也可以使用快捷鍵  Command ⌘+ Shift 鍵 ⇧ + p  之後輸入 format documnet 就會跳出下方的格式選擇器,  可以挑你想用或是喜歡的 之後也可以藉由上面提的方法去更改預設的格式 當寫完城市要存檔之前,  就可以點選右鍵的選單 格式化文件  或是 Option ⌥ +  Shift 鍵 ⇧+ f  就可以自動套入之前設定好的格式 有沒有更快的方法？ 覺得每次都要按右鍵選格式化文件 覺得非常麻煩..... 有的～～工程師能有多懶就想要多懶 Code -> 喜愛設定 ->  設定 (快捷鍵 : Command ⌘ +  , ) 在搜尋設定中輸入關鍵字 : format on save 打勾 - 在儲存時設定當案的格式選項,  當你完成coding 時按一下  Command +  S, 就會自動完成格式的調整,  非常方便

我們都希望透過測試自動化, 來讓測試夠方便一點, 或是把人力投入在更有效率的地方 手動的做每一次的回歸測試 (Regression), 對人力的消耗是非常大的 事實上 regression test 不太適合由人去執行...  regression test 理想上是可以完全重複, 我們希望在每一個的測試,執行一樣的步驟, 得到一樣的結果 這件事由人做會比機器做得更精準嗎？ 這是我們選擇做test automation  的原因, 那我們對automation 的期待是什麼？ 在沒有任何變動的情況下, 我們希望相同的版本和相同的環境能得到相同的結果  更重要的是我們希望系統或功能真正出現問題的時候失敗,  但是要做到這一點非常的難... 我們常常會遇到測試的不穩定 (Test Flaky) 帶給我們不可預期的結果 不穩定帶我們的結果是什麼？  在沒有任何變動的情況下,  綠燈, 紅燈交互出現  你選擇相信哪一個？紅燈？綠燈？ 這種flaky 的情況下,  選擇哪一個都是在欺騙自己... 在沒有查看之前,你不會知道是真的有功能壞掉, 還是只是假警報 如果你不相信automation 帶給你的測試結果,  這樣寫automation 還有意義嗎？ Treat Tests as Falsification, Not a Proof Test Automation 執行過後沒有噴出任何錯誤, 不代表系統沒有錯 有可能是你的測試寫錯了, 或是沒有涵蓋到這一塊 但是我們可以換一個角度想, 會讓我們更有信心 當automation fail 的時候, 代表是真的遇到了問題 五個會導致Automation Flaky 的原因 環境 (Environment) 測試資料 (Test Data) 版本控制 (versioning) 資源限制 (Resource Use) 系統行為 (System Behavior) 環境 (Environment) 如果我們的Automation 所使用的環境以任何方式的不穩定, 這些可能是配置上的改變或是依賴第三放的服務, 這些變化都是我們不可預測及掌控的 最常遇到的說法是 在我的環境或是local 跑起來是好的啊～～ 如果程式碼都一樣,  最大的差別就...

 軟體工程一向都是複雜的, 很多問題都是藏在細節裡面一開始都不會發現, 直到他咬了你讓你感到頭痛 怎麼樣快速的找到不熟悉技術的通關密語或是秘訣,讓整個工作便順利, 這是本篇想要聊的重點 會有幾個徵兆或是信號代表系統或是開發過程可能會出現問題 使用大家都不熟悉的技術 缺乏專注, 團隊成員一開始可能都是以兼職的方式會是side project,並不是非常的在意 時間壓力 解決問題的第一步 : 版本控制 &  可部署性 利用docker 或是容器化技術讓local 和 real  環境跑的程式碼是一樣的, 差別只是要做管理設定配置 (configuration) 使用版本控制可以低風險的嘗試錯誤, 當發現下一步走錯的時候,  可以很簡單的回復成上一個可成的版本 雖然這件事看起來沒有什麼大不了的事...但是他對整體的工作模式有了很大的改變 你不能明智的期待我們會準確預測未來的事 所以了解當下的問題以及做出當下適合的決策很重要 即使這個決策在之後被證實他是錯誤的, 但是我們已經開始在執行且發現錯誤了 等待完美的方法 VS 快速面對失敗且快速學習 但在倡導快速的時候, 我們很常會掉入另一個陷阱裡.... 當我們面對問題的時候,  可能會很快地提出解決方案, 但是我們看到的只是問題的表面 而忽略了我們想要解決的問題是什麼？ 導致走的方向偏離原本的目標 你對目標的猜測遠比你所決定採取的步驟更為重要 如何選擇正確的技術？ 如果你的技術沒有做正確的事,  有時候他會讓你的工作變得更加困難,  技術選擇問題的時候應該這麼做 先釐清我們想要解決的問題是什麼？ 再來尋找有哪些技術可以解決我們所遇到的問題？ 這個技術能做到前面提到的版本控制嗎 再思考這些技術所帶來的限制或是缺點是什麼？ 是我們可以承受的嗎？ Goal over Tech  選擇王牌技術 (Feature of top trumps)可能不會是最好的, 每個問題都不一樣, 適用的技術也不一樣 只有適不適合的技術 Make it work before you change, Make one change at a time 在動手修改配置之前先確定他是可以正確運行的, 有點類似TDD 的概念, 先是綠燈再來重構 且不要隨機的改動配置, 應該要...