踩雷無數的狐狸先生

 當注意力成為稀有貨幣, 預留深度工作的時間 變成想要變成高效率人士必學的技能 臉書的小紅點, 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 使用者案例應該以小步快跑不段遞增的方式去描述需求,  盡可能小到讓使用者案例可以在一個開發週期裡面被完成 怎麼分解到足夠小的部分,並且可以讓工程師快速的完成每一部分去向客戶提供價值 這是最大的挑戰 使用者案例的價值在於它能夠解決客戶的問題或是提供客戶想要的價值 一堆寶藏很有價值, 但是一塊錢也是有價值的 開發團隊經常會誤解為做完客戶想要的 所有事 才有價值... 我們應該把案例拆分到更小的單位, 更快且不斷交付提供價值給用戶 這樣做是會更有效率,  且單位更小的好處是當犯錯時更容易回朔,  這樣客戶和開發團隊所承擔的風險或更小 Depend

 如果你在工作上一直表現都不錯的話, 遲早都會遇到變成 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, 就會自動完成格式的調整,  非常方便