2014年5月6日 星期二

如何扮演程式經理的角色? - How to be a program manager

如何扮演程式經理的角色? - How to be a program manager


Scott Berkun,  Making Things Happen
Steve Krug, Don’t Make Me Think
Joel Spolsky, User Interface Design for Programmers
Dale Carnegie, How to Win Friends & Influence People


怎麼學習當個程式經理?

作為程式經理是一種學習:學習技術、了解人性、搞懂怎麼在組織政治裡有效率的做事。好的程式經理能把工程師的想法整合到設計裡,並像政治家一樣把人聚在一起並建立共識。當你在做這些事情的時候,可以讀一讀這些書:
Scott Berkun 的「Making Things Happen」是唯一一本內容涵蓋了程式經理所要做的事情的書。所以從這一本開始吧。Scott 曾經在 Internet Explorer 團隊擔任多年的程式經理。
程式經理的一大部分工作是設計使用者操作介面。首先可以讀 Steve Krug 的「Dont Make Me Think」,然後是我寫的「User Interface Design for Programmers」。
最後,我知道這聽起來很俗氣,不過 Dale Carnegie 1937 年寫的「How to Win Friends & Influence People」真的是的超棒的人際關係入門書。這是我所指定的在 Fog Creek 裡受訓的經理人要閱讀的第一本書。這些人一開始總是在私底下竊笑,不過大家在讀完之後都會愛上這本書。


2014年5月4日 星期日

找尋偉大開發者 - Finding Great Developers

 找尋偉大開發者 - Finding Great Developers  (翻譯中)


偉大的開發者,事實上,每個領域最優秀的人才,根本從來不曾出現在人力市場上。

平均來說,偉大的開發者在他們整個職業生涯裡,總共也許只會應徵四份工作。
優秀的大學畢業生會被與業界關係良好的教授拉進暑期實習,他們很早就拿到合約,從不用煩惱找工作的事兒。如果他們離開原本那家公司,通常去跟朋友合作創業,或跟著頂頭上司跳槽到另一家公司去,或者他們真的決定想要,例如,替Eclipse工作,只因為Eclipse很酷,所以他們去BEAIBMEclipse相關的工作,因為他們非常優秀,當然就拿到工作了。
如果你夠好運,真的真的很好運的話,他們會在公開的人力市場上露一次臉,他們的另一半決定要接受地點位於安克拉治(阿拉斯加的一個港口)的醫學實習,他們才會真的送出求職信到少數他們認為在安克拉治可以工作的地方。

但大部分時候來說,這些偉大的開發者(這幾乎成了贅詞),嗯,很偉大(好吧,這真是個贅詞),而且,未來的雇主通常很快的認識到這些人的偉大之處,意思是說,基本上他們想要就可以找到工作,所以他們實在不需要投一大堆履歷或申請一大堆工作。

這聽起來像你想要雇用的那種人嗎? 鐵定是的。


有個獲取潛在的傑出人才的好方法 -- 
在他們出現在人力市場上以前就先得到他們:從大學裡。

一些人力資源主管不愛雇用實習生。他們認為實習生尚未成熟且技能不足,在某種程度上這個想法並沒有錯。實習生不比資深員工來的有經驗。(真的嗎?)你需要在他們身上多投資一些,而且要花點時間讓他們上軌道。好消息是,在我們圈子裡,真正偉大的程式設計師通常從10歲開始寫程式。其他同年齡的小鬼們還在「踢足球」的同時(足球是許多不會寫程式的小鬼玩的遊戲,玩法涉及用腳踢一個叫做「足球」的球狀物體 -- 我知道這聽起來很怪)他們卻在老爸的工作室內試著編譯Linux Kernel呢。與其在操場上追逐女孩,他們在 Usenet上和網友論戰著程式語言若沒有 Haskell 風格的型別推斷是全然的墮落;與其在車庫裡練團,他們修改了韌體讓偷用未加密的無線網路頻寬的鄰居,看到的圖片會是上下顛倒的。姆哈哈哈!
所以,不像法律或醫學領域,軟體開發領域裡的學生們,在大二、大三時就已經是超「棒」的程式師了。

....
當動用到親自面談時,我們有很高的機會雇用這個人,該是啟動正式招聘的時候了。我們在機場碰面,並由穿著制服的轎車司機連同行李將他們送往市中心鬧區(可能是他們看過最豪華的)酒店。隨時有時尚名媛進出、別緻的衛浴裝飾可能是博物館的典藏展品,他們可能要花點時間在五星級酒店裡學著刷牙。我們在客房內留給他們一個包裹:一件T恤、Fog Creek員工寫的紐約必遊景點地圖、2005年實習生紀錄片DVD。房間內的DVD播放機放著前屆實習生的有趣畫面。
經過一天的面試,我們邀請這些學生留在紐約幾天免費遊覽(如果他們想看看這城市)然後再由豪華轎車接送機場飛回家鄉。
雖然只有三分之一的面試者通過這些階段到最後面對面的面試,但讓這些面試者有好的體驗是很重要的。
即使面試失敗回到校園,他們仍然會認為我們是個好公司,並告訴他們的朋友在大蘋果待的飯店有多豪華,增加他們同儕明年也申請實習的意願(儘管他們可能只想來紐約享受這趟豪華旅行)


軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)

 軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)

每個被雇用的人選都應該至少和六個人面談,六個人裡至少要有五位會和應徵者共事的人(也就是其他程式員而非經理)。你知道那種只靠幾位老鳥(salty)經理和應徵者面談,一試定生死的那種公司嗎?這些公司裡頭不會有非常優秀的工作人員。要瞞過一場面試實在太容易了,特別是由非程式員面試程式員時更是如此。

如果六次面談中有兩人認為對方不值得用,就不要錄取。這表示當你不打算錄用某位應徵者時,在兩次面談後就可以技術性地結束「整天」的面試,這並不算是壞事。不過為了避免流於殘酷,最好不要事先告訴對方要面談的次數。我還聽過有些公司允許任何一個面試官把人選刷掉。我覺得這有點太過頭了;對我來說,或許可以容許讓資深人員刷掉應徵者,不過不會只因某個新進人員不喜歡而否決。


軟體產業的變化太頻繁又太快,所以你需要那種任何編程工作都可以勝任的人。如果基於某種原因,你發現一個非常非常擅長SQL,但是完全無法學習其他主題的白痴學究,不錄用。否則就會就是拿長痛去換短痛。


錯失好人選比錄用不適合的人要好太多了。不對的人會耗用很多錢和精力,還會讓其他人浪費時間去修正所有的問題。錄用錯人要開除得花上好幾個,而且會非常的困難(當他們決定對簿公堂時更是格外麻煩)。在某些情況下也有可能完全無法開除任何人。不好的員工會破壞好員工的士氣。而且他們可能是個爛程式員,同時卻又是個真正的好人或是極度需要這個工作,所以你根本不忍心開除他們,不然就是一開除就會犯眾怒,或是其他種種的窘境。反正很慘就是了。
反過來說,如果你否決了一個好人選,我是指我認為有些地方不太公平,不過如果他們真的這麼聰明就不用擔心,他們有很多好的工作機會可以挑。別害怕會因為拒絕太多人而找不到人用。這在面談過程中並不是你的問題。當然找到好的人選非常重要。不過當你實際面試某人時,要假裝門外還有900個人排隊等著和你面試。不管優秀人選似乎有多麼難找,也不要降低你的標準。
好了,我還沒有告訴你最重要的部份:如何知道是否要錄用某人?
原則上很簡單。你要找的人必須聰明,而且能把事做完。

你要如何在面談中察覺聰明這回事呢?頭一個徵兆就是你不必再三地說明事情。對話會很流暢地進行。應徵者經常會說出某些很有見地有思想或是心思敏銳的話。所以面談的重點之一就在於建立情境,讓受試者能向你展示他有多麼聰明

愛吹牛的人是最差勁的面試官。這種人在面談時都在胡扯,應徵者只來得及說「是的,這實在是對極了,我衷心的同意你的看法。」吹牛專家什麼人都會錄用;他們認為應徵者一定很聰明,因為「他的想法和我很像!」

益智問答型的面試官是第二糟的。這種人認為聰明表示「知道很多事實」。他們只會問一堆瑣碎的編程問題,答對就加分。純粹好玩提一下世界上最爛的面試問題:「Oracle 8i裡的varcharvarchar2有何差別?」這是個爛問題。會知道這種芝麻小事的人和你真正想用的人完全不會有任何關聯。誰會在乎有什麼差別?你只要約15秒就可以在線上找到答案!記住,聰明並不等於「知道瑣碎問題的答案」。

總而言之,軟體團隊是要雇用有才華而非會某種特定技能的人。畢竟所有能用在工作上的特定技能,就技術而言都會在數年內過時,所以最好雇用能學習任何新技術的人,而不是此刻剛好知道如何讓JDBGMySQL資料庫溝通的傢伙。

不過大體來說,要深入瞭解一個人的方法就是讓他說話,要提出開放性的問題與難題。


2014年4月20日 星期日

卓越客戶服務的七步驟 - Seven steps to remarkable customer service

卓越客戶服務的七步驟 - Seven steps to remarkable customer service

建議吹掉灰塵

某個顧客抱怨鍵盤不會動。原因當然是因為沒有接線。如果你問他們線有沒有接好,「他們會覺得被侮辱,氣沖沖地說『當然接了!我像個白癡嗎?』而不去檢查。」
Chen的建議是「換一種說法『好,有時候接頭會有點灰塵而鬆掉。你可以把接頭拔下把灰吹掉再插回去嗎?』」
「然後他們就會爬到桌子下,發現自己忘了接線(或是插錯洞),就會吹一吹插回去然後回答『嗯,耶,這樣就好了,謝謝。』」

很多要求客戶進行某些檢查的動作都可以用這種方式表達。不要叫他們檢查某個設定,而是要他們把設定改掉再改回去,目的「只是要確定軟體有確實把設定存起來。」

讓錯的程式看得出錯 - Making Wrong Code Look Wrong (命名規範)

讓錯的程式看得出錯 - Making Wrong Code Look Wrong


我是故意用種類(kind)這個詞,因為Simonyi在他的文章中誤用了型別(type),結果好幾世代的程式師都誤解了他的意思。

如果你仔細讀Simonyi的文章,就會發現他所講的和我之前範例所用的命名規範是一樣的,
在我的範例中把us和s分別定義為不安全字串和安全字串。這兩者的型別都是字串。

如果你把某種字串指派另一種,編譯器並不會給任何警告,Intellisense也不會說些什麼。
可是他們的語意是不同的;他們解讀和處理的方式都不同,要把兩種字串互相指派時還要某些轉換函數做轉換,否則就會有執行時期的問題。






明確型別宣告(explicit typing, 要求程式員必須宣告型別)


2014年3月17日 星期一

爪哇學校的危害 - The Perils of JavaSchools

爪哇學校的危害 - 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這個世界上最大的平行處理超級電腦,我不認為微軟真正瞭解他們在這波競爭中落後了多少。


利誘管理法 - The Econ 101 Management Method

利誘管理法 - The Econ 101 Management Method


一個大的問題是:這方法會導致內在動機被外在動機取代掉。

人們將會傾向去尋找局部的最大獲益,他們會找到一些方法,去尋求最佳化某些你正獎勵他們的特殊事情,而不是完成你真正意圖要達成的事。


當你使用利誘管理法時,你等於在鼓勵開發者玩弄制度。

假定你決定獎賞寫出最少臭蟲的開發者,那麼當測試人員要回報一個臭蟲時,就成了大問題了,開發著通常會說服測試員這並不是真的臭蟲;或者測試員會同意,在回報給臭蟲管理系統之前,先非正式地提報臭蟲給開發人員,那麼現在就沒有人會使用臭蟲管理系統啦,雖然記錄中的臭蟲數量降低,但實際的數量並沒有任何改變。

開發者在這方面可是相當有天分的,無論你想要測量什麼,他們總是可以找到方法最大化此數值,而你永遠也無法獲得真正想要的東西。