爪哇學校的危害 - The Perils of JavaSchools
有些小孩高中就在自己的Apple II上，用BASIC寫出很棒的乒乓遊戲。當這些孩子上大學修CompSci 101(一門資料結構的課程)，接觸指標這玩意之後，轟！他們的大腦馬上被炸成一堆豆腐渣，接下來都跑去修政治學，因為法學院似乎是個更好的主意。我看過CS科系退學率的各種數字，通常介於40%到70%之間。大學當局通常認視之為浪費，我則認為這是必要的排除手段，讓那些往後無法樂於編程職業或因此成功的人及早出局。
對許多年輕的CS學生來說，另一個難題是教授functional programming(包括遞迴編程在內)的課程。MIT對這些課程的要求很高，不但創造了必修課程(6.001)，還編寫出一本教科書(Abelson & Sussman的Structure and Interpretation of Computer Programs)，被數十甚至數百所一流CS學校拿來作為CS入門教材。
不瞭解function programming，就無法發明MapReduce這個讓Google具備驚人擴充性的演算法。Map跟Reduce是從Lisp和function programming來的。修過相當於6.001編程課程的人，如果還記得純functional programs沒有什麼副作用，不會影響並行的函式，因此可以輕易地平行化同步處理。在他們回想之際，MapReduce實是是顯而易見的演算法。Google發明了MapReduce而微軟沒有，這個事實可以解釋為何當微軟仍在嘗試讓基本搜尋功能能運作時，Google已經進到下個領域：建立Skynet這個世界上最大的平行處理超級電腦，我不認為微軟真正瞭解他們在這波競爭中落後了多少。
2014年3月17日 星期一
利誘管理法 - The Econ 101 Management Method
利誘管理法 - The Econ 101 Management Method
一個大的問題是：這方法會導致內在動機被外在動機取代掉。
人們將會傾向去尋找局部的最大獲益，他們會找到一些方法，去尋求最佳化某些你正獎勵他們的特殊事情，而不是完成你真正意圖要達成的事。
當你使用利誘管理法時，你等於在鼓勵開發者玩弄制度。
假定你決定獎賞寫出最少臭蟲的開發者，那麼當測試人員要回報一個臭蟲時，就成了大問題了，開發著通常會說服測試員這並不是真的臭蟲；或者測試員會同意，在回報給臭蟲管理系統之前，先非正式地提報臭蟲給開發人員，那麼現在就沒有人會使用臭蟲管理系統啦，雖然記錄中的臭蟲數量降低，但實際的數量並沒有任何改變。
開發者在這方面可是相當有天分的，無論你想要測量什麼，他們總是可以找到方法最大化此數值，而你永遠也無法獲得真正想要的東西。
一個大的問題是：這方法會導致內在動機被外在動機取代掉。
人們將會傾向去尋找局部的最大獲益，他們會找到一些方法，去尋求最佳化某些你正獎勵他們的特殊事情，而不是完成你真正意圖要達成的事。
當你使用利誘管理法時，你等於在鼓勵開發者玩弄制度。
假定你決定獎賞寫出最少臭蟲的開發者，那麼當測試人員要回報一個臭蟲時，就成了大問題了，開發著通常會說服測試員這並不是真的臭蟲；或者測試員會同意，在回報給臭蟲管理系統之前，先非正式地提報臭蟲給開發人員，那麼現在就沒有人會使用臭蟲管理系統啦，雖然記錄中的臭蟲數量降低，但實際的數量並沒有任何改變。
開發者在這方面可是相當有天分的，無論你想要測量什麼，他們總是可以找到方法最大化此數值，而你永遠也無法獲得真正想要的東西。
讓你的履歷有可讀性 - Getting Your Résumé Read
讓你的履歷有可讀性 - Getting Your Résumé Read
大量散發的垃圾履歷，或是任何顯示你正在申請100個職缺的跡象，都只是讓你看起來自暴自棄而更使你顯得不夠格。你想讓自己看起來像一個搶手人才，正在決定要去那裡工作，因為你夠聰明可以在這方面做個選擇，所以你只需要申請一或兩個職位。
一封顯示你知道公司業務的個人化求職信是很有幫助的，表示你很在乎這個工作，值得給予一次面試機會。
我們真正尋找的是有熱情而且在任何他們想做的事上都會成功的人。我們喜歡對軟體有熱情的人。對我們來說，十幾歲時就寫出共享軟體是個跟進麻省理工學院一樣好的指標。這是你的生命故事，而在你申請工作時多半已經來不及改變了。
大量散發的垃圾履歷，或是任何顯示你正在申請100個職缺的跡象，都只是讓你看起來自暴自棄而更使你顯得不夠格。你想讓自己看起來像一個搶手人才，正在決定要去那裡工作，因為你夠聰明可以在這方面做個選擇，所以你只需要申請一或兩個職位。
一封顯示你知道公司業務的個人化求職信是很有幫助的，表示你很在乎這個工作，值得給予一次面試機會。
我們真正尋找的是有熱情而且在任何他們想做的事上都會成功的人。我們喜歡對軟體有熱情的人。對我們來說，十幾歲時就寫出共享軟體是個跟進麻省理工學院一樣好的指標。這是你的生命故事，而在你申請工作時多半已經來不及改變了。
2014年3月16日 星期日
開發抽象層 - The Development Abstraction Layer
開發抽象層 - The Development Abstraction Layer
程式員的工作層次（比方說，Emacs）實在太過於抽象了，抽象到做不了生意。在抽象層工作的軟體開發者，還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。
桃莉巴頓（Dolly Parton）是在”唱好歌”那一個層次的，她也需要一個龐大的實作層，來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。
任何成功的軟體公司都會包括薄薄一層的開發者，這些開發者散佈在巨大管理組織抽象層之上建立軟體。這個抽象層存在的目的，只是為了建立一種假象，讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫，程式碼的簽入、除錯等等)，就是建立軟體產品並將之引入市場的一切。
這一點讓我得出本文最關鍵的重點：
身為軟體團隊經理，你的第一要務是建立開發抽象層。
大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。
在命令式的作法中，經理/團隊領隊會找出公司的目標，然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行，直到最後某個在最底層的人實際做事為止。在這種模式之下，程式員就是機器中的一根齒輪牙：一個執行管理階層命令中某一部份的打字員。
對一家軟體公司而言，管理的第一要務就是替程式員建立那樣的抽象層。
如果某個程式員正為椅子壞掉而操心，或是因為等Dell送新電腦來閒置，表示這個抽象層已經有了裂縫。
把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題，就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動，維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼，不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭，整隊人就會完全協調演出，讓程式員能把遊艇的細節全部抽象掉，只要管速度和方向，以及午餐要吃些什麼。
最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇，我們服務遊艇，我們就是遊艇本身，不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層，讓他們能創造出偉大的程式，再讓那些程式抵達能因而獲益的客戶手中。
程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器，必須去採購、安裝、備份，還要配置不斷電系統；伺服器會產生很多熱，表示你得準備一個有額外空調的房間去放；而空調得連接到大樓外，表示大樓外牆外面要裝一個80磅的風扇；安裝這東西會讓屋主緊張，所以他們得帶自己的工程師來，協調要在哪裡安置空調設備(決策結果：要裝在往上到18樓的外牆上，可能是最不方便的位置)，而屋主也會拉律師進來，因為我們得付出許多才獲淮進行；然後當空調安裝人員出現了，還帶著有如芭比玩具組的吊索機具，讓我們的建築工頭緊張起來，不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel，譯註：著名玩具商)繫具爬出18樓窗外，於是有人得再把包商找來，搞清楚他們為什麼在施工12週後，會突然發現得為這該死空調再次修改合約，而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。
就你的團隊中的軟體開發者而言，這一切都必須被抽象化成只要在命令列鍵入svn commit。
這就是要有管理階層的原因。
管理階層就是為了那些沒有公司能避免的事，不過如果讓你的程式員為此而操心，那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎，這台一百英呎長的遊艇也算失敗了。
要讓一位程式員發揮最大的生產力，必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料，華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者，一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品，並讓程式員瞭解導致客服電話的問題，極具耐心的技術支援聖人、以及其他十幾位支援及行政人員，而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。
沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像，由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構，這全部的一切只是要在她唱歌時建立那種抽象性，好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作，就是提供最完美的抽象：那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌，其實是有個巨大的基礎結構讓這件事實現，不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。
===
由程式員驅動，在組織上讓程式員坐上駕駛座，同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。
程式員的工作層次（比方說，Emacs）實在太過於抽象了，抽象到做不了生意。在抽象層工作的軟體開發者，還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。
桃莉巴頓（Dolly Parton）是在”唱好歌”那一個層次的，她也需要一個龐大的實作層，來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。
任何成功的軟體公司都會包括薄薄一層的開發者，這些開發者散佈在巨大管理組織抽象層之上建立軟體。這個抽象層存在的目的，只是為了建立一種假象，讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫，程式碼的簽入、除錯等等)，就是建立軟體產品並將之引入市場的一切。
這一點讓我得出本文最關鍵的重點：
身為軟體團隊經理，你的第一要務是建立開發抽象層。
大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。
在命令式的作法中，經理/團隊領隊會找出公司的目標，然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行，直到最後某個在最底層的人實際做事為止。在這種模式之下，程式員就是機器中的一根齒輪牙：一個執行管理階層命令中某一部份的打字員。
對一家軟體公司而言，管理的第一要務就是替程式員建立那樣的抽象層。
如果某個程式員正為椅子壞掉而操心，或是因為等Dell送新電腦來閒置，表示這個抽象層已經有了裂縫。
把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題，就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動，維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼，不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭，整隊人就會完全協調演出，讓程式員能把遊艇的細節全部抽象掉，只要管速度和方向，以及午餐要吃些什麼。
最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇，我們服務遊艇，我們就是遊艇本身，不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層，讓他們能創造出偉大的程式，再讓那些程式抵達能因而獲益的客戶手中。
程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器，必須去採購、安裝、備份，還要配置不斷電系統；伺服器會產生很多熱，表示你得準備一個有額外空調的房間去放；而空調得連接到大樓外，表示大樓外牆外面要裝一個80磅的風扇；安裝這東西會讓屋主緊張，所以他們得帶自己的工程師來，協調要在哪裡安置空調設備(決策結果：要裝在往上到18樓的外牆上，可能是最不方便的位置)，而屋主也會拉律師進來，因為我們得付出許多才獲淮進行；然後當空調安裝人員出現了，還帶著有如芭比玩具組的吊索機具，讓我們的建築工頭緊張起來，不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel，譯註：著名玩具商)繫具爬出18樓窗外，於是有人得再把包商找來，搞清楚他們為什麼在施工12週後，會突然發現得為這該死空調再次修改合約，而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。
就你的團隊中的軟體開發者而言，這一切都必須被抽象化成只要在命令列鍵入svn commit。
這就是要有管理階層的原因。
管理階層就是為了那些沒有公司能避免的事，不過如果讓你的程式員為此而操心，那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎，這台一百英呎長的遊艇也算失敗了。
要讓一位程式員發揮最大的生產力，必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料，華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者，一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品，並讓程式員瞭解導致客服電話的問題，極具耐心的技術支援聖人、以及其他十幾位支援及行政人員，而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。
沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像，由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構，這全部的一切只是要在她唱歌時建立那種抽象性，好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作，就是提供最完美的抽象：那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌，其實是有個巨大的基礎結構讓這件事實現，不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。
===
由程式員驅動，在組織上讓程式員坐上駕駛座，同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。
2014年3月14日 星期五
開發人員完全指南 - A Field Guide to Developers
開發人員完全指南 - A Field Guide to Developers
程式員在組織中是怎麼被看待的？
他們是明星還是打字員？公司經理是由工程師或曾任程式員的人組成的嗎？開發者能乘坐頭等艙去參與研討會嗎？（我不在乎這是否像是在浪費錢，明星就該坐頭等艙，要逐漸習慣這樣的思維！）當他們飛抵機場準備來參與面試時，將會有輛轎車來接送呢？還是得自己想辦法到達公司？基於相同的背景條件下，開發者傾向於選擇將他們當成明星的組織。假若你們公司的執行長是個壞脾氣的銷售員，他不能理解為何這些嬌貴的開發人員會持續的爭取類似腕墊、大螢幕跟舒適椅子等等之類的東西，他們以為自己是誰呀？那麼你的公司或許需要好好的調整態度，如果你不尊重他們，你將永遠無法獲得優秀的開發人員。
他們的同事是哪些人？
程式員在面試的那天還會密切注意他們所遇見的任何人。他們友善嗎？更重要的是：他們都聰明機靈嗎？我曾經在Bellcore暑期實習過，我遇到的每個人都一遍又一遍地告訴我相同的事：能遇到這兒的人們是他們在Bellcore工作時最美好的事。
這告訴我們，不要讓無法駕馭、怪脾氣的開發人員參與任何面試活動，相反的，記得找具有親和的、社交能力強、個性溫和等特質的人一起參與。隨時提醒自己，當你的求職者們回到家並且要決定到哪兒上班時，若是他在你的公司遇到的每個人都是陰沈憂鬱地，則他們絕不會有正面印象。
另外，原本Fog Creek公司預想的徵人規則（這概念是從微軟偷來的）為「聰明、可將事情做好」，但就在我們正式讓公司營運之前，我們理解到還應該加上第三個規則：「不要討人厭的怪喀（譯註：jerk,粗魯、不顧別人感受、讓人厭惡的人）」。回想起來，想在微軟獲得一份工作，不是怪喀向來不是個必要條件；雖然我很肯定他們會客套地說：能對他人友善是件重要的事，但真實情況為：他們絕不會只因某人惹人嫌就開除掉他，事實上，當個怪喀有時還會是個進入高階管理階層的先備條件。從管理角度來看這似乎是無害的，但從招募的角度來看卻是有害的：有人願意在一家容忍怪喀的公司上班呢？
程式員在組織中是怎麼被看待的？
他們是明星還是打字員？公司經理是由工程師或曾任程式員的人組成的嗎？開發者能乘坐頭等艙去參與研討會嗎？（我不在乎這是否像是在浪費錢，明星就該坐頭等艙，要逐漸習慣這樣的思維！）當他們飛抵機場準備來參與面試時，將會有輛轎車來接送呢？還是得自己想辦法到達公司？基於相同的背景條件下，開發者傾向於選擇將他們當成明星的組織。假若你們公司的執行長是個壞脾氣的銷售員，他不能理解為何這些嬌貴的開發人員會持續的爭取類似腕墊、大螢幕跟舒適椅子等等之類的東西，他們以為自己是誰呀？那麼你的公司或許需要好好的調整態度，如果你不尊重他們，你將永遠無法獲得優秀的開發人員。
他們的同事是哪些人？
程式員在面試的那天還會密切注意他們所遇見的任何人。他們友善嗎？更重要的是：他們都聰明機靈嗎？我曾經在Bellcore暑期實習過，我遇到的每個人都一遍又一遍地告訴我相同的事：能遇到這兒的人們是他們在Bellcore工作時最美好的事。
這告訴我們，不要讓無法駕馭、怪脾氣的開發人員參與任何面試活動，相反的，記得找具有親和的、社交能力強、個性溫和等特質的人一起參與。隨時提醒自己，當你的求職者們回到家並且要決定到哪兒上班時，若是他在你的公司遇到的每個人都是陰沈憂鬱地，則他們絕不會有正面印象。
另外，原本Fog Creek公司預想的徵人規則（這概念是從微軟偷來的）為「聰明、可將事情做好」，但就在我們正式讓公司營運之前，我們理解到還應該加上第三個規則：「不要討人厭的怪喀（譯註：jerk,粗魯、不顧別人感受、讓人厭惡的人）」。回想起來，想在微軟獲得一份工作，不是怪喀向來不是個必要條件；雖然我很肯定他們會客套地說：能對他人友善是件重要的事，但真實情況為：他們絕不會只因某人惹人嫌就開除掉他，事實上，當個怪喀有時還會是個進入高階管理階層的先備條件。從管理角度來看這似乎是無害的，但從招募的角度來看卻是有害的：有人願意在一家容忍怪喀的公司上班呢？
求職信排序 - Sorting Resumes
求職信排序 - Sorting Resumes
熱情。 我們尋找求職者對電腦充滿熱情與真正喜歡寫程式的證據.
典型的證據是：
1. 電腦相關工作或寫程式的經驗可以回溯到年紀很小的時候. 偉大的程式設計師很可能花一個暑假在電腦營，或為他的牙醫叔叔建立一個線上預約系統，而不是在香蕉共和國(註：成衣連鎖店)打工折衣服。
2. 課外活動. 喜歡寫程式的人通常會利用閒暇時間投入他自己的程式計畫(或是在開放源碼的專案中有所貢獻).
3. 在他們的求職信上，說明他們如何的被電腦程式的結構與闡釋感動落淚
英文。對我們來說用英文技巧來評分履歷是一個難以下的決定，因為電腦程式設計是不會說英文的移民一樣可以做的好的一門領域。與程式設計師工作的多年經驗教會我，能清楚地溝通他們的想法的程式設計師遠比只能跟編譯器溝通的程式設計師更加有效。為程式寫文件是很關鍵的，撰寫其他人能審閱的規格與技術設計文件也是關鍵的，甚至對那些你們只是坐著討論如何做較佳的會議也是關鍵的：對解釋想法有困難的聰明程式設計師無法提供更多貢獻。在這個類別，我們也只考慮履歷是否清爽易懂。一個充斥文法錯誤的無組織履歷只會啟動一個大紅標幟：這是一個思想毫無組織的人或一般的懶人；這對許多工作來說也許沒關係但是對軟體開發者來說不行。特別是我們常常完全剔除充滿英文錯誤的履歷。就算對一個非英文母語的人來說，找一個人檢查你的履歷也不是困難的事，這件事也不做常表示你對你做的事非常缺乏對品質的關心。.
他們花時間認識 Fog Creek 並寫一篇為我們量身訂做的求職信表示他們對自己的能力有很大的信心，所以他們只申請少數的職缺，而不是寄一大堆給上千家公司。同時發出一堆的履歷是絕望的徵兆。更重要的是，一個量身訂做的求職信是一個徵兆：如果我們真的錄取這個應徵者，他們很可能會接受。這增進我們的投資報酬率。如果我只有夠面試六個人的時間，面試者其他條件均相同，我較願意面試六個真的想要為 Fog Greek 工作的人，不是一般也同時應徵其他工作的聰明人。
記得這件事真的是非常非常重要：
這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。記得這件事真的是非常非常重要：這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。
熱情。 我們尋找求職者對電腦充滿熱情與真正喜歡寫程式的證據.
典型的證據是：
1. 電腦相關工作或寫程式的經驗可以回溯到年紀很小的時候. 偉大的程式設計師很可能花一個暑假在電腦營，或為他的牙醫叔叔建立一個線上預約系統，而不是在香蕉共和國(註：成衣連鎖店)打工折衣服。
2. 課外活動. 喜歡寫程式的人通常會利用閒暇時間投入他自己的程式計畫(或是在開放源碼的專案中有所貢獻).
3. 在他們的求職信上，說明他們如何的被電腦程式的結構與闡釋感動落淚
英文。對我們來說用英文技巧來評分履歷是一個難以下的決定，因為電腦程式設計是不會說英文的移民一樣可以做的好的一門領域。與程式設計師工作的多年經驗教會我，能清楚地溝通他們的想法的程式設計師遠比只能跟編譯器溝通的程式設計師更加有效。為程式寫文件是很關鍵的，撰寫其他人能審閱的規格與技術設計文件也是關鍵的，甚至對那些你們只是坐著討論如何做較佳的會議也是關鍵的：對解釋想法有困難的聰明程式設計師無法提供更多貢獻。在這個類別，我們也只考慮履歷是否清爽易懂。一個充斥文法錯誤的無組織履歷只會啟動一個大紅標幟：這是一個思想毫無組織的人或一般的懶人；這對許多工作來說也許沒關係但是對軟體開發者來說不行。特別是我們常常完全剔除充滿英文錯誤的履歷。就算對一個非英文母語的人來說，找一個人檢查你的履歷也不是困難的事，這件事也不做常表示你對你做的事非常缺乏對品質的關心。.
他們花時間認識 Fog Creek 並寫一篇為我們量身訂做的求職信表示他們對自己的能力有很大的信心，所以他們只申請少數的職缺，而不是寄一大堆給上千家公司。同時發出一堆的履歷是絕望的徵兆。更重要的是，一個量身訂做的求職信是一個徵兆：如果我們真的錄取這個應徵者，他們很可能會接受。這增進我們的投資報酬率。如果我只有夠面試六個人的時間，面試者其他條件均相同，我較願意面試六個真的想要為 Fog Greek 工作的人，不是一般也同時應徵其他工作的聰明人。
記得這件事真的是非常非常重要：
這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。記得這件事真的是非常非常重要：這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結，不論如何，重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試，然後決定他們是否值得錄取。
Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity
Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity
如果你問我並讓我偏私的回答，我會說除非有個程式師掌舵，否則沒有軟體公司會成功的。到目前為止的證據都可以支持我。
不過這些要命的錯誤中有許多也是程式師搞出來的。Netscape重寫瀏覽器而不去改善原有的程式碼庫，這個不朽的神經病決定花了他們好幾個年的Internet時間，在這期間他們的佔有率由大約九成掉到4%左右，而這是程式師的點子。當然啦，該公司裡面非技術又無經驗的管理階層完全不知道這為什麼是個爛點子。還是有很多程式師為Netscape徹底重寫辯解。「舊的程式真的很爛耶，約耳！」是，嗯哼，這種程式師應該因熱愛乾淨的程式而被讚賞，不過絕對要禁止他們接近任何商業決策100呎的範圍內，因為對他們來說，乾淨的程式碼顯然比讓軟體出貨重要多了。
所以我會對Rick稍微讓步地說，如果你想要在軟體業成功，必須有一個完全瞭解並熱愛程式設計的管理團隊。不過這個團體也必須瞭解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易，不過只有這樣才能避免這些被Rick親切地列在書中的錯誤。所以讀吧，笑一笑。如果你的公司是某位豬頭在經營，就把履歷整理一下開始在Redmond(譯註：微軟公司所在)找房子吧。
如果你問我並讓我偏私的回答，我會說除非有個程式師掌舵，否則沒有軟體公司會成功的。到目前為止的證據都可以支持我。
不過這些要命的錯誤中有許多也是程式師搞出來的。Netscape重寫瀏覽器而不去改善原有的程式碼庫，這個不朽的神經病決定花了他們好幾個年的Internet時間，在這期間他們的佔有率由大約九成掉到4%左右，而這是程式師的點子。當然啦，該公司裡面非技術又無經驗的管理階層完全不知道這為什麼是個爛點子。還是有很多程式師為Netscape徹底重寫辯解。「舊的程式真的很爛耶，約耳！」是，嗯哼，這種程式師應該因熱愛乾淨的程式而被讚賞，不過絕對要禁止他們接近任何商業決策100呎的範圍內，因為對他們來說，乾淨的程式碼顯然比讓軟體出貨重要多了。
所以我會對Rick稍微讓步地說，如果你想要在軟體業成功，必須有一個完全瞭解並熱愛程式設計的管理團隊。不過這個團體也必須瞭解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易，不過只有這樣才能避免這些被Rick親切地列在書中的錯誤。所以讀吧，笑一笑。如果你的公司是某位豬頭在經營，就把履歷整理一下開始在Redmond(譯註：微軟公司所在)找房子吧。
雙元文化主義 - Biculturalism (Windons, Unix)
雙元文化主義 - Biculturalism
Unix文化重視對其他程式師有用的程式，而Windows文化重視對非程式師有用的程式。
--
我們寫程式究竟是為程式師還是為了一般使用者？除了這個問題之外其他的都只是詮釋。
--
因為可以進入程式庫除錯所以Unix比較好。因為張阿姨可以看到提示確認她的電子郵件真的送出去了，所以Windows比較好。事實上沒有誰比誰更好，他們只是擁有的價值不同：Unix的核心價值是製作有助於其他程式師的東西，而Windows則把製作有助於張阿姨的事視作核心價值。
----
Raymond說「典型的Unix文件會寫得簡潔而完整...這種風格假設讀者夠積極，可以推導未寫出的推論，並且有自信信任這些推導。小心的閱讀每一個字，因為一件事很少會講兩遍。」天啊，我認為他其實是在教年輕的程式師寫出更不人性的man說明文件。
這對一般使用者而言是絕對行不通的。雖然Raymond可能說這是「過於簡化的屈就」，不過Windows文化瞭解一般使用者不讀文件，即使不得不看也是愈少愈好，因此你必須不斷重複的解釋... 事實上在良好的Windows說明檔中，必須每個主題都能讓一般讀者直接看懂，不必先看懂其他任何的說明主題。
----
Unix的程式文化格外重視可由命令列呼叫的程式，這種程式可以用參數控制各種動作，其輸出可以擷取成一般機器可讀的純文字格弋。這種程式之所以會被重視式，是因為可以讓其他程式師輕易地整合進別的程式或較大的軟體系統中。舉個很小的例子，Unix文化中有一個Raymond稱之為「沈默是金」的核心價值，是說當程式成功地完成你所交付的事時應該不要有任何輸出。不管是在命令列輸入300個字元的命令建立檔案系統，還是建立並安裝了一套複雜的軟體，或是把載人火箭送到月球，全部都一樣。只要成功執行就不要有任何輸出。使用者看到下一個命令列提示就會推論一切正常。
由於你是為其他程式師寫程式，所以這才會是Unix文化的重要價值。就如同Raymond所說的：「喋喋不休的程式不太能和其他程式好好合作。」 相較之下在Windows文化中是為張阿姨而寫程式的，而張阿姨搞不清楚程式是因為執行成功而沒有任何輸出，還是因為出錯了所以無法顯示任何訊息，或是因為誤解你的要求而沒有輸出。
同樣的狀況，Unix文化欣賞保持文字介面的程式。他們不是很喜歡圖型介面，不過在純文字介面程式上漂亮地塗一層GUI口紅可以例外，另外他們也不喜歡二位元檔案格式。因為文字介面比較好用程式控制，而圖型介面除非提供其他機制(如內建腳本語言)，否則幾乎不可能用程式控制。我們在這裡又再次看到，Unix文化重視有助於其他程式師的程式，而這一點很少會是Windows程式設計的目標。
Unix文化重視對其他程式師有用的程式，而Windows文化重視對非程式師有用的程式。
--
我們寫程式究竟是為程式師還是為了一般使用者？除了這個問題之外其他的都只是詮釋。
--
因為可以進入程式庫除錯所以Unix比較好。因為張阿姨可以看到提示確認她的電子郵件真的送出去了，所以Windows比較好。事實上沒有誰比誰更好，他們只是擁有的價值不同：Unix的核心價值是製作有助於其他程式師的東西，而Windows則把製作有助於張阿姨的事視作核心價值。
----
Raymond說「典型的Unix文件會寫得簡潔而完整...這種風格假設讀者夠積極，可以推導未寫出的推論，並且有自信信任這些推導。小心的閱讀每一個字，因為一件事很少會講兩遍。」天啊，我認為他其實是在教年輕的程式師寫出更不人性的man說明文件。
這對一般使用者而言是絕對行不通的。雖然Raymond可能說這是「過於簡化的屈就」，不過Windows文化瞭解一般使用者不讀文件，即使不得不看也是愈少愈好，因此你必須不斷重複的解釋... 事實上在良好的Windows說明檔中，必須每個主題都能讓一般讀者直接看懂，不必先看懂其他任何的說明主題。
----
Unix的程式文化格外重視可由命令列呼叫的程式，這種程式可以用參數控制各種動作，其輸出可以擷取成一般機器可讀的純文字格弋。這種程式之所以會被重視式，是因為可以讓其他程式師輕易地整合進別的程式或較大的軟體系統中。舉個很小的例子，Unix文化中有一個Raymond稱之為「沈默是金」的核心價值，是說當程式成功地完成你所交付的事時應該不要有任何輸出。不管是在命令列輸入300個字元的命令建立檔案系統，還是建立並安裝了一套複雜的軟體，或是把載人火箭送到月球，全部都一樣。只要成功執行就不要有任何輸出。使用者看到下一個命令列提示就會推論一切正常。
由於你是為其他程式師寫程式，所以這才會是Unix文化的重要價值。就如同Raymond所說的：「喋喋不休的程式不太能和其他程式好好合作。」 相較之下在Windows文化中是為張阿姨而寫程式的，而張阿姨搞不清楚程式是因為執行成功而沒有任何輸出，還是因為出錯了所以無法顯示任何訊息，或是因為誤解你的要求而沒有輸出。
同樣的狀況，Unix文化欣賞保持文字介面的程式。他們不是很喜歡圖型介面，不過在純文字介面程式上漂亮地塗一層GUI口紅可以例外，另外他們也不喜歡二位元檔案格式。因為文字介面比較好用程式控制，而圖型介面除非提供其他機制(如內建腳本語言)，否則幾乎不可能用程式控制。我們在這裡又再次看到，Unix文化重視有助於其他程式師的程式，而這一點很少會是Windows程式設計的目標。
約耳測試：邁向高品質的12個步驟 - The Joel Test: 12 Steps to Better Code
約耳測試：邁向高品質的12個步驟 - The Joel Test: 12 Steps to Better Code
約耳測試 (Joel Test)
你有使用原始碼控制系統嗎？
你能用一個步驟建出所有結果嗎？
你有沒有每天都重新編譯建立(daily builds)嗎？
你有沒有問題追蹤資料庫(bug database)？
你會先把問題都修好之後才寫新的程式嗎？
你有一份最新的時程表嗎？
你有規格嗎？
程式人員有沒有安靜的工作環境？
你有沒有用市面上最好的工具？
你有沒有測試人員？
有沒有在面試時要求面試對象寫程式？
有沒有做走廊使用性(hallway usability)測試？
約耳測試 (Joel Test)
你有使用原始碼控制系統嗎？
你能用一個步驟建出所有結果嗎？
你有沒有每天都重新編譯建立(daily builds)嗎？
你有沒有問題追蹤資料庫(bug database)？
你會先把問題都修好之後才寫新的程式嗎？
你有一份最新的時程表嗎？
你有規格嗎？
程式人員有沒有安靜的工作環境？
你有沒有用市面上最好的工具？
你有沒有測試人員？
有沒有在面試時要求面試對象寫程式？
有沒有做走廊使用性(hallway usability)測試？
7.你有規格嗎？
寫規格像用牙線：大家都同意這是好事，卻沒有人真的在做。
我不知道為什麼，或許是因為大多數程式人員都討厭寫文件吧。所以當全是程式人員的團體面對問題時，自然傾向用程式碼而非文件來表示答案。他們寧願跳進去寫程式也不願先寫規格。
在設計階段發現問題時，只要改幾行就能輕易修正。等程式寫出來之後，修正的代價就高得多了，代價包含了情感(人們討厭拋棄程式碼)和時間，所以會抗拒修正問題。通常未依據規格製作的軟體最後的設計都很糟，而且進度完全無法控制。這似乎就是發生在Netscape上的問題。它的前四版變得一團亂，結果管理階層愚蠢地決定把程式丟掉重新開始。然後他們在Mozilla上又重蹈覆轍，造出了一個無法控制的怪物，而且耗了幾年才進入alpha測試階段
我的拿手方法是把程式人員送去上密集的寫作課程，讓他們變得不那麼排斥寫作，就可以解決這個問題。另一個方法是雇用聰明的專案經理來寫規格。不管用哪一種方法，你都應該強制執行「沒有規格不寫程式」這個簡單的規則。
2014年3月10日 星期一
不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers
不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers
1. 問題是懶惰的程式師弄出來的。
2. 我的軟體放在網路上。即使有問題也馬上就能修好。
3. 客戶會替我測試軟體。
4. 有資格可以勝任的人都不想做測試人員。
5. 我請不起測試人員！
1. 問題是懶惰的程式師弄出來的。
2. 我的軟體放在網路上。即使有問題也馬上就能修好。
3. 客戶會替我測試軟體。
4. 有資格可以勝任的人都不想做測試人員。
5. 我請不起測試人員！
給資訊科系學生的建議 - Advice for Computer Science College Students
給資訊科系學生的建議 - Advice for Computer Science College Students
修要寫大量程式的課
(前略)
這個故事的教訓是資訊科學並不等同於軟體開發。如果你真的非常幸運，你的學校可能會有一套合宜的軟體開發課程，不過大概是不會有的，因為精英學校認為技職教育和犯人改過自新計劃才需要教導實務技能。只不過是寫寫程式而已，到處都可以學。我們可是耶魯大學，身負鑄造未來世界領袖的重責大任。你覺得 16 萬美元的學費是讓你來學 while 迴圈的嗎？你以為這是什麼？某個在機場旅館舉辦的騙人 Java 研討會嗎？哼。
問題在於我們並沒有真正的專門軟體開發學校，所以如果你想當個程式師，可能還是得主修資訊科學。這是個好的主修學科，不過跟軟體開發是兩回事。
不過如果你幸運的話，可以在資訊科系找到很多密集寫程式的課程，就像你可以在歷史系找到很多能學會寫作的課一樣。這些是最好的課程了。如果你喜歡寫程式，修 lambda 演算或線性代數這種不碰電腦的課時，有些地方搞不懂不必難過。去找那些課程名稱有 Practicum 的 400 等級課程。這些課用這個拉丁文只是想弄個漂亮的課程名稱，好瞞過那些愛跩文的屁管理階層。
----
給資訊科學系學生的七個免費建議（物超所值哦）：
在畢業前學會寫作。
在畢業前學會C。
在畢業前學會個體經濟學。
不要因為非資訊課程無聊就放棄。
修要寫大量程式的課。
別擔心所有工作都會外流到印度。
不管你做什麼，去找個好的暑期實習工作。
接下來是解釋，除非你好騙到只因為我叫你做就去做。萬一你真的那麼天真，那就再來一個吧：8. 自尊心受損時要尋求專業援助。
修要寫大量程式的課
(前略)
這個故事的教訓是資訊科學並不等同於軟體開發。如果你真的非常幸運，你的學校可能會有一套合宜的軟體開發課程，不過大概是不會有的，因為精英學校認為技職教育和犯人改過自新計劃才需要教導實務技能。只不過是寫寫程式而已，到處都可以學。我們可是耶魯大學，身負鑄造未來世界領袖的重責大任。你覺得 16 萬美元的學費是讓你來學 while 迴圈的嗎？你以為這是什麼？某個在機場旅館舉辦的騙人 Java 研討會嗎？哼。
問題在於我們並沒有真正的專門軟體開發學校，所以如果你想當個程式師，可能還是得主修資訊科學。這是個好的主修學科，不過跟軟體開發是兩回事。
不過如果你幸運的話，可以在資訊科系找到很多密集寫程式的課程，就像你可以在歷史系找到很多能學會寫作的課一樣。這些是最好的課程了。如果你喜歡寫程式，修 lambda 演算或線性代數這種不碰電腦的課時，有些地方搞不懂不必難過。去找那些課程名稱有 Practicum 的 400 等級課程。這些課用這個拉丁文只是想弄個漂亮的課程名稱，好瞞過那些愛跩文的屁管理階層。
----
給資訊科學系學生的七個免費建議（物超所值哦）：
在畢業前學會寫作。
在畢業前學會C。
在畢業前學會個體經濟學。
不要因為非資訊課程無聊就放棄。
修要寫大量程式的課。
別擔心所有工作都會外流到印度。
不管你做什麼，去找個好的暑期實習工作。
接下來是解釋，除非你好騙到只因為我叫你做就去做。萬一你真的那麼天真，那就再來一個吧：8. 自尊心受損時要尋求專業援助。
大麥克對原味主廚 - Big Macs vs. The Naked Chef
大麥克對原味主廚 - Big Macs vs. The Naked Chef
1. 有些事需要天份才做得好。
2. 天份很難複製。
3. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
4. 結果所得到的產品品質很低。
麥克不太高興。他請了一個大型IT顧問公司來建立系統。他請的IT顧問都很無能，只會一直講「方法論(Methdology)」，花了幾百萬美元還做不好一樣東西。 還好麥克找到一位真正聰明又有天份的年輕程式師。這個年輕人只拿了20美元和一塊披薩，一天內就把整個系統架好了。麥克高興得不得了，就把年輕的程式師推薦給所有朋友。 年輕的程式師開始大賺銀子。不久工作就多到做不完，所以請了一堆人來幫忙。厲害的人股票選擇權要太多了，所以他決定請些更年輕剛畢業的程式師來「訓練」六星期。 問題是「訓練」並不真的能產生一致的結果，所以年輕的程式師就開始建立規則和流程希望產生更一致的結果。幾年下來規則手冊愈來愈厚，不久就變成後一套叫做「方法論」的六冊巨書。 過了幾年，當初的年輕程式師現在已經成為巨大無能的IT顧問，帶著一本「方法論」和一堆盲從方法論的手下。即使方法論行不通的時候這些人還是硬幹，因為他們根本不知道其他方法。何況他們也並不是真有才能的程式師，只是受過六星期訓練，好心的政治學科系畢業生而已。 而這個新的巨大無能IT顧問公司也開始陷入困境了。他們的客戶都很不高興。於是又出現另一個新興的天才程式師把客戶都搶光，然後整個循環又重來一遍。
這個故事的教訓是？小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。就我而言，有才華的廚師顯然不會樂於在麥當勞做漢堡，原因正是麥當勞的規則。是否如此IT顧問才如此吹噓他們的方法論呢？
1. 有些事需要天份才做得好。
2. 天份很難複製。
3. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
4. 結果所得到的產品品質很低。
麥克不太高興。他請了一個大型IT顧問公司來建立系統。他請的IT顧問都很無能，只會一直講「方法論(Methdology)」，花了幾百萬美元還做不好一樣東西。 還好麥克找到一位真正聰明又有天份的年輕程式師。這個年輕人只拿了20美元和一塊披薩，一天內就把整個系統架好了。麥克高興得不得了，就把年輕的程式師推薦給所有朋友。 年輕的程式師開始大賺銀子。不久工作就多到做不完，所以請了一堆人來幫忙。厲害的人股票選擇權要太多了，所以他決定請些更年輕剛畢業的程式師來「訓練」六星期。 問題是「訓練」並不真的能產生一致的結果，所以年輕的程式師就開始建立規則和流程希望產生更一致的結果。幾年下來規則手冊愈來愈厚，不久就變成後一套叫做「方法論」的六冊巨書。 過了幾年，當初的年輕程式師現在已經成為巨大無能的IT顧問，帶著一本「方法論」和一堆盲從方法論的手下。即使方法論行不通的時候這些人還是硬幹，因為他們根本不知道其他方法。何況他們也並不是真有才能的程式師，只是受過六星期訓練，好心的政治學科系畢業生而已。 而這個新的巨大無能IT顧問公司也開始陷入困境了。他們的客戶都很不高興。於是又出現另一個新興的天才程式師把客戶都搶光，然後整個循環又重來一遍。
這個故事的教訓是？小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。就我而言，有才華的廚師顯然不會樂於在麥當勞做漢堡，原因正是麥當勞的規則。是否如此IT顧問才如此吹噓他們的方法論呢？
工匠技藝 - Craftsmanship
工匠技藝 - Craftsmanship
這個故事的教訓是修正一個1%的問題可能會用掉500%的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成Fog Creek新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力，旁邊圍著鋁框，鋁框上每20公分就鑲有一顆螺絲。如果你仔細看照片，會發現每片門都會被鋁框整個包住，當門關起來時，兩片直框會併排在一起。雖然圖上看不出來，不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有2公釐。負責這件事的木匠很小心的測量，不過裝鋁框時門是放在地上，並不是等好門裝好再當場裝的。所以等到要把門裝上去時，才發現螺絲並沒有對齊。
這或許並不罕見;;我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後，要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐，所以不能直接在門上再鑽一個，可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正1%的問題會用掉500%工夫的例子，而且這也解釋了為何這世上很多人造物都是99%好而非100%完美。(不過建築師倒是不斷吹噓，說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)
這點出了軟體的一項特性，一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時，所有螺絲都會對得整整齊齊..當你做些很罕見的事時，應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況，而不光是讓主要的程式會動。即使要額外再花500%的力氣去處理1%的狀況也在所不惜。
工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉，不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界，因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言，這種工藝境界可以讓使用者高興並提供長期的競爭優勢，所以我願意花時間並正確地執行。請容忍我吧。
這個故事的教訓是修正一個1%的問題可能會用掉500%的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成Fog Creek新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力，旁邊圍著鋁框，鋁框上每20公分就鑲有一顆螺絲。如果你仔細看照片，會發現每片門都會被鋁框整個包住，當門關起來時，兩片直框會併排在一起。雖然圖上看不出來，不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有2公釐。負責這件事的木匠很小心的測量，不過裝鋁框時門是放在地上，並不是等好門裝好再當場裝的。所以等到要把門裝上去時，才發現螺絲並沒有對齊。
這或許並不罕見;;我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後，要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐，所以不能直接在門上再鑽一個，可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正1%的問題會用掉500%工夫的例子，而且這也解釋了為何這世上很多人造物都是99%好而非100%完美。(不過建築師倒是不斷吹噓，說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)
這點出了軟體的一項特性，一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時，所有螺絲都會對得整整齊齊..當你做些很罕見的事時，應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況，而不光是讓主要的程式會動。即使要額外再花500%的力氣去處理1%的狀況也在所不惜。
工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉，不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界，因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言，這種工藝境界可以讓使用者高興並提供長期的競爭優勢，所以我願意花時間並正確地執行。請容忍我吧。
墨菲定律發威的一週 - A Week of Murphy's Law Gone Wild
墨菲定律發威的一週 - A Week of Murphy's Law Gone Wild
差的系統可能表現完全正常，不過等相鄰的系統故障時就會出事。有過敏和背痛的人可能好幾個有都沒事，不過一患乾草熱打噴嚏就會背痛到不行。這種事在系統管理中到處都有。可以利用這種機會把所有問題一次修好。
幫你所有的PC都加裝RAID並且定期備份，不要使用EFS，要買很大的硬碟(這樣就永遠不必停下工作來升級)，另外要再次確認rdist的命令列選項。安裝導風管並且把水管隔熱做好。把你重要的伺服器移去安全的代管設施並且在辦公室改用Verizon的T1服務。
差的系統可能表現完全正常，不過等相鄰的系統故障時就會出事。有過敏和背痛的人可能好幾個有都沒事，不過一患乾草熱打噴嚏就會背痛到不行。這種事在系統管理中到處都有。可以利用這種機會把所有問題一次修好。
幫你所有的PC都加裝RAID並且定期備份，不要使用EFS，要買很大的硬碟(這樣就永遠不必停下工作來升級)，另外要再次確認rdist的命令列選項。安裝導風管並且把水管隔熱做好。把你重要的伺服器移去安全的代管設施並且在辦公室改用Verizon的T1服務。
約耳的程式師書櫃 - Book Reviews
約耳的程式師書櫃 - Book Reviews
Helplessness: On Depression, Development, and Death
Martin E. P. Seligman
良好UI設計之所以重要，是因為它會讓大家快樂。
如果你的UI設計良好，使用你的軟體的人就會比較快樂。
如果設計不良，他們就會不快樂。
這個講憂鬱症的書有什麼關係呢？是這樣的，當人們感覺無法控制自己的生命和環境時，
就會轉變成臨床上的憂鬱症。而Seligman這位先驅發現，對抗憂鬱已知最有效的非藥物療
法，就是鼓勵人們小幅地逐漸控制他們的環境。
Influence: The Psychology of Persuasion
Robert B. Cialdini
Robert B. Cialdini的經典作品Influence是另一本值得一讀再讀的書。慈善組織請求你捐款時幾乎都會在信封裡附一個「禮物」，比如印有你的地址的自黏標籤或是幾張空白賀卡。他們會送禮物給你是基於互惠的社會性原理；因為這樣你就會覺得要回饋一些東西。你也可能常常在電視購物頻道上聽過「快快快，數量有限！」這種台詞，聽到都沒感覺了。不過這種台詞是基於罕見(scarcity)原理，也就是你會自然地假設罕見的物品會比較值錢。業務員，行銷人員以及廣告主會運用這些手法以及其他技倆，影響人們進行某些行為。Cialdini出色的書中討論了影響其他人行為的科學與實務背後的心理學理論。你得趕快在他們進行之前先看這本書！
Helplessness: On Depression, Development, and Death
Martin E. P. Seligman
良好UI設計之所以重要，是因為它會讓大家快樂。
如果你的UI設計良好，使用你的軟體的人就會比較快樂。
如果設計不良，他們就會不快樂。
這個講憂鬱症的書有什麼關係呢？是這樣的，當人們感覺無法控制自己的生命和環境時，
就會轉變成臨床上的憂鬱症。而Seligman這位先驅發現，對抗憂鬱已知最有效的非藥物療
法，就是鼓勵人們小幅地逐漸控制他們的環境。
Influence: The Psychology of Persuasion
Robert B. Cialdini
Robert B. Cialdini的經典作品Influence是另一本值得一讀再讀的書。慈善組織請求你捐款時幾乎都會在信封裡附一個「禮物」，比如印有你的地址的自黏標籤或是幾張空白賀卡。他們會送禮物給你是基於互惠的社會性原理；因為這樣你就會覺得要回饋一些東西。你也可能常常在電視購物頻道上聽過「快快快，數量有限！」這種台詞，聽到都沒感覺了。不過這種台詞是基於罕見(scarcity)原理，也就是你會自然地假設罕見的物品會比較值錢。業務員，行銷人員以及廣告主會運用這些手法以及其他技倆，影響人們進行某些行為。Cialdini出色的書中討論了影響其他人行為的科學與實務背後的心理學理論。你得趕快在他們進行之前先看這本書！
程式設計領域的帕麥爾斯頓勳爵 - Lord Palmerston on Programming
程式設計領域的帕麥爾斯頓勳爵 - Lord Palmerston on Programming
所以當我們遇到某個只有NT 4.0才發生的怪問題時，我只花了三分鐘就解決了，因為我知道如何使用VMWare，而且我有一套用VMWare灌的乾淨NT 4.0機器，另外我也知道如何用Visual C++做遠端除錯，還知道可以由EAX暫存器知道函數的回傳值。完全沒接觸過這些東西的人要抓同一個問題，恐怕得花一個小時或更多的時間，不過我已經知道了很多很多「東西」，那些基本上是從1982年拿到我第一台IBM-PC和那本Norton書時就開始學的東西。
有漏洞的抽象表示我們面對一個直線上升的學習曲線：你可以用一星期學到每天工作所需知識的90%。不過其他10%可能得要好幾年才能補齊。有些人會說：「不管你要我做什麼，我都可以拿本書來就學會了。」真正有經驗的程式師超越這種人的地方就在這裡。如果你正在建立一個團隊，當然可以找一堆經驗較少的程式師用抽象工具製作出一大堆程式碼，不過如果少了經驗老到的人去做真正困難的事情，這個團隊是做不起來的。
程式設計有很多不同的世界，每個世界都需要大量的知識才能真正的精通。
所以當我們遇到某個只有NT 4.0才發生的怪問題時，我只花了三分鐘就解決了，因為我知道如何使用VMWare，而且我有一套用VMWare灌的乾淨NT 4.0機器，另外我也知道如何用Visual C++做遠端除錯，還知道可以由EAX暫存器知道函數的回傳值。完全沒接觸過這些東西的人要抓同一個問題，恐怕得花一個小時或更多的時間，不過我已經知道了很多很多「東西」，那些基本上是從1982年拿到我第一台IBM-PC和那本Norton書時就開始學的東西。
有漏洞的抽象表示我們面對一個直線上升的學習曲線：你可以用一星期學到每天工作所需知識的90%。不過其他10%可能得要好幾年才能補齊。有些人會說：「不管你要我做什麼，我都可以拿本書來就學會了。」真正有經驗的程式師超越這種人的地方就在這裡。如果你正在建立一個團隊，當然可以找一堆經驗較少的程式師用抽象工具製作出一大堆程式碼，不過如果少了經驗老到的人去做真正困難的事情，這個團隊是做不起來的。
程式設計有很多不同的世界，每個世界都需要大量的知識才能真正的精通。
2014年3月7日 星期五
在公司裡當個寫程式的工程師
http://mmdays.com/2013/12/22/be_a_programmer_in_company/
在公司裡當個寫程式的工程師，首先要能做到如下事項：用其專業知識，開發與設計新功能與產品；計劃、設計、撰寫與測試軟體系統，能符合需求；參與團隊開發專案，符合時程；維護既有產品；提出建議，改善既有流程；能解決煩雜的問題；在專案團隊裡，支持與協助新想法的實做與推廣；可以學習快速，在有限的時程完成重要的任務指派；能規劃工作的先後順序；能順暢地與無技術背景的人員溝通；在自己參與開發的產品上，可以預測並避免將發生的商業問題。在公司裡當個寫程式的工程師，想被公司當作不可替代的人，作為公司維護營運的要件，以上是基本要求。
在公司裡當個寫程式的工程師，首先要能做到如下事項：用其專業知識，開發與設計新功能與產品；計劃、設計、撰寫與測試軟體系統，能符合需求；參與團隊開發專案，符合時程；維護既有產品；提出建議，改善既有流程；能解決煩雜的問題；在專案團隊裡，支持與協助新想法的實做與推廣；可以學習快速，在有限的時程完成重要的任務指派；能規劃工作的先後順序；能順暢地與無技術背景的人員溝通；在自己參與開發的產品上，可以預測並避免將發生的商業問題。在公司裡當個寫程式的工程師，想被公司當作不可替代的人，作為公司維護營運的要件，以上是基本要求。
不想畢業就失業？這五件事你該越早做越好
http://www.thenewslens.com/post/26544/
但其實對企業來說，給一個完全沒經驗的人這樣的錢根本是不合理的。
他不知道你的工作表現如何，何況現今人人有大學念，
這張畢業證書也不能為你證明什麼。
對於你的老闆來說，你不是什麼頂尖人才，只是一個小菜菜而已。
---
這裡自私的定義是指所有的思考角度都從自己出發。簡單來說就是任何公司的好處都要拿
盡，自己的義務卻不願盡。很敢要求公司配合卻又不想被要求，覺得公司給你的都是應該
，你犯的錯也只是還好而已。自己永遠是對的，錯永遠是別人造成的。
這種態度，老闆們都請不起你啊。
2014年3月4日 星期二
Software design
http://en.wikipedia.org/wiki/Software_design
http://en.wikipedia.org/wiki/Software_design_pattern
http://en.wikipedia.org/wiki/Software_design_pattern
2014年3月3日 星期一
Android APP 上架流程
Android APP 上架流程
http://xyz.cinc.biz/2013/06/android-app.html
企業 Android App 上架 Google Play 軟體市場的流程說明
APP上架前相關準備工作
http://www.webmobi.com.tw/push-android-app-google-play-market/
Android 開發筆記 - APP 的上架與更新
http://blog.changyy.org/2012/08/android-app.html
http://xyz.cinc.biz/2013/06/android-app.html
企業 Android App 上架 Google Play 軟體市場的流程說明
APP上架前相關準備工作
http://www.webmobi.com.tw/push-android-app-google-play-market/
Android 開發筆記 - APP 的上架與更新
http://blog.changyy.org/2012/08/android-app.html
[Max的Android心得筆記] 安裝 Eclipse 教學
Max的Android心得筆記
http://imax-live.blogspot.tw/2012/11/install-android-eclipse.html
http://imax-live.blogspot.tw/2012/11/install-android-eclipse.html
2014年3月2日 星期日
抽象滲漏法則 - The Law of Leaky Abstractions
抽象滲漏法則 - The Law of Leaky Abstractions
所有重大的抽象機制在某種程式上都是有漏洞的。
例子: 下雨天時開車沒辦法開得和平常一樣快，雖然車上有擋風玻璃雨刷有頭燈有車頂還有暖氣，這些裝備應該是讓你可以忽略下雨這個事實(他們把天氣抽象化了)，不過看吧，你還是得擔心天雨路滑，有時候雨甚至會大到你看不遠，所以在只好慢慢地開，因為基於抽象滲漏法則，天氣永遠不能完全被抽象化。
抽象滲漏法則會造成問題的原因之一，是因為它說明了抽象機制並不真能照原構想簡化我們的生活。當我想訓練某人成為C++程式師時，最好能完全不教char*和指標運算，直接去學STL字串。問題是總有一天他們會寫出"foo" + "bar"這樣的程式然後看到怪事出現，於是我就得停下來教他們有關char*的事情。他們也可能會試著呼叫某個需要OUT LPTSTR參數的Windows API函數，於是又得把char*、指標、Unicode、wchar_t以及TCHAR含入檔搞懂，才會知道如何呼叫。而這些全都是漏洞。
抽象滲漏法則表示，當某人發明一套神奇的新程式產生工具，可以大幅提升效率等等，就會聽到很多人說：「應該先學會如何手動進行，然後才用這個神奇的工具來節省時間。」 程式產生工具假裝抽象掉某些東西，和其他所有抽象機制一樣都有漏洞，而唯一能適當處理漏洞的方法，就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然替我們節省了工作的時間，不過學習的時間是省不掉的。
而這一切都似非而是地表示，即使我們擁有愈來愈高階的程式設計工具，抽象化也做得愈來愈好，要成為一個純熟的程式師卻是愈來愈難了。
所有重大的抽象機制在某種程式上都是有漏洞的。
例子: 下雨天時開車沒辦法開得和平常一樣快，雖然車上有擋風玻璃雨刷有頭燈有車頂還有暖氣，這些裝備應該是讓你可以忽略下雨這個事實(他們把天氣抽象化了)，不過看吧，你還是得擔心天雨路滑，有時候雨甚至會大到你看不遠，所以在只好慢慢地開，因為基於抽象滲漏法則，天氣永遠不能完全被抽象化。
抽象滲漏法則會造成問題的原因之一，是因為它說明了抽象機制並不真能照原構想簡化我們的生活。當我想訓練某人成為C++程式師時，最好能完全不教char*和指標運算，直接去學STL字串。問題是總有一天他們會寫出"foo" + "bar"這樣的程式然後看到怪事出現，於是我就得停下來教他們有關char*的事情。他們也可能會試著呼叫某個需要OUT LPTSTR參數的Windows API函數，於是又得把char*、指標、Unicode、wchar_t以及TCHAR含入檔搞懂，才會知道如何呼叫。而這些全都是漏洞。
抽象滲漏法則表示，當某人發明一套神奇的新程式產生工具，可以大幅提升效率等等，就會聽到很多人說：「應該先學會如何手動進行，然後才用這個神奇的工具來節省時間。」 程式產生工具假裝抽象掉某些東西，和其他所有抽象機制一樣都有漏洞，而唯一能適當處理漏洞的方法，就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然替我們節省了工作的時間，不過學習的時間是省不掉的。
而這一切都似非而是地表示，即使我們擁有愈來愈高階的程式設計工具，抽象化也做得愈來愈好，要成為一個純熟的程式師卻是愈來愈難了。
測量 - Measurement
測量 - Measurement
軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。如果想懲罰產生問題的程式師來避免這個問題，就為他們創造了一個墮落的動機，讓他們努力隱藏問題，或者寫了程式卻不告訴測試人員，好讓測到的問題少一點。你是不可能贏的。
財星前500大公司執行長的報酬通常都是底薪加股票選擇權。股票選擇權通常價值數千萬或數億美元，相較之下底薪幾乎無關痛癢。結果執行長就會花招百出炒高股價，即使會毀掉公司或讓公司破產都在所不惜(就像這個月一直上頭條的新聞一樣)。即使股價只是暫時上升也照做不誤，因為他們會在高點賣掉。獎懲委員會的反應很慢，不過他們最新的好點子是要求執行長要一直持有股票，直到離開公司才能脫手。了不起啊，現在等於要他們短線炒高股價然後趕快走。同樣的，你也是不可能贏的。
油漆工Shlemiel演算法
油漆工Shlemiel的演算法。
Shlemiel是誰？他是下面這個笑話的主角：
Shlemiel得到一個在路上塗油漆的工作，他要漆在路中間的間斷分隔線。第一天他拿了一罐油漆去漆好了300碼的路。「做得真好！」他的老闆說「你手腳真快啊！」然後就給他一個銅板。
第二天Shlemiel只漆了150碼。「這樣啊，沒有昨天好，不過也還是很快。150碼也很了不起。」也給他一個銅板。
第三天Shlemiel只漆了30碼。「只有30碼而已！」老闆就哇哇大叫了。「這實在是無法接受！第一天你漆了十倍的長度耶！究竟怎麼回事啊？」
「我也沒辦法啊，」Shlemiel說「我每隔一天就離油漆罐愈來愈遠啊！」
訂閱：
文章 (Atom)