來源：http://but.tw/2008/10/programmers_rule/
SE是日本軟體公司的職稱(不是Sony Erission)。自己不太寫程式，主要工作是跟客戶確認規格。在台灣隨公司不同，比較接近SA或PM。
- 每天有24小時。所謂的「今天之內」，是指到明天早上為止。
- 程式不會照自己所想的跑。只會照所寫的跑。
- 需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。 - 我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
– C.A.R.Hoare - 程式碼不要在開發現場寫！ 去客戶那寫！除錯不要在期限前做！ 上線後再做！
- 畫面好藍啊。
(譯註) 世界第一個太空人尤里·加加林的名言「地球好藍啊」。
(譯註) 也有傳說有太空人在太空站裡安裝 Windows NT 時說了這句話。 - 先說「沒辦法」的人贏。
- 有意見的話你寫。
- 要殺一個程式設計師不需要刀，改三次規格就好。
- 首先要先懷疑別人，被懷疑的人或許會把問題解決掉。（註：通常會「先懷疑自己」）
- 開發沒有終點。只有釋出(release)。
- 無論規格多晚才能確定，結案期限永遠不會變。這是所謂的「期限守恆定理」。
- 客戶總是覺得水跟追加需求是不用錢的。
- 付錢愈計較的客人愈囉唆。
- 在排定開發行程時，總是視而不見一些連小學生都會的算數。業務部門總是一堆不知道 1+1=2 的人。
- 一個人掛了大家都掛了。
- bug 過了一晚可能就變成規格了。
- 好的規格找一個天才不如找三個凡人。爛的規格找一百個凡人不如找一個天才。
- 客製軟體中30%的價格用在確認規格上。30%用在修改規格上。30%用在找bug。結果初期規格反映在價格上占的比例只有10%。
- 對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。 - 顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。SE想受顧客喜歡，則要讓程式設計師討厭自己。
- 很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，不過都沒這種機會。
- 品質的劣化程度依規格改變的次數與規模而定。
- 業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。 - 有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
- 程式是運氣與直覺堆砌而成的奇蹟。若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。而追加修改則是相信奇蹟還會重現的魯莽行動。 - 程式設計師聽了「把自己當作顧客去著想！」而開始思考。啊，像夢一樣。
- 對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。程式語言可以看著手冊溝通，客戶不行。
- 程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。 - SE需要持久力，程式設計師需要爆發力。
- 準時離開公司，工作會變多。
- 完美的程式需要完美的時間與金錢。聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
- 詳細設計要在程式碼的註解裡做完。註解是唯一的自衛手段，至少要讓自己看懂。
- 還有時間看程式碼的話就執行他。CPU跑得比腦細胞快。至少這時候可以休息。
- 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
- 所謂便服日，好像社會上把他叫做假日
(譯註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但… - 地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
(譯註) Runner’s High 指跑馬拉松到後段反而精神舒暢的狀態。 - 遠處的火災一定燒到這裡。
- 禱告，然後工作(work)吧。（修道院的標語）
- 程式不是用腦記的，要用身體記住。
- 明天能放假的話死了也罷。
- 外面有下雨耶，昨天開始下的嗎？
- 若不能心死，身體會死。若不讓自己殘忍，自己會被殺。
- 客戶會說謊，業務會作夢，SE會做白日夢。程式設計師則惦惦。（愈來愈自言自語）
- SE總是不講理的(unreasonable)說「沒有辦不到(impossible)」，業務總是沒辦法(impossible)說「沒道理(unreasonable)」。
(譯註) 日文文字遊戲。 - 規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
- 再嘮嘮叨叨下去也是要付錢的。
- 多想個10秒鐘，你可以不說「嗯，這個做得到」。
- 人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從Mizuho的失敗中記取教訓。
（譯註：Mizuho是日本知名銀行，當初合併系統上線時發生整合錯誤系統掛掉） - 老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。 - 所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
- 程式、SE、經理不是職種。是職責。
- 業務是最難搞的客戶。
- 能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
– Jon Bentley - 漂亮的規格，可以從沒有bug出現看出來。明明爛的就是設計，為什麼是這樣…
- 上線後的除錯才叫做bug。
- 追加需求確定後交貨期限就無法確定，交貨期限確定後追加需求就無法確定。這稱為「追加需求與交貨期限的測不準原理」。
- 除三個錯就會冒出一個錯。這稱為bug的無窮迴圈。
- 不祥的預感總會實現。不過程式設計師不會去煩惱不祥的預感，那是SE的工作。
- 要解決地獄的辦法，就是客戶把錢交出來。
- 不懂電腦的操作者是發現bug的天才。而且無法重現。
- 每次開會就更改規格的客戶，他的操作手冊要等到操作寫好的程式後才能寫出來。
- 搞不懂的時候，Currency（長整數）比Interger（整數）好用。Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。安全第一。（VB程式設計師如是說）
- 啊，那是微軟的規格。
- 程式設計師所不滿的規格也一定會讓客戶不滿。（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）
- 程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。 - 正因為健康，才能做不健康的事。
- 規、規格、是規格啦。不過跟規格有一點不太一樣啦。
(譯註) 仿自電玩《純愛手札》「義、義理、是義理啦。不過跟義理有一點不太一樣啦」。 - 那是你說的規格。
- 開發室沒有窗戶，那是因為以前…
- 即使爛了，規格還是規格。(譯註) 模仿自日文俗語「腐っても鯛」＝瑕不掩玉
- SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態） - 為什麼你不能兩三下解決掉他啦。因為之前兩三下搞定的東西也被你兩三下就否定了。
- 不會動的bug就只是普通的bug。（會動的bug則能視為規格）
(譯註) 宮崎駿電影《紅豬》「不會飛的豬就只是普通的豬」。 - 今天好好清理bug，bug應該死光了吧。咦？Windows也死了唷。
- 客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。 - 唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。 - 共同責任是程式設計師的責任。管理職？那是啥？好吃嗎？我沒吃過耶。
- 如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
- 對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，也就是新手程式設計師也能馬上動手改的程式。而要寫出這樣的程式，需要單純、簡單、美麗的規格。但可惜客人總是喜歡搞很複雜。
- 設計者應該是不該要求製作者製作出超過設計以上內容的吧…
- 無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。所以程式設計師只做規格書裡的寫的內容。
- SE對程式設計師說的「常識」每三小時變一次。
- 自己看規格書。不能跑的是規格。
- 「沒辦法」是要看把一天當多少小時來算。一天常常指的是3人日，一個月常常是指4.5人月喔。
- 工時要減掉一半的單體測試與一半的系統測試，而交貨期則要另外加上上線後的兩個月。
- 能拿到錢的規格變更稱為「受理項目」，拿不到錢的規格變更則稱為「SE的規格確認失誤」。程式設計師是這麼看的。
- 累了。我想睡了。可以回家嗎。（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）
- 試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。
- REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
- 有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
- 小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路 - 「不要讓老闆當業務比較好」
- 說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。
EX 另外追加：
- 就算程式裡沒bug，編譯器會有bug。就算編譯器沒bug，OS會有bug。就算一切都沒bug，客戶會決定什麼是bug。
- 規格與規格書是不同的東西。
- 比期限更重要的是靈感與睡眠。
- 比知識與經驗重要的是手冊與時間。
- 能動就好了，能動的話…
- 過了三天就是別人寫的程式碼。
- (大搜查線系列)規格變動不是在會議室裡發生的！是在現場發生的！
- (大搜查線系列)異常不是在模擬測試時發生的！是上線後才會發生的！
- 漂亮的設計三天或許就膩了，骯髒的設計三天就習慣了。
- bug與規格是一體兩面。
- 電腦裡沒有bug，bug常在人心。
- 無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)
- 估價需要1%的經驗與99%的直覺。
- 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
- 『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
『PM』＝每天修改自己定下的行程表的人
『業界老鳥』＝臉色蒼白缺乏表情的人
『外包』＝幫不會寫程式的正職員工寫程式的人
『coding』＝複製貼上的工作
『單體測試』＝指開始寫程式
『除錯』＝把程式碼註解掉的工作
『新同事』＝在火燒屁股的專案火上加油的人
『出貨日』＝把只完成一半的系統上線的日子
『末班電車』＝業界平均的下班時間
『颱風假』＝一年一度可以準時下班的業界假日 - 當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
- 最終手段「重開機」意外的常常都很有效
- 最強藉口，以前「那是硬體的極限」，現在「那是Windows的規格」
- 「程式碼的可信度，不會比寫的人還可信。」
趴兔：
- 最好騙的總是自己。
- 抄來的程式碼是bug之母。
- 輕易刪掉的程式碼，往往在之後都需要用到。
- 電腦不會騙你，測試資料有錯時，都是人錯了。
- 交貨日是為了打破而存在的。
- 程式碼如其人。
- 發問是一時之恥，不問是一生之蟲。
- 「/* 刪掉下面這行不知道為什麼就會當掉 */」是永遠不滅的。
- 覺得「這什麼沒可讀性的爛程式！」時，常常是自己以前寫出來的程式碼。
- 「誰說程式設計師就一定熟電腦的」
- 使用手冊是需要的人不會讀它，而不需要的人會去讀的神祕讀物。
- 無論有多奇怪，只要符合規格就是滿分。無論如何完美，只要不符合規格就是零分。
- 我前方沒有規格，bug在我身後形成。(譯注：高村光太郎《道程》的名句 ─ 我前方沒有道路，路在我身後形成。)
- 專業不是努力於辦不到的工作，而是事前能夠判斷工作辦不到。
- 把勞基法當作是別國的法律就對了。
- 當你有「啊，加上這功能吧」的念頭時，還是不要想太多，早點去睡結果會比較好。
- 狀況總在週末來臨。
- 「責任」不是該負的人要負的，而是要負的人被逼著負的。
- 看到別家公司寫的程式碼，就知道客戶有多麼被看不起，然後自己得到了勇氣。
-
老闆是bug。
- 程式設計師的價值決定在寫了多少程式碼，程式設計師的技能決定在讀了多少程式碼。
- 熟悉程式語言不表示就會寫軟體。
- 熟悉程式語言軟體會寫得更慢。
- 機器感受到你的著急，所以他壞了。
- 程式設計師就算有愛，也不能愛上程式設計，因為程式有讓人墮入地獄的力量。
- 程式設計師重視過程，客戶重視結果，所以永遠是兩條平行線。
- 為了解決問題而最初想出來的點子，通常都有一些問題。
- 發現問題如何解決不是最重要的，發現哪裡是問題比較重要。
- 除錯，是喚醒沉睡錯誤的儀式
- 檢查後如果沒找到任何bug，一定是檢查有出錯。
- 就像SE所說的「辦得到」往往不可信，PG說的「辦不到」也不可信。
- 如果bug十年都沒人發現，就不要理他。去解掉它的話，不出半年就會被人當作bug了。
- 想個好的變數名稱比想演算法還花時間。
- 要在水面上行走、要照規格開發軟體都很簡單。如果能固定不動的話。
- 別相信手冊！相信我！
- 還沒付錢的，不是客戶。 已經付清的，也不是客戶。
- 不知道自己在修什麼的維修員。
- try-catch 然後 return null。～推卸責任～
- 客戶的抱怨認真地（約兩時間左右）聽就對了。這樣一來客戶的問題就可以說是解決一半了。也就是程式就不用改了。
- bug 是不會看臉色的。
- 昨天的自己是今天的敵人。
- SE的沉默代表著進度順暢的安心，PG的沉默代表著進度空白的慘叫。
- 業務的幸福是技術者的不幸。
- 接受「口頭規格」的開發案，就好像開一張空白支票給別人一樣。
- 這不叫更改規格。因為打從一開始就沒有規格存在。
- 程式這檔事，總是會有「難以置信」的事情發生。
- 程式設計師這種人，總是會寫出「難以置信」的程式碼。
- 而「難以置信」的程式碼，不知道為什麼常常跑得很好。
- 要證明 bug 不是自己的責任，往往比修好這個 bug 更花時間。
- bug 是會認人的。兩個人在一起明明很大方的，更多人來看時就躲起來了。
- 程式的養分來自於程式設計師的鮮血。
- 不知道為什麼會動的東西，OS程式設計師會在下一版讓他動。不知道為什麼會動的東西，開源程式設計師會在下一版捨棄它。不知道為什麼會動的東西，週日程式設計師會嘗試在下一版讓它動，結果膩了而放置。
- 當程式的原始碼規模超過臨界點，就會離開程式設計師的手，擁有自己的意志。
- 直接看程式碼，比看英文的註解好懂多了。
- 要求「功能要有彈性」的客戶，往往思考都沒有彈性。
- 程式的字典裡沒有「不可能」，但程式設計師有。
- 沒被發現的 bug，就不是 bug！