學IT專業（軟件開發）需多長時間啊？

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