明星程式設計師的十個特質
原文: Top 10 Traits of a Rockstar Software Engineer http://0rz.tw/o7QTb
看到第一條我就安心了，我絕對不是明星程式設計師，因為「I hate coding」，雖然他列出的十個特質我想其他的九項我大概都有。特別是第十項，我現在翻那些大學資訊科學聖經本的頻率遠超過我大學時候對他們的使用率。
其實看到這篇，我又想到「做學問」跟「解決問題」的微妙差別。
其實這篇講的具備這十個特質的人，通常在學界會比較容易找到（雖然我懷疑學界是否需要多種程式語言的才藝），像是 ntucsie b86/87/88 這幾屆我覺得應該有這些特質的人們幾乎毫無意外地都繼續在學界發光。而比較偏向於致用的，也就是比較重視問題解決的人，對於繼續做研究相較之下是比較沒有興趣的。
「做學問」跟「解決問題」有個微妙的差別，那就是現實框架的存在與否，我並不是說「做學問」就會不食人間煙火，而是「做學問」現實的框架在必要的時候是必須要放棄的，也就是說「做學問」必要的時候可以先無視於現實，或甚至去突破「現實的桎梏」。
像在相對論跟量子力學之前，古典物理學者陷入了「乙太」的迷思，若沒有愛因斯坦假設性拋棄了乙太假說，假定光速是不變的而發展出狹義相對論，今天我們可能還活在古典物理框架的世界裡。（然後資訊科學領域的人就還沒有飯吃）
這是一個好例子，表達了「現實的框架」在必要的時候是必須被拋棄或無視的。而量子力學跟相對論到現在仍然無法「完美」解釋黑洞（或萬有引力）。（光速基本上是可解釋的，但是卻未必是我們觀測到而公設的定值，
那可能是我們現實上現有物理的測量極限，或是我們這個系統的所能觀測到的最大值）
那「解決問題」呢？「解決問題」目的是在現實的框架中尋得一個「較佳解」而非「最佳解」，因此現實框架不但是前提，而且是個非常重要的前提。
用個方式來比喻，就是在遊戲規則下，怎麼去獲取遊戲中的較大利益。在這種情況下，「最佳解（或完美解）」是否存在？是的，存在。但這個「最佳解」在加入了一個變數之後卻未必然是最佳解。
跟我一樣有在研究程式交易的人大多會有一個體認，在不斷跑新的資料的情況，在 N+1 時獲利最多的的交易方式卻未必是在 N 時獲利最多的交易方式。用一個比較常聽見的說法就是「過去績效不代表未來績效」，買基金的時候常聽到。
舉這幾個例子，並不是要說解決問題特質比較強的人就追求不完美，而只是說，因為現實一直在變化，雖然有一個框架在那邊限制住，現在追求出來的完美卻依然有可能過了一陣子後就變成「不完美」的。特別是框架一直被打破的情況下，從 198x, 199x, 200x ，程式設計的理論跟技巧一直在改變再進化，而硬體限制的不斷突破，也使得一些在當時是最佳的解的解法到現在有可能變成了一個笑話之類的。
從電腦系統資源不足，到資源過剩（所以我看過很多人開 int array 都開超大），到現在又資源不足（因為物理的限制一解除，問題的 scale 又變了），我一直算有點憂心的是一些我接觸到的學弟妹對硬體方面無視甚至敵視的態度。（其實精確度的問題以及大數的問題很大一部份跟硬體有關）
我自己是在電腦系統資源過剩的時候念大學的，所以當時對於為什麼要學硬體架構跟學最（較）佳化（這個時候就會覺得對岸用語「優化」比較到位）有著根本上的抗拒。但是現在出來工作，卻覺得這種東西實在很重要，特別是我需要的是較佳的解的時候。
講一講，又覺得沒有什麼重點。不過保持一定程度的不完美，通常比較能夠應對各種不同情況的變化，以及各種彈性，當然前提是，知道自己在做什麼。
『肚子餓了…口渴了…去一趟便利商店就可以了…但是那裡…卻沒有販賣人際關係…』
這真是一本有趣的書。 XD
◎寫在前面 － 流‧清‧涼‧水
《死亡之門》在《第七之門》邁向了一個終結，當然，這是當初作者就已經承諾的事情。然而我個人卻覺得惋惜，因為《第七之門》不再有凡人，而回到神人－以及善與惡的代表力量。
這是應該是我看過最異質的漫畫了。因為主要的內容都是圍繞著屍體打轉，經常性的出現屍體描寫的畫面，不過內容卻是在討論更人性也不過的事情。目前中文版由
本介紹文略有一點內容洩漏，請自行斟酌是否閱讀。本書為