跳到主要內容

[團隊,從傳球開始]

.
最近跟公司的前輩聊天,當時問他有什麼什麼書可以推薦給我,他推薦了我一本書,這本書是"團隊,從傳球開始"。或許是他希望給我一個方向,因為我在目前的團隊裡面是經驗比較多的,需要更有領導力來帶領現在的團隊吧。
.
這本書是關於 John Wooden 這位傳奇教練的領導哲學。Wooden 是美國大學籃球史上最難以超越的總教練,他在 UCLA 執教時讓當時的籃球隊達成全國冠軍七連霸,最長連勝高達八十八次。
.
書中有許多讓我自己感到很有幫助的文字,我把它紀錄下來
.
  • 領導者學無止境,若是停止學習就等同於死了
  • 推銷自己的價值與原則
  • 永遠不要企圖變得比誰更好,但是永遠不要停止成為最好的自己
  • 成功金字塔特質 : 勤奮、熱情、友情、忠誠、合作、自我控制、專注力、警覺性、衝勁、狀態、技能、團隊精神、鎮定、自信、極致的競爭力
  • 怎麼教 : 先解釋、再示範、跟著做、接著不斷重複
  • 律己最嚴
  • 如果會議時間是三點,而你三點才到,其實你已經遲到了
  • 要快,不要趕;如果你沒空把事情做好,那你怎麼可能還會有空重做一遍?
  • 什麼東西不能教? 人格、靈敏度
  • 跟願意傳球的人在一起
  • 自己負責;最終你所做的決定,決定了你是誰
  • 努力:成功的終極魔數。付出所有的努力,無論是個人或是團隊的一份子,都不是安慰獎或是次等的成就。在我看來,它就是頭獎,它才是最高等級的成就。
  • 別做24/7便利商店;Wooden 的訓練方式是每天只要兩個小時的時間,全心投入,絕對要參與所有訓練的細節。然而一但練球結束,籃球也就跟著結束了。
  • 一直問同樣的問題,[我該如何幫助我們的球隊變得更好?]
  • 別當個大氣球
  • 活在別人的期待是多麼蠢的一件事[太平洋也無法滿足所有人的期待]
  • 擁有好人生
  • 把你的資產最大化
這些摘錄的部份是我快速看過一遍後比較有感的地方。
整本書只有些許地方提到籃球,更多的地方反而是提到領導者的氣量跟原則。像是不斷學習,努力是重要的,勝利並不是最後的評斷。
.
這本書有好多很棒的觀念需要我細細琢磨,我覺得某些想法可以成為我自己的原則。
在看這本書之前我看過史蒂芬-柯維的與[成功有約],我發現這本書也有很多地方有重疊。像是要找到自已的原則,主動積極,努力不懈。
.
覺得最大幫助的幾個要點是,找到自己的路,全心投入事業2小時、而後還有其他也很重要的部分要照顧,像是休息與家庭。另外別活在他人的期待中,堅持自己的路,不斷努力。這部分是關於自已成長的部分。
.
對於團隊與領導的部分,雖然整篇著墨不少,但我領會的沒這麼多。可能自己還不是一個領導者,沒碰過很多領導的難點與痛點。目前比較有感的是"怎麼教",以及將上面提到自我提升的部分分享給團隊的成員吧,更細部的地方可能要等以後需要的時候可以再回來看一次看看。
.
整體而言,這本書給了我許多想法與振奮自己的精神。人總是有惰性的,常常看這些可以振奮人心的書籍,可以適時提供反思與檢視,讓自己更好。

留言

這個網誌中的熱門文章

[學習iOS之路] Lifecycle 比較

在開發Android很多年之後終於開始學習寫iOS了 契機就是工作需要,果然工作需求就是推開最大靜摩擦力的原動力啊! 在這邊寫下學習Swift的一些筆記,希望在自己忘記或是需要給別人教學的時候可以起到一點點作用。 因為對Android比較熟悉,所以透過比較來熟悉iOS架構 首先是iOS與android的比較 可以參考這張圖 Android vs iOS lifecycle 與這張 iOS 詳細state 流程 Android lifecycle OnCreate -> OnStart -> OnResume ->(running) -> OnPause -> OnStop -> OnDestroy                        ^                  ^                                  |               |                         |                  |-------------------v               |                         |-----<-----   OnRestart   ------<---------v iOS lifecycle LoadView -> ViewDidLoad -> ViewWillAppear -> ViewDidAppear -> (running) -> ViewWillDisappear -> ViewDidDisappear -> ViewWillUnload -> ViewDidUnload -> dealloc 於ViewDidDisappear之後view就看不見了,如果view要再次被看到且view還存在 那就會是ViewWillAppear,否則就是LoadView從頭開始 下一篇是語言的比較 Java vs Swift

Docker vs VM 的學習

工作上用到 Docker 也一段時間了,剛接觸到 Docker 時常常會聽到別人這樣解釋," Docker 的 Container 技術,類似於 VM 。差別是 Container 比較小,沒有包含 OS,而 VM 會包含 OS"。 這段話我覺得不算是全錯,所以我一開始也是這樣去解釋給別人聽,直到我聽到我同事在面試求職者時問了這句話,"如果 Container 比較快,比較輕量,優點這麼多,為什麼 VM 沒有被淘汰?" 我才忽然意識到,我並沒有真正瞭解這兩種技術的差別。 事實上,這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點,從這點來思考的話網路上就有很多文章可以查到了,我把我查到的最清楚的文章連結放下本文最下方,有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術,而這個需求仍然存在,並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣,事實上很多 Container 還是跑在 VM 裏頭,可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的,每個 Dockerfile 會指定使用的映象檔(image),然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置,就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的,為什麼在正式環境就行不通" 的問題。   參考連結

C# CSRF attribute 的錯誤追蹤與處理

最近開發網站碰到一個問題,有時候可以登入成功,有時候不行。但明明帳密都是 Google 記憶的,不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題,由於網站是透過 k8s 建立的,且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿,但登入是跟 B pod 登入,造成 token 無法驗證成功。 想證明這個問題,我們必須去紀錄 Log,由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦,因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現,CSRF 並不是丟出例外,而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果,並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行,這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN