Skip to content

Instantly share code, notes, and snippets.

@littlebookboy
Last active May 20, 2022 23:34
Show Gist options
  • Save littlebookboy/79f41c449f06de794ae071d7a006517a to your computer and use it in GitHub Desktop.
Save littlebookboy/79f41c449f06de794ae071d7a006517a to your computer and use it in GitHub Desktop.
More Joel On Software 約耳續談軟體閱讀筆記

Part 1 人員管理

CH01 我的BILLG審查初體驗

  • 寫規格的人,必須完全掌握你的規格,與關聯到的所有實作細節、邏輯

CH02 尋找優秀的開發人員

  • 各領域中最好的人才不會出現在人力市場,而且他們花在「應徵」這件事上的時間很短

CH03 開發者實戰指南

  • 優秀的開發者想要的是什麼,想在什麼工作環境下做事,喜歡什麼?又討厭什麼
  • 私人空間可以增加程序員的生產力,提高軟體開發效率
  • 組織內部如何看待程序員,只是打字員,還是重要人才
  • 聰明,且能把事情搞定,不是怪胎
  • 別讓自己的「建議」被解讀為「命令」,讓其對在自己專精的領域內做決策
  • 不搞不正常的政治
  • 讓開發者做有趣的工作
  • 年輕的程序員會被意識形態吸引
  • 希望自己的工作是有意義的
  • 培養程序員的認同感
  • 薪資公平,避免同工不同酬
  • 薪資必須要有(同業中)競爭力

CH04 三種管理方式(導論)

  • 讓大家做你想做的事情
  • 指揮及控制管理法
  • 經濟學101管理法
  • 認同管理法

CH05 指揮與控制管理方法

  • 不管你說什麼,照做就對了,不服就斥責、處罰
  • 聰明的人不喜歡被下自以為是的指揮、命令,會不爽
  • 軟體開發細節太多,管理層淪為打了就跑
  • 知道最少的人反而是做技術決策的人,而非開發者
  • 讓他們向士兵一樣照命令做,尤其對優秀的開發者到哪都可以工作,會留不住人

CH06 經濟學101管理法

  • 付錢讓人們去做本來就想做的事,外在動機就取代了內在動機,降低了想把事情做好的渴望
  • 外在動機:賺額外的錢
  • 內在動機:把程式寫好
  • 導致:我不想賺那額外的錢,程式沒寫好,搞的自己花超多時間除錯->寫出破綻很多的程式
  • 或導致:我想賺額外的錢,所以我會花額外的時間把程式寫好,但一旦你抽掉這個額外的錢,我就不願意花額外的時間做好這件事
  • 找出能換取你給予得東西極大化的方式,例如讓「錯誤 (看起來) 很少」,任意掩飾所有的錯誤,換取獎勵,卻導致產品不穩定,但你本身給這個獎勵的初衷是「錯誤很少 = 產品要穩定」

CH07 認同管理法

  • 讓大家認同你想達到的目的
  • 讓大家對同事都有某種忠誠與承諾感
  • 提供資訊,讓人們將組織駛向正確方向

Part 2 給未來程式員的建議

CH08 JAVA學校帶來的危害

  • 打好寫程式的基礎

CH09 在耶魯大學的演講

  • 因為找不到現成的軟體而雇用內部程序員(你)開發內部軟體,你永遠無法用正確的方式做事,只能用最便捷的方式來做,因為「這很花錢」
  • 只要程式夠好夠用,你就要住手了
  • 一旦核心功能完成,後續投入都沒有回報,沒有商業上的理由要去改善它
  • 能夠清楚的寫好技術主題文章,是底層程序員與領導者間的差異
  • 寫作能力、鍛煉大腦內對往後有幫助的能力

CH10 給電腦科系學生的建議

  • 學會寫作
  • 學會C
  • 非專業領域的課(覺得無聊)不要一開始就排斥,每個工作的都有無聊的時候,很多公司不會想請只想做有趣好玩事情的人
  • 學會個體經濟學,提升個人價值
  • 寫大量的程式

Part 3 設計的衝擊

CH11 字型平滑化,去鋸齒與次像素渲染

  • 人們會選擇他們熟悉的(風格或設計)系統

CH12 逐吋的競賽

  • 想要創造一份有用的軟體,你必須爭取每一個修正、每一個功能,還有每個小小的妥協,努力幫助多一個人跨越學習曲線
  • 每天進步一點、把每件事都做更好一點,就是多一寸進展

CH13 大局觀

  • 必須對要做的事情全盤清楚,不要掉入過度自信的情況,大腦會誤以為對事情已經非常清楚,甚至都不寫規格直接開始寫程式
  • 唯一比軟體設計困難的事情,就是讓團隊一起設計軟體,你還沒設計好就不要僱用程序員

CH14 選擇 = 頭痛

  • 選項越簡單易懂,才是越好的設計,但軟體設計往往希望提供越多越彈性的選項,讓使用者反而不明白用途發生選擇障礙

CH15 不只是可用性

  • 可用性不是隨時隨地都是必要的
  • 人與人互動的介面:社會性介面
  • 人與軟體互動的介面:使用者介面
  • 除了做好使用者介面,社會性介面才是最重要的,如果你的軟體無法顧及到人,與溝通對象,使用者介面再好也沒用
  • 考慮文化與人性
  • 防禦性設計,例如垃圾信阻擋,讓信箱更好用
  • 工作使用的輔助軟體,常常因為要求所有人同時改變工作方式,而無法持續。...設計成刻意讓產品在團隊中只有一人參與時也仍然有用,在另外大量設計其他功能,鼓勵把軟體散布給團隊其他成員,直到所有人都在使用

CH16 用軟體建設社群

  • 論壇設計重點,放在增加交談意願,免註冊開放留言可以起鼓勵效果
  • 依照原貼文發佈時間排序,而非最後更新時間排序,可讓閱讀者有順序的看文章,不用一直去看到舊的文章
  • 有新的回覆的文章可以藉由把回覆數量掛在 url 上,瀏覽器就會因為數量有變化而判別成沒有點過的連結
  • 回覆文章的按鈕或開新文章的按鈕都放在最後一個留言下面,強迫使讀者先看完留言再看看需不需要開新文章或留下留言
  • 不做確認步驟是因為大多數人編輯時就會確認文章,且少了確認動作反而使人更謹慎的發出留言
  • 不顯示回覆對應的原文,是為了讓閱讀更流暢,不強迫使人一直重讀原文,太繁雜
  • 消除空餐廳效應,如果你的網站都沒人留言,會導致沒人想逛,反而會去逛一些文章質量差,但有人流的網站
  • 就像首頁提供的敲客服,即使你不是會員也可以使用客服系統
  • 制定規則只會侮辱多數守法公民,並不能阻止低能兒認為自己不可能違反規則,或不在意自己有無違反規則

Part 4 管理大型專案

CH17 火星耳機

  • 要讓軟體滿足所有版本或標準格式是不可能的,舊有軟體跨到新建軟體,會有不相容的問題,那所謂的標準格式無法通用支援新舊軟體上

CH18 為何Microsoft Office檔案格式如此地複雜?(以及一些變通辦法)

  • 略,這章還讀不出想表達什麼

CH19 想賺錢就別怕髒

  • 為了賺錢投入人力與成本,做能賺更多錢的部分,而非一味做自己想做的部分

Part 5 對程式編寫的忠告

CH20 證據式時程安排

  • 使用工具輔助訂定時程,逐步掌握如何預測準確的時程

CH21 策略書之六

  • 略,這章還讀不出想表達什麼

CH22 你的程式語言能這樣做嗎?

  • 了解第一級函數的用法,可讓你的程式有更多手段,設計具擴展性、更抽象的邏輯結構,更彈性且易於重用

CH23 讓錯的程式看得出錯

  • 學會如何分辨「乾淨」或「髒」的程式碼
  • 程式員層級
    • 你不知道「乾淨」跟「髒」有什麼區別
    • 你對乾淨有粗淺的認知,主要以是否符合編程規範為準
    • 你開始能嗅出藏在表面下不對境的蛛絲馬跡,你會察覺這是問題,並且找出來加以修正
    • 你有計畫地架構程式碼,借助能察覺問題的靈眼,讓程式碼更正確
  • 光看該行程式碼就足以看得出錯
  • 通則
    • 保持簡短的函數名稱
    • 變數宣告的地方離使用的地方越近越好
    • 不要讓左右括弧超過一個畫面
  • 找出能讓錯誤程式看起來是錯的編程規範

Part 6 開創軟體事業

CH24 「ERIC SINK ON THE BUSINESS OF SOFTWARE」一書的前言

CH25 「MICRO-ISV:FROM VISION TO REALITY」一書的前言

  • 在落後的軟體專案裡增加人力,只會讓他更落後

CH26 飆出高音

  • 平凡人就是永遠唱不出天才隨時能飆出的那種高音:這不僅是10倍工作效率的問題,而是生產力尋常的開發者,永遠也飆不出製作優秀軟體所需要的那種高音
  • 頂尖的工作環境->頂尖的程序員->頂尖的軟體->賺大錢

Part 7 經營軟體業務

CH27 超級辦公室

  • 辦公室應該是個窩,辦公室應該比一般程序員的住家更棒

CH28 巧婦難為無米之炊

CH29 簡單

CH30 洗刷刷、洗刷刷

  • 重構,不要加入新功能,就算很小很小的功能也不要
  • 系統隨時都能完全正常運作

CH31 實施BETA測試的12項提示

  • 技術 beta 與行銷 beta 是不同的,前者目的是找出問題,並持續得到意見回饋,後者是軟體的搶鮮版,針對的是媒體與大客戶

CH32 邁向卓越客戶服務的七個步驟

  • 每件事都用兩種方法修正
    • 表相而即時的辦法,與思考更深層讓問題不再發生的解決方案
    • 「技術支援人員」須能直接接觸「開發者」,比較貼近問題進而修正使其不再發生
  • 建議吹掉灰塵
    • 有客戶抱怨鍵盤不會動,客服不該直接請客戶檢查是否接頭沒接好(讓客戶覺得自己被當成白痴),應該換個說法,例如可否幫我重新拔掉接頭、吹掉灰塵,再連接回去,因為灰塵可能會導致接觸不良,於是客戶就會發現其實是自己沒接好接頭,但不用觸怒客戶,問題一樣有被解決
  • 讓客戶成為狂熱支持者
    • 幫客戶吸收「因為客戶報錯需求導致產品製作錯誤」的成本,讓客戶覺得很溫暖,成為自己產品的推銷者之一
  • 承擔指責
    • 身為產品開發商,若有錯誤,需要有向客戶承認「是自己做錯」的擔當
  • 背誦緩頰短句
    • 不要被情緒左右而衝動出口怒言相向,趕走客戶,試著不經過大腦就說出「對不起,我們會改善,是我們疏失」等短句
  • 練習表演木偶戲
    • 跟客戶吵架,你永遠不會贏
    • 要理解客人不是對你生氣,而是對就近代表公司的你(公司的木偶),對公司(產品開發商)生氣
  • 貪婪讓你一無所獲
    • 如果沒有讓你很快樂(產品不好用、不實用),我們不收你的錢,就算我們訂定的退款政策是90天不滿意可以全退,但91天、100天、150天,你感到不快,我還是退給你錢
  • 附贈:為客服人員規劃職業前景
    • 提供進修資金補助轉為技術開發者

Part 8 發行軟體

CH33 選擇交貨日期

  • 列出所有功能按優先順序排列,每次時程延誤就把不重要的功能砍掉,確保出貨日不變
  • 先行版避免大量宣傳,導致大多數人的第一印象都很差,無法挽回名聲

CH34 駱駝和橡皮鴨

  • 定價需要參照利潤,且不要考慮沈默成本
  • 資本家會想要獲取消費者剩餘(對於那些願意付更多錢取得相同服務的人,因為你定價太低而不用付出太多金額就取得,差額即為消費者剩餘),所以出現區隔訂價
  • 未來收益流入的淨現值最大化(淨現值是估算現在的金額,在幾年後根據年利率而折算的結果)
  • 現金儲備一直為正值

Part 9 修訂軟體

CH35 五個為什麼

  • 黑天鵝孤立點,指很少很少很少很少,罕見的突發事件
  • 甜蜜點,指綜合各種因素下的最佳方案

CH36 安排你的優先順序

  • 如果你正在做某些只針對單一客戶的事情,表示你的業務不受控制
  • 不要因為你「遲早都要完成」就去先做目前當下不是最重要、最優先的功能,會吃掉你現在的時間
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment