寫過代碼的人，相信都對一個觀點深有體會，那就是：No Magic。

用中文來說，就是沒有不用寫代碼而實現的功能。比如你在程序里只寫了一行打印“Hello World”的代碼，那么這個程序就只能打印這么一行字符，只能干這么一件事，其他的事情都不會干。再比如你的程序做了一個表格的界面出來，除非你額外寫了“排序”的代碼，否則這個表格界面是不會自動實現“排序”這個功能的。你想讓你的程序干更多的活，那就得寫更多的代碼。

這個道理也可以反過來理解，如果你發現你的程序額外實現了功能，但是你沒有寫過這樣的代碼，那么就可以推斷：必定有人幫你寫了額外的代碼，這個“人”可能是廠商已經寫好的框架，可能是開發工具，它自動幫你寫了一些代碼，也可能是這個程序的上一任作者，他把代碼寫到了隱蔽的地方。

總之，這時候你得深信必定有代碼存在哦。

說回上個例子，你就寫了一個表格的界面，哎，發現居然它“天生”可以排序，那肯定是有人幫你寫了額外的代碼了，比如說蘋果公司的Cocoa框架。

乍一聽，有這樣的事情多好啊，不用自己干活，事情就自己成了，不用操心啊。但是一個優秀的程序員不會對這樣的事情放手不理的，他一定要找出誰幫他寫了額外的代碼，至少要了解這些代碼的運行邏輯。他為什么要這樣做呢？答案是：這些不知道的代碼很可能將來會出問題！

優秀的程序員必須掌握他所寫的代碼的一切細節，這樣他才知道他的程序在不同場景下會有怎么又的表現，他才能預測他的程序的行為，會不會出問題。再說回排序的例子，當前你的表格是可以實現對數字進行排序，但如何用戶在你的表格里面輸入了數字和字符，那你的表格會怎么樣排序呢？如果你不懂別人幫你寫好的“排序”的代碼，那么就是不知道你的程序會做出什么行為，說不定它會彈出一個告警罵用戶不要亂輸入呢！

這個觀點，想想其實蠻好玩的，可以上升到處事哲學的層面。

比方說這么個場景：某天，某一服務器發生故障造成公司業務停頓，這時候IT經理怒火沖天的來了，對著服務器工程師劈頭蓋臉就罵：你干的好事？！我不管你用什么方法，總之必須在中午前給我解決故障！！

這場景看官有無經歷過？其實用旁觀者的眼光來看，這話妙就妙在：我不管你用什么方法。

最妙的就是三個字：我不管

領導指出大方向，定好目標，即“火速恢復故障”，然后就可以“不管”了，坐著等下面的人把工作完成，實現目標。一定程度上，這位領導也算做了領導工作，災難面前沒有躲起來而是直接面對，而且做出了應對的行動。但是想想又好象哪里不對。

我就想起了No Magic的哲學，事情要完成，就必須有人付出勞動的，不是說你說了一句話，然后喝完咖啡之后，事情就會自動完成的。事情必定是由于某人付出了額外的勞動而完成的。如果你不管他具體用了什么方法，那么可能就會埋下禍根。

話說這個服務器工程師也就是個臨時工，他查看了一下服務器，哎，原來是某一個卡出了問題啊，但是這個服務器型號太老了，廠商已經沒有備件換了，上頭又逼得緊，那就上電腦城某某攤位買一張吧，反正我和檔主也熟。這個故障就這么對付過去吧，反正這家公司待遇也不是很好，下個月就跳槽罷。

至于攤檔買的這個卡好不好用嘛，呃，我也不管了。