Posts Tagged ‘engineer’

上半輩子，我也是個工程師。

我從 11 歲左右開始寫程式，第一個語言是 BASIC，之後還學過 C/C++, Assembly, Java, Lisp。除了寫程式，我也從 15 歲左右開始自己升級、組裝電腦，買過一條一萬元的 1MB RAM — 為了玩 Wing Commander，也買過一台 2 萬元的光碟機 — 為了讀大補帖、看 VCD。

在第一次接受創業的洗禮之前，我的思考方式跟一般的工程師沒什麼兩樣。

我總是用「技術架構」的眼光看事情。Twitter 不就是一個簡單的短訊存取系統，我一個週末就可以寫出來了。Instagram 只是個照相 App 加上幾個濾鏡，哪有什麼了不起。Google 的客製刀板伺服器好屌，一個架位可以放 32 台主機。Pinterest 的瀑布流只是幾行 Javascript 而已，真不懂大家為什麼大家那麼興奮。

無論我做什麼，一定要用「最新、最酷的技術」。SQL 已經落伍，現在最屌的軟體都是採 NoSQL。HTML5 才是王道，所有的其他平台都會被打敗。做網站當然一定要用 Responsive Design，沒有就太遜了。

我最討厭跟「麻瓜」浪費時間。使用者不會用我寫的軟體，是他們太笨。客戶聽不懂我的技術與架構有多厲害，那還想出來混。與其花時間跟生意人喝咖啡，我還寧可回家打魔獸。

直到我創了業，開始做行銷、當業務、擔任管理職，我才知道之前的思考方式有多幼稚。

技術架構根本不是重點，產品對使用者有多少價值才是重點。最新、最酷的技術也不是重點，穩定、兼容性高、經過市場考驗的東西才是重點。出來做生意，聰明、厲害也不是的重點，建立長期互相信任的關係才是重點。

然後你就了解為什麼每年有成千上萬的工程師出來創業，最後能夠成功獲得使用者與市場青睞，找到長期獲利模式的人卻手指數得出來。

這是工程師教育的盲點，也是所有工程師的詛咒。直到你覺悟的那天前，你很難變身成一個真正的創業者。

快醒來吧，各位工程師。

___

每天的種種人生體悟，也會分享在我的 Twitter 上，歡迎追蹤

(Inspired by Niall’s Blog; Photo via chrisjan99, CC License)

我常常在想，如果你把一個「成功」的創業者丟到 @deduce 的成份分析器裡面，會跑出什麼東西來。上面這個圖，大概是我想像中最可能出現的結果。

一個成功的創業者，勢必需要是一個商人。而且他的商人 DNA，可能需要大過所有其他成份。創業畢竟是做生意，如果公司沒辦法有營收、獲利、最後規模化，那這門生意終究必須關門大吉。所以一個成功創業者的商人 DNA，必須要有相對的優勢。

但從另一方面來說，他的商人 DNA 卻不能有絕對的優勢。創業，尤其是網路創業，畢竟是在找那個尚未存在的商業模式，如果你太執著於眼前的利益，那從定義上來說，就不可能找到任何未知的東西。所以我把商人放在 40%，但除了商人，我認為一個創業者還必須要有 60% 其他的特質。

首先是工程師的特質。Engineers 是很理性的動物，我們的專長是發掘問題，解決問題。工程師尤其是容易溝通的，只要是情符合邏輯與科學的原理，通常就能夠說服我們。但工程師的缺點，就是想法太一致。如果把一樣的問題、一樣的客觀條件丟給一群工程師，你大概很難得到不一樣的答案。所以工程師的執行力是創業者必備的，但只有商人和工程師加起來卻也還是不夠。

你必須還要有藝術家的 DNA。相對於工程師的理性，藝術家擁有的是感性。相對於工程師的按部就班，藝術家往往是偏執、理想、充滿熱情的。他能夠在所有 (已知) 條件都不利於他時堅持下去，也有勇氣去站著與全世界作對。而就像無數個成功故事中提到的一樣，這似乎是每個創業者必須經歷的道路，必須具備的能力。

我不確定工程師與藝術家該如何分配剩下的 60%，但我知道哪一個太多都不是很好，而且它們都不能超過商人的 40%，所以唯一合理的分配，就是 30% & 30%。因此，我產生出了理想中的創業者成份組成。

不過那只是最終的結果，達到奈許平衡時的分布狀態，但如果你對初創業者進行成份分析，大概會是這樣的結果。

他們的藝術家成份往往佔絕大多數，畢竟用工程師的角度去思考，出來創業不一定是解決問題最佳的方法。而用商人的價值觀去判斷，創業的獲利期望值更是遠遠低過去 Google 上班。但他們還是出來創業了，所以背後肯定有很大藝術家偏執、忠於自我的 DNA 在驅動。

但創業畢竟是在經營市場，所以從那邊，他們必須要慢慢學會如何當一個商人，同時不要失掉工程師的善與藝術家的美。這個成份轉換當然不是一瞬間的，像好酒一樣，它往往需要 2-3 年，甚至是 5-10 年的醞釀，過程中還需要很多的失敗、挫折來當酵素。

從這個角度去看，創業之路更是一個必須，也絕對是急不得的過程。幫助創業者越久，越發現重點不是「加速」，不是在多少個月內做出成績，重點更是陪著他們蛻變，和他們一起堅持到成功的那一刻，無論那需要多久。

___

別錯過我在 Facebook 上的更多創業分享

上次聊過工程師的生產力不應該用程式碼來衡量，因為他們的極致生產力，是在少寫幾行程式，而不是在多寫幾行程式。今天剛好又看到兩篇文章，可以用不同的面向延伸、解釋這件事情。

首先，是一位跑去日本教英文老師的前任軟體工程師，發現了寫程式和學語言間的共通性，他說：

這些工程師往往可以輕鬆的通過面試，但當他們真正開始工作，卻讓人大失所望。我讀了很多關於這個問題的研究，但當我越看它，就越發現這些「殘障工程師」，就好像我的英語學生一樣。他們有 5,000 字的詞彙，書裡面的每一個文法都背得滾瓜爛熟，但是就是說不出一句話。

我的理論是，程式其實就跟寫作沒什麼兩樣。多數的程式概念上一點都不難 (跟你想的不一樣)，我們搞不好的原因往往只是寫作能力太差。大部分的工程師根本就不是「流暢」的語言使用者，也沒有努力想要讓自己變得流暢。他們不去多讀讀他人的程式，看不懂也不會使用「成語」，更不會「用程式語言來思考」。這些人寫出來的程式很糟，因為他們根本就是電腦語言的三歲小孩，卻試著要寫一本小說。

所以如果你是工程師，多讀讀別人的程式碼，是很重要的，就跟學習寫作一樣。

相反的，如果你的程式想要讓人家讀懂，那 documentation 是非常重要的。GitHub 工程師 Zach Holman 發表了一篇非常棒的文章，詳細解釋了為什麼你要寫文件，怎麼寫。

1. Documentation 是個人的 — 相信我，你以後一定會回來改這些程式，如果要讓未來的自己更快進入狀況，把事情搞定，今天請你務必把東西寫清楚。
2. Documentation 是清楚的 — 如果你不把你推出去的程式碼講清楚，那根本是在幫自己找麻煩，以後一定會出現一堆 bugs、困惑的同事，最後搞得自己更累而已。
3. Documentation 是可以測試的 — 因為你必須要把程式的邏輯解釋清楚，這讓你重新思考自己的寫出來的東西是不是符合原始精神，有沒有更好的方式。為了不在寫文件時陷入無法解釋的難關，這也迫使你簡化每一個功能，把一個複雜的東西切成好幾個功能。
4. Documentation 是可以比較版本的 — 好的文件可以讓版本間的比較更容易，也讓團隊合作更有效率。
5. Documentation 是行銷 — 透過好的文件，可以讓下載你軟體的人更容易開始使用，這也大大提升了轉換率。
6. Documentation 讓你在床上表現更棒 — 這點 Zach 還在驗證，不過他認為建立好的文件讓你很酷，這應該對自信會有幫助。

以上，希望這些觀念可以幫助你們更了解工程師、效率和生產力之間的關係，加油！

(Image via zooboing, CC license)