1.理解你的需求

成為高效程序員的第一步是，保證時間的合理分配。沒有什么比將時間花在完全沒有前途的工作上更浪費的了。

盡快開工

盡快完成一個直觀的系統(tǒng)。這意味著先創(chuàng)建界面，無論是程序界面還是用戶界面，然后生成內(nèi)部功能的存根代碼（如果有必要的話）。這么做便于“客戶”查看，通過執(zhí)行用戶界面或編寫程序界面的代碼，可以發(fā)現(xiàn)最初代碼存在的矛盾或遺漏。甚至在第一次交付以前，你有可能會注意到問題或可改進(jìn)的地方。

有一個經(jīng)典觀念認(rèn)為，如果你提前設(shè)計好所有東西，那么之后你要做的就只剩寫代碼了。如果你之前做過完全相同的項目，那么這個說法當(dāng)然正確。但如果不是，你很可能會陷入死角，也就是你只是在猜想或執(zhí)行一個可疑的假設(shè)。

很早以前在一家無限網(wǎng)絡(luò)的新公司工作時，我們開了兩個月的會來設(shè)計一個將在6個月內(nèi)發(fā)布的無線門戶和網(wǎng)關(guān)。最終，我們厭煩了開會，開始編寫代碼。頭兩周內(nèi)，我負(fù)責(zé)的部分與原始設(shè)計不符，兩個月后的第一個無線連接測試表明，我完全誤解了無線協(xié)議。

這不是說設(shè)計是沒必要的。但在一定程度上，設(shè)計只是一種猜想。設(shè)計應(yīng)該通實執(zhí)行來確認(rèn)，并且早執(zhí)行總是比晚執(zhí)行好。

即使原始設(shè)計是充分的，只要你發(fā)現(xiàn)可以調(diào)整的地方，你就要改進(jìn)它。硬件產(chǎn)品、建筑和大型軟件項目等會受到僵死的“預(yù)制”的損害，但對于軟件，你可以在項目早期提煉項目要求，然后制作適合的界面。但是，這必須盡早完成。

盡早開工有利于樹立你的職業(yè)形象。如果能向你的老板展示一些成果，他會很高興的。另一方面，提早開工有助于緩解焦慮。

經(jīng)常交付

一旦你完成一些可用的東西了，不要只是把它留作“概念實證”。要讓其他人試執(zhí)行它、看看他們的反應(yīng)，然后讓它指導(dǎo)開發(fā)過程的優(yōu)先次序。觀察人們?nèi)绾问褂媚愕能浖?，這是無可代替的方法?？蛻魡柧碚{(diào)查和焦點研究可能會提供一些有用的意見，但有可能會讓開發(fā)者的設(shè)計決定和特點被客戶牽著鼻子走，這是一種冒險。

特別是要盡快將軟件交付QA人員，經(jīng)常提交成果，最好是按預(yù)定的時間間隔。讓他們測試每天的成果，或至少是每周的成果也是好的。這會讓QA人員覺得自己全程參與項目開發(fā)，從而培養(yǎng)職業(yè)責(zé)任感，更樂意發(fā)現(xiàn)和報告問題。最需要優(yōu)先解決的是導(dǎo)致產(chǎn)品失效的問題，如崩潰或死循環(huán)——讓問題盡可能涵蓋多方面，熟悉整個產(chǎn)品，這樣才有可能提早發(fā)現(xiàn)設(shè)計問題。

在一個小型3D軟件公司，我負(fù)責(zé)移植從SGI出品的龍頭產(chǎn)品到Windows NT。6個月后，移植沒完成，倒有了崩潰的傾向，我很不情愿地將第一輪成果交付測試團(tuán)隊。幸運的是，因為漏洞太多，QA經(jīng)理堅持要我立刻解決導(dǎo)致測試

人員無法有意義地使用程序的問題。如果是我自己測試，我應(yīng)該會忙于看起來更困難更重要的核心3D問題，可能會怠慢看來起比較普通的問題，如用戶界面、載入-保存功能和與計劃支持的硬件之間的兼容性。

程序師常常不想過早將代碼交付測試人員——他們不想聽到自己已經(jīng)知道的漏洞；而測試人員極有可能不想測試基本上行不通的東西。但測試人員的工作就是找到這些問題。如果程序師想盡快看到成果的話，應(yīng)該把漏洞報告當(dāng)成好東西。

2.把工作當(dāng)真

將軟件放在盡可能接近完工的狀態(tài)下運行。你永遠(yuǎn)不知道你什么時候得演示系統(tǒng)、發(fā)送評估備份或甚至交付。

使用真實數(shù)據(jù)

如果你只用作為著冰山一角的樣本數(shù)據(jù)作測試，那么，你的程序可能一撞上真實數(shù)據(jù)的大冰山就沉了。

我曾參與開發(fā)一種用于評估先進(jìn)的半導(dǎo)體絕對值的供應(yīng)鏈管理產(chǎn)品?？邕^交付這道大坎后，我們接到消息說他們輸入的第一批真實數(shù)據(jù)仍然在處理中——已經(jīng)兩天了。我同情主程序師，他不得不在管理人員和客戶的催促之下忙活了兩周。很高興遇上這事的人不是我。

使用正式版本

記住，用你自己的機(jī)器創(chuàng)建的東西不是正式的。

在最近的一個游戲開發(fā)項目中，我負(fù)責(zé)用戶界面，我陸續(xù)從QA那接到報告說有些顏色不對。最后，我發(fā)現(xiàn)問題只出現(xiàn)在交付版本中，另一位程序師使用專門的主機(jī)調(diào)試工具找到了漏洞。結(jié)果竟是一個我在兩個月前犯下的愚蠢錯誤，沒有指定初始顏色值。調(diào)試版本總是選擇特定的默認(rèn)值，但是交付版本會更改，最終結(jié)果是不太確定的。如果我注意經(jīng)常地運行交付版本，我會立刻發(fā)現(xiàn)問題的，而不是損失大量的時間。

經(jīng)常合并

及時將你的代碼并入主代碼庫中——你拖得越久，這項工作就越累。

我曾與一名程序師共事，他覺得每天數(shù)據(jù)庫中出現(xiàn)的所有新代碼和數(shù)據(jù)變化都“很麻煩”。確實，這讓所有其他程序師每天都要花一定時間合并，他才能夠只掃視一下代碼和數(shù)據(jù)就開始運行一些不錯的獨立樣本。但每一次階段性交付時，我們都要花好幾天再次把單獨的代碼接到當(dāng)前的代碼庫中，有時候甚至得拖延交付或冒著損失整個項目的風(fēng)險。

將你的代碼與正式版本分開意味著程序師不能評估你的代碼，以及測試員不能盡早發(fā)現(xiàn)漏洞。可能你并不想其他人挑剔你的代碼，但早發(fā)現(xiàn)問題總是比晚發(fā)現(xiàn)好的——所以，忍了罷。

3.理解你的代碼

生活中充滿了奇妙的神秘，但你的代碼可不適合出現(xiàn)這些神秘。你不必知道你的車怎么工作的——如果引擎發(fā)出奇怪的聲音，把它交給汽車技師就好了。但換成是你的代碼，如果連你都不知道它是怎么運行的或出了什么錯，那就沒人知道了。

有自己的編寫風(fēng)格

我童年時的鋼琴教師是這么評價我和我姐姐哥哥的：“你姐姐的時間感強(qiáng)，你哥哥的鍵盤打得不錯?！比缓笏ｎD了一下說：“你嘛，嗯，你很努力?！?/p>

編程是一種有些人能做有些人不能做的事，但還有一些人則是天才。雖然我有過多年的練習(xí)，鋼琴還是彈不好；雖然我那么喜歡打球，水平仍然一般般。但我確實認(rèn)為我有編程和寫作的天賦。不要吃驚，我認(rèn)為好程序就像好散文。散文和代碼都是文本，有語法、句法、拼寫和語義。對于大多數(shù)寫代碼的人和寫作的人，有這些就夠了，但好作家和好程序師還要有一種美感，他們的作品在結(jié)構(gòu)和風(fēng)格上是有特點的，往往能借此識別出作者。

許多Windows程序師都感到好奇：為什么壞脾氣的老Unix/Mac/Amiga/Lisp程序師對Win32/MFC/.NET很不滿，但如果所有應(yīng)用界面都來自Microsoft，你可能就不知道還有什么東西是更好的。

復(fù)制粘貼

風(fēng)格化編程的反面是復(fù)制粘貼。從什么地方復(fù)制一些可能有用的代碼，稍作調(diào)整，合并，重復(fù)，然后就大功告成了。你的軟件簡直就是大雜燴。

離開一家公司的幾個月后，一位前同事電郵問我，他復(fù)制粘貼了十頁的代碼組成一個算法，為什么運行不了。我實在不知道怎么回答了。如果你不能解釋你自己的代碼應(yīng)該是怎么運行的，你還指望誰來拯救你？

我甚至在診斷自己從樣本代碼復(fù)制粘貼過來的代碼時也犯過難。從復(fù)制粘貼開始新代碼是合情理的，但你不能因為看起來能運行就放手不管了——你得返回去看看你是否讀懂了每一條，根據(jù)自己的目的理清代碼。

清理代碼

保持你的房子/公寓/房間整潔的最好辦法就是每天花一點時間清理它，或至少每周清理一次吧。如果等到住所亂到一定程度才打掃，那么這麻煩就非常大了。除非你雇個清潔工。

假設(shè)你沒辦法奢侈到雇一個人每天幫你清理代碼的程度，那么你就應(yīng)該定時地檢查你的代碼、清理累積的死代碼、淘汰過時的注釋和錯誤的名稱，否則你必定會得到一份不敢拿出來見人的代碼。如果你不覺得丟不起人，好吧，你行。

我指導(dǎo)過的一名程序員總是向我報告，她的代碼“完成”了。這是管理者樂意聽到的話，卻讓我非常抓狂。她的代碼從來沒有做完——你得調(diào)試它、維護(hù)它、改進(jìn)它，直到它徹底沒問題。

問題？注釋？

有些人認(rèn)為編程是一門手藝活，也有些人認(rèn)為編程是一項工程。更經(jīng)常的是，它是一門考古學(xué)。你挖掘代碼的沉積物，想知道這些奇怪的人工產(chǎn)品是用來干什么的。為后來人著想一下，留點線索吧。

我問之前提到的那位程序員“完成”注釋了沒有。結(jié)果是，一個函數(shù)名稱為“GetData”的注釋居然是“Gets data”。這不只是廢話——簡直是侮辱。什么數(shù)據(jù)？什么格式？來自哪里？更不要提像服務(wù)器不可用或傳送中斷時會怎么樣這種小細(xì)節(jié)了。

將你的代碼做成文檔，以防有人隨時要拿來用?？赡芤玫娜司褪悄惚救恕胂肴绻贿@么做，你得重新訪問代碼多少次啊？

與之前的一個老板合作時，他叫我瀏覽一段沒人有時間看的代碼。一開始，我認(rèn)為它很糟，不知道寫的都是什么東西。之后我慢慢摸索出來這段代碼是干什么的，所以我勉強(qiáng)同意它不算太糟。最后我終于認(rèn)出這貨竟是我兩年以前寫的。教訓(xùn)：多留點注釋。

當(dāng)你寫代碼時，記得注釋，而不是等著出現(xiàn)什么方便的清理短語——注釋你的代碼，讓它甚至可以清楚地反映你在編寫時的想法。你可以成為自己的編寫伙伴。

現(xiàn)在你可以用javadoc和doxygen等生成漂亮的HTML或來自源代碼注釋的其他格式化的文件。理想的情況是，你每天晚上做的就是doc生成的部分，可以通過你的內(nèi)聯(lián)網(wǎng)獲得。

注意警告

無視編輯器和運行時間警告會害到你自己。有“警告”就有原因。

我曾做過一個基于Unix的應(yīng)用，它不能成功地連接某些函數(shù)。我們通過在運行時再次連接這些函數(shù)解決問題。六個月后，當(dāng)我們執(zhí)行一個干凈的新版本時，我們才發(fā)現(xiàn)原來我們關(guān)掉了能提醒我們未知連接漏洞的警告。在供應(yīng)商的斥責(zé)下，我們將連接問題解決了。但結(jié)果是，原來我們只要通過重新排列庫就能連接上了。

提高編輯器的警告水平，注釋代碼以及記錄創(chuàng)建和運行時間的警告信息，最好包括解決警告的標(biāo)準(zhǔn)，這樣你就會知道是否解決問題或忽略問題。

4.優(yōu)化編程

帶著目的寫代碼

復(fù)制粘貼代碼的人的另一個極端是，只是為了讓代碼看起來更漂亮（至少對他們而言）而改變代碼。雖然有編程審美感是值得贊揚的，但改變代碼以便讓你覺得漂亮只是浪費時間（無用的冒險）。瀏覽并改變別人寫的代碼，讓它看起來更漂亮，真是讓人生氣。

我有一個挑剔的同事，瀏覽我們的代碼庫時將所有的附加語都刪除了。如果他只是清理了入門級員工寫的代碼，那可能沒人會說什么，但那些附加語是我們團(tuán)隊的技術(shù)領(lǐng)導(dǎo)寫的，他可是我們公司最出色的人物之一。

不要搞破壞

“代碼重構(gòu)”現(xiàn)在十分流行，但程序員往往以為它是指代碼清理或重新設(shè)計。這個技巧是指重新組織代碼，同時不破壞其他東西。如果你以改進(jìn)的名義破壞已經(jīng)存在的功能，那么你的意思就是：要么你的時間比其他人的時間金貴，要么你不破壞就不會整代碼。

我有一個特別討人嫌的同事，他決定重新執(zhí)行我們系統(tǒng)中的解析器，但結(jié)果讓代碼變成其他所有人都不知道怎么寫了。我讓他恢復(fù)原狀，之后發(fā)現(xiàn)代碼能編寫了，卻不能運行了—–問他怎么回事，他說“應(yīng)你的要求”，他移除了整個解析器。真沒團(tuán)隊精神。

保持代碼運行需要一些耐心和額外的工作——你勤奮地回歸測試你的工作，在將函數(shù)添加到新代碼中時，你可能需要暫時留住老代碼和界面。但對于所有與這個代碼庫有關(guān)的人來說，這是必須做的。

找到瓶頸

人們總是談?wù)摗白罴选保@不是一個正確的詞。我們極少將最佳作為目標(biāo)——相反的，我們的目標(biāo)是改進(jìn)和權(quán)衡以達(dá)到足夠好的表現(xiàn)。

在谷歌的電話面試時，我被問到如何在一組有序的數(shù)字中搜索某個數(shù)字。顯然，提問的人是在問二進(jìn)制搜索法。但在現(xiàn)實生活中，我可能會做出“錯誤”的選擇——從頭找到尾。如果程序表現(xiàn)足夠好了，還花兩倍的時間寫兩倍的、必須維護(hù)和調(diào)試的代碼，那是毫無意義的，特別是如果那段代碼并非程序的瓶頸（我嚴(yán)重懷疑如果那個數(shù)據(jù)是瓶頸部分，你居然還會將它線性排列）。

如果你確實需要在程序的速度或空間方面達(dá)到最佳，折騰除了瓶頸以外的其他任何部分都只是浪費時間。

5.自我管理

你可能對你那位討厭的老板有各種抱怨，你的抱怨可能沒錯。所以你得成為你自己的管理者。即使你的老板人不錯，他也不會站在你背后告訴你該寫什么、怎么寫才會快（盡管我肯定許多老板恨不得這么做）。

估計時間

程序師不能提供有用的時間估計，這是出了名的。但我認(rèn)為這是無理指責(zé)，因為管理層往往作出更差的預(yù)測，并且程序員的警告往往被無視（這可能是所有工程的共同災(zāi)難）。但是，合理的時間估計對于按時完成項目仍然是關(guān)鍵的。

在一個商業(yè)軟件項目中，我的有些同事居然樂得忘了產(chǎn)品交付日期——有人問是否已經(jīng)交付了，另一個人才很驚訝地發(fā)現(xiàn)，日子已經(jīng)過去好幾天了。

更糟的也更普遍的是，程序員能給出的時間估計是“只需要幾天。”每次我聽到這話，或者我自己說出這話，我都感到害臊。

一家圖像軟件公司的總裁想讓產(chǎn)品支持VRML（那時它是下一件大任務(wù)），包括我們將在兩個月內(nèi)發(fā)行的產(chǎn)品也支持VRML。他可能想到（他是正確的）我會拒絕開始新項目，所以他問了另一個工程師，得到了他想到的回答：“只需要幾天?！眱商旌螅腋嬖V總裁，我們剛剛浪費了他和我的兩天時間，因為有兩百多個更重要的漏洞要修復(fù)，他認(rèn)為我的理由算是充分。（后話：VRML沒有太成功。）

另一位程序員完全沒有時間估計的概念。但沒有必要完全拒絕時間的模糊屬性——畢竟只是估計，事實上你應(yīng)該避免太確切。如果你是一名有經(jīng)驗的工程師，你就知道你以前做類似的工作需要多長時間，如果你不是，那你就問問有經(jīng)驗的人。

我有一個聰明的朋友，經(jīng)常被指派去開發(fā)實驗原型，他問我：“你怎么估計時間？”我認(rèn)為這是一個反問句，但甚至純研究人員也要估計時間。有人支付他們，希望得到結(jié)果，即使它是許多演示樣本或某段時間發(fā)表的文章。

如果你確實估計不準(zhǔn)需要多少時間，那么你就不是做這項任務(wù)的合適人選。

有時候程序師不情愿承諾時間是因為他們害怕保證。確實，這個世界沒那么美好，經(jīng)理會在時間上跟你討價還價，競爭對手可能用嚴(yán)苛或不切實際的安排來擠兌你，希望你失敗。在你承諾時間后，你就悲劇了，你別想得到任何你希望的結(jié)果。

我曾有個老板問完成時間后會追問一句：“你保證？”但問他硬件條件和其他相關(guān)事宜時，他會說：“我盡量。”

我能說的只有，抓緊時間以及給出現(xiàn)實估計。任何讓步都應(yīng)該根據(jù)實際的介于產(chǎn)品和資源之間的交易。要根據(jù)假設(shè)、相關(guān)事宜和資源做時間安排，找個地方寫下來，這樣以后你就不用麻煩你不太給力的記性了。

計劃進(jìn)度

在決定上哪去以前，你不會跳上車的，對吧？你在開車時心里可能就有路線了。相同地，在你開始用電腦寫以前，你應(yīng)該知道你今天想完成什么，有一些想法了。

每天都會遇到分心的事，所以你不可能總是完成你想完成的事。與那些將軟件工程團(tuán)隊當(dāng)作自動販賣機(jī)的人的想法相反的是，有些任務(wù)不是一天就能完成的。所以想想你到周五要完成什么，如果你完成了，那么周末你就可以好好過了。

6.不斷學(xué)習(xí)

一名社團(tuán)足球隊成員曾經(jīng)問我，我們每天束緊防滑釘練習(xí)，你們“C語言編程的秘密是什么？”如果存在這樣的秘密的話，我肯定會在晚間電視節(jié)目上宣傳如何靠房地產(chǎn)發(fā)財。對不起，沒有捷徑——你必須學(xué)習(xí)、練習(xí)和犯錯。你不一定得依靠團(tuán)體訓(xùn)練或?qū)W校教育——有許多國立的和當(dāng)?shù)氐膶I(yè)團(tuán)體、書籍，當(dāng)然還有網(wǎng)絡(luò)。

編程是科學(xué)

編程被稱作“計算機(jī)科學(xué)”是有原因的。無需正規(guī)的計算機(jī)科學(xué)教育，任何人都可以輕易地開始編程（可能太容易了）。特別是，那些學(xué)過其他工程和理科的人，可以非?？斓厣鲜志幊蹋缓笠源酥\生。但對于高效地處理重大任務(wù)，你必須知道軟件的固有功能和限制、識別前提，這樣你才不會白費力氣地做重復(fù)的工作。你不必知道所有事，但你應(yīng)該至少粗略地了解許多領(lǐng)域，必要時能做一些額外的研究。

例如，創(chuàng)建了新文件格式的人應(yīng)該知道一些關(guān)于編輯器的事。我不是指所有代碼生成的優(yōu)化如循環(huán)展開，而是基本的問題和各種編輯的短語和大部分指定標(biāo)記和語法的重要性。今天，大多數(shù)人會默認(rèn)地使用XML，那是件好事，

但在那之前，一般是粗略地寫一些文本格式，指向一些生成的樣本文檔作為文件，之后其他寫了另一個解析器的人會補(bǔ)上一些在文檔中閱讀的東西，但不是全部。在出了差錯的情況下，你有兩種方式推卸責(zé)任——要么讀者不行，要么作者太差。無論怎么樣，更受歡迎的產(chǎn)品會贏。

我對3D圖象行業(yè)最不能容忍的事情之一是，過多的文件格式不明。當(dāng)我執(zhí)行一個3D作品的OBJ文件解析器時，我測試的每份導(dǎo)出作品都生成明顯不同的文件，比如空白和換行不同。與之形成對比的是，我的一個初出茅廬的同事用語法和詞法分析器設(shè)計了一個新游戲交換格式（現(xiàn)在，這不再是什么大不了的事了—-大多數(shù)新圖象文件格式好像都是基于XML的）。

只會將簡單的腳本和用戶界面放在一起的程序員和可以處理實際問題的程序員，如果說這二者有什么區(qū)別的話，那就是對復(fù)雜計算的理解能力，如算法怎么影響問題的大小。每一位程序員都應(yīng)該知道基本的復(fù)雜性術(shù)語和對常見問題的復(fù)雜程度有常識性認(rèn)識。

我的第一份工作是計算機(jī)輔助半導(dǎo)體設(shè)計，涉及許多可擴(kuò)展性的問題，包括一些NP-complete問題（非常難處理）。但是，每次看到在線性時間中不能解決的問題，和我們自夸可能意味著大部分是線性時間的“線性”算法，有些工程師會興奮地說：“這是旅行商問題！”（游戲邦注：旅行商問題，即TSP是一個有著重要工程背景、在圖論中的典型組合優(yōu)化問題，已被證實是一個NP完全問題。也就是，如果一個旅行商不得不到幾個城市做生意，怎樣走最短的路線使他一次到達(dá)這幾個城市。）

免費啤酒、自由討論、免費軟件

好吧，其實沒有免費啤酒；但現(xiàn)在程序員過得還不錯（盡管經(jīng)濟(jì)衰退和外包業(yè)惹爭議）——畢竟你需要的東西網(wǎng)上教程、討論組上都有，還有免費軟件可以用。你要解決的只有硬件和寬帶問題。

7.尊重

高效軟件工程師的要求之一是，被認(rèn)真對待。你必須得到你的同事和老板的尊重，至少出于你的技術(shù)能力、對自己的工作有主導(dǎo)權(quán)、對他人有一定影響力。

愚蠢問題

真的，這個世界上存在許多愚蠢的問題。提出一個聰明的問題會增加別人對你的尊重，但這是一項技術(shù)活。一個揭露未解決的事的好問題會讓別人看到你深刻的內(nèi)涵，你敏銳的思維。要求說明關(guān)于技術(shù)參數(shù)的問題，顯示了你閱讀和發(fā)現(xiàn)問題的能力。

如果你的問題沒有得到答案，可能是問題本身有誤，所以不要再重復(fù)發(fā)問了。換一種方式提問，帶上更多細(xì)節(jié)或背景。如果被提問的是你或花時間回復(fù)新手問題的是你，你會感謝上述考慮的。

能與技術(shù)支持人員保持良好關(guān)系，這是讓我對自己都感到驕傲的事。但我確實記得一件往事，那時我拋出一個問題：“幾周前提出來的那個問題是怎么回事？”你可以想象別人是多么惱火地回答——“你說的怎么回事是指什么，并且，你說的是什么問題？”

粗魯無禮是沒有回報的，特別是如果你是要求免費指導(dǎo)或咨詢討論組。即使你是在支持協(xié)議的保護(hù)之下發(fā)問，激怒了你的技術(shù)顧問對長期合作也會很不利。

我曾經(jīng)向臭脾氣的新人們解釋為什么他們的問題有問題或者什么是他們從一開始就做錯了的，真是太累人了?，F(xiàn)在，我給你快速生效的傻瓜過濾器——“我想知道的只是……”或果斷無視。

讓所有人知道你讀了文件和谷歌搜索了該問題。除了避免回復(fù)必然的“RTFM”（游戲邦注：RTFM意為：去讀該死的指導(dǎo)手冊。當(dāng)你需要信息或者解決問題時，在請求對方幫助之前，應(yīng)該花一些時間嘗試自己去尋找需要的東西。）和“Google is your friend”，都顯示了你做足了功課，那些幫助的人不必搜索相同的資源。如果你確實指望他們?yōu)槟闼阉髂切┵Y源，那你的意思就是，你的時間比他們的金貴，你在謀殺他們的時間。

白癡答案

如果你要表現(xiàn)得你知道自己在說什么，那么你確實應(yīng)該知道你到底在說什么。工程師的交流有時候更多地是炫耀自己的知識而不是提供信息（如果你也能這么做，那我向你致敬）。這往往無益于求職面試，面試官其實是假借“發(fā)現(xiàn)你是怎么想的”的幌子，向求職者拋出空洞的問題。當(dāng)然，如果求職者有一點自知之明的話，也可能產(chǎn)生出乎意料的結(jié)果。

有一位技術(shù)總監(jiān)打電話面試我，要我概述C++編輯的結(jié)果堆?？蚣埽⑶铱陬^答復(fù)他。我一步一步地打草稿，每次我給他正確的答案，他都反過來要我說一個錯誤的答案，以便我們可以仔細(xì)檢查為什么那個選擇不管用。我不知道我這么寫是不是在彰顯我有多聰明或他有多聰明。

作為一名工程師，你不能太倚重錢財和長相——信譽(yù)才是你的資本。所以如果你犯錯了，就坦率承認(rèn)吧。

我有幸與一名資深工程師共事，他從來不犯錯。當(dāng)他的Java代碼在多重處理器系統(tǒng)中崩潰時，原來是出現(xiàn)了大漏洞。當(dāng)我拿代碼指出UI代碼不支持多線程運行時，他堅持說只有一個線程。當(dāng)我列出代碼中的7條線程（我能找出的）時，他同意不應(yīng)該保留這么多線程，并且最好修改一下。但他還是按老樣子編寫代碼——他沒有修復(fù)任何漏洞，他只是用更多代碼掩蓋了漏洞。

最后，一個節(jié)省時間的建議：不要糾結(jié)于愚蠢的爭論。愚蠢是會傳染的。