成為一個程序員要花多長時間——理解專業程序員
對于有些事情，似乎每個人都是專家。教學就是一個好例子。任何人，只要智商超過80，又懂得一點兒什么東西，似乎都可以當老師。至少美國的教育體系就是建立在上面這個理論上的。在美國，但凡你敢對一個教授說，他的課堂教學還有可改進的地方，那他就會感到羞辱、惱怒，還很可能采取法律行動。
還是在美國，每個人都是當招待的專家。在歐洲，一個侍者可能要經過10年，甚至20年的訓練，才能獲準在一個一流飯館服務。在美國，只要按照廣告應征，在小臂上搭一條毛巾，那就是侍者了。
編程是另一個不缺乏專家的領域。按照標準看法，6個星期的“培訓”就足以把一個人提升到“專家”層次，該人不必再學習任何新的知識，即具有設計在線生命救援系統的資格。如果你看到一條廣告招收“有經驗的”程序員，那意思往往就是一年或者兩年經驗。實際上，如果誰有15年的編程經驗，人們倒會覺得這人簡直是個智障。如果他真有一點點智力的話，那總應該在14年前就學會了全部編程知識。在此之后，他就早該做膩了這一行，去換個管理呀，銷售呀之類的職位了。
先別忙著嘲笑持這種觀點的人，首先我們還是應該承認，15年的經驗，就其自身而言，在編程方面不一定就能教會你任何東西。我認識一些有“15年經驗”的美國侍者，甚至不知道餐前如何在餐桌上放盤子。我也知道一些有“15年經驗”的美國大學教授，甚至教不會小狗搖尾巴。同樣，我也認識一些有“15年經驗”的美國程序員，他們仍然會在一個多程序訪問的系統中，在更新直接存取主文件（master file）之前，就給事務文件（transaction file）排序。
理解專業程序員第1章對專業人士來說，有哪些重要問題如果說這個例子還太難懂，那我就來列舉幾個前兩天讀“有經驗的”程序員寫的代碼時發現的問題：
1. 在做整數除法時，有些人不懂“余數”是什么東西！
2. 為了把一個取值在0~5的變量轉化成取值在1~6的變量（用于FORTRAN語言的下標），有人用了5個IF語句，再加上5個賦值語句！
3. 在寫COBOL程序的時候，有些人不用“ELSE”子句，原因是“這不一定管用”。
4. 在寫PL/I程序的時候，有些人從來不用變長字符串，原因是“這個不夠高效”。
5. 有些人根本不寫子程序，原因是“這太復雜了”。
這個單子能夠無限地寫下去。這里的要點不是在于，居然有這么多看似專業程序員的人在四處丟人現眼，而在于，沒有幾個管理者知道，正在和自己打交道的到底是“他們”中的一員，還是“我們”中的一員。
這和美國侍者的處境特別相似。在美國，很少有人曾經享受過專業侍者的服務，所以即使人們真正遇到了一個專業侍者，他們也無從辨別。或者這樣說更好，他們根本無法意識到，他們心目中的“標準”侍者其實還處于“亞專業”層次。
同樣，除非你自己就是一個勝任的程序員，否則也就很難衡量一個程序員的工作質量。世上有很多可憐的企業，這些企業中從來沒能長期留住一個真正勝任的程序員，因此他們也就沒有一套標準來衡量程序員的專業性。這些企業的標準就是把庸人當成奇才。而這樣的標準也千奇百怪，各地均不相同，甚至同一公司中的不同部門也不相同。
每次我到一家新公司去做咨詢顧問的時候，我都提前讓經理給我看一些典型代碼。經理們往往都不敢相信我真是要看代碼，我總得堅持索要好幾次才能得手。只要看一小段代碼，我通常就能對該公司的工作環境具有相當準確的了解。有時候我說得特別準，管理層聽了都大吃一驚，以為此前我跟員工們私下談過話。
經理們自己永遠也不看代碼。代碼之于經理，如同臟盤子之于領班侍者。一旦你從那個垃圾堆里提升出來，你就再也不碰那些垃圾了——開玩笑碰一下都不成。
有一回，在大學里的時候，我們學生提議，教授們也應該和學生一起參加碩士生考試，好給學生們做個榜樣、立個標準。2/3以上的教授對此滿是驚恐，敬謝不敏。他們自己也經過20多年的考試折磨，再也不愿意回到考生的位置上去——這會讓他們想起從前卑微的地位。
同樣，在我們的行業里經理不愿意編碼，這說明寫代碼這個職業在人類等級體系中的地位略高于盜墓者，低于管理層。對于這樣的思考方式來說，編寫代碼不可能構成一種獨立的技藝，不可能是一種天分，也不可能是一種有著自身地位的體面職業——所謂體面，就是說不必和盜墓呀，管理呀之類的在同一個尺度下衡量。只要這種態度在數據處理行業還處于主導地位，那就仍然會有6個星期培養出來的專家，也還會有那些經理——他們甚至不愿傾聽公司高薪聘請的、有15年經驗的程序員說話。
當老師、當侍者、當程序員，這3件事有什么共同之處嗎？為什么人人都覺得自己能夠像專業人士一樣做這3件事？首先，這些工作似乎是容易理解的，因為很多挺普通的人都有過相關的經驗。每個人都或多或少曾經教過別人。每個人都做過把盤子放在桌上，或者收拾臟盤子的事。但是不是每個人都曾經在一個活人大腦上做過手術，也不是每個人都曾經在陪審團前為一個案件辯護。
但是編程序又是什么情形呢？當然了，并不是每個人都寫過程序，對不對？也許不是每個人都寫過，但是似乎每個經理、會計、工程師，或者其他大學畢業的專業人士都寫過程序。編程課程在大學里相當風行，在很多職業教育中，這也是必修的課程。比如說，IBM在20年來，在行政人員培訓班中就設置了一定的“編程經驗”。
我不太清楚現在IBM的行政人員培訓班的具體課程內容，但是有好多年這門課程中包括了那個著名的“曼哈頓問題”，作為唯一的編程練習。在美國，數據處理課程的主流入門教科書大多會講到這個“曼哈頓問題”，如果讀者中有人不巧沒學過這個，我就按照教科書上的寫法，在這里重復一遍：
問題是這樣的：據說在1627年，白人們用24塊錢買了曼哈頓島。如果這筆錢被存入一個銀行戶頭，按年利率4.5%計算，今天會有多少錢？
（如果4.5%的年利率偏低的話，那是因為這道題是1956年出的，從那時起就被一代代的作者在不同的教科書中抄來抄去。）
這道題的“解法”，如果拋開一些無關緊要的細節，按照FORTRAN語言編寫，那就是這樣一個循環：
I = 1627
PRINC = 24.00
2PRINC=PRINC*1.045
I = I + 1
IF(I-IYEAR)2,1,1
1WRITE (3,601) PRINC
至少有三四百萬名學生學會了這個“解法”，這之中包括從行政人員到大學新生的各種人。對于其中的一些人，以上代碼就是他們“寫過”的唯一程序，但是這就讓他們有足夠資格判斷編寫一個操作系統、一個勞動力部署系統、一個零件需求管理模擬器、一個在線處理控制器，或者無論什么你想得出來的系統的復雜度。而且，當然了，在行政人員的課程中，每個學生還有一個專業程序員作為輔導，“好幫助他們處理細節問題”。
其實呢，曼哈頓問題確實可以作為一個出色的工具，教給行政人員關于編程行業他們應該知道的最重要的一課。假設讓他們編寫了以上那么一段程序，也對他們承認這確實是問題的一個“解法”。然后你就問問他們，編這個程序花了多少時間，運行該程序又要多長時間，再問問他們，覺得這些數字“好不好”。
當他們交了作業，也總結了感受，你就讓他們看看下面這個程序，告訴他們這樣的代碼就能獲得同樣的結果：
PRINC=24.00*(1.045**(IYEAR-1627))
WRITE(3,601)PRINC
對他們比較一下編程時間和運行時間。你大概能夠發現這后一個程序只需要1/5的編程時間，和1/100的運行時間，當然具體的比例在不同的環境下不一樣。然后你就問他們：“如果對這樣一個最簡單的程序，兩種不同的代碼之間能夠具有5倍，甚至100倍的差別，那么，如果一個專業程序員和一個業余程序員編寫同樣一個操作系統的話，又會產生多大差別呢？”
如果給行政人員上了這樣一課，那么這種給他們掃盲、讓他們理解編程是怎么回事的課程也許能夠利大于弊。但是目前這一類課程的主要目的，雖然從來沒有明言，但其實是這樣的：“編程并沒有那么復雜。練習幾個星期，哪怕是我也能成為編程專家。”
為了把編程當成一種正規職業對待，公眾——也包括程序員自己——都應該通過某種方式受到教育。他們必須懂得這樣一個道理：即使是15年的經驗，對于學習編程知識來說也不一定就夠用——除非這位學習者特別一心一意。
文章鏈接：http://blog.sina.com.cn/s/blog_52f761ea0100ce8u.html
【編輯推薦】
