Posts Tagged ‘productivity’

Resolution (res·o·lu·tion) 名詞：1. 決心，e.g. New Year’s Resolutions 新年計劃；2. 解析度，e.g. Screen Resolution 螢幕解析度

新年快樂！2012 終於來了，希望大家都在家人、朋友的陪伴中，渡過了一個難得的跨年週末。新的一年，有什麼計劃呢？我的 2012 目標很簡單，就是 Hack More Things、製造更多意外，然後喝更多咖啡。

或許你會問，為什麼我沒有一個「真正」的目標，像是把 appWorks 帶到中國，還是培育出更多個 EZTABLE 之類之類的？因為我認為那些目標根本沒有意義。

首先，能不能達到這些終點，有很大的成分是控制在別人的手上 — 外在環境的因素、時間點的因素、其他人的選擇等等。所以把這些固定的點當成目標，2012 年才剛開張，什麼都還沒做，你就已經把自己變成「不幸的人」，還自廢 Pivot 的能力。再來，大多數人訂新年目標的原因，說穿了只是為了要驅使自己更努力。那既然是這樣，為什麼不直接專注在更努力上面就好了。

所以，我說我們應該放棄對準「既定的終點」，把心思放在提升你的 Resolution，也就是你的決心、你的解析度上面。與其領完年終再出來創業，不如今天就開始動手測試你的 MVP。與其把新版本「做出來」，不如每個月都 Double 你的轉換率。累積 100 萬次下載，還不如動手提升 100 倍付費比率。與其導來 1,000 萬次流量，你應該讓 1,000 個人愛上你的產品，並且讓他們去跟朋友說。

成功需要的是日起有功、是累積、是進步、是學習、是不斷的修正。只要你能夠下定決心，今年的 366 個日子裡面，你沒有一刻會鬆懈，絕對比去年更努力 2 倍。我相信到了最後，你會非常滿意一年下來的收穫。

新年快樂，各位，預祝你們有一個非常棒的 2012！

(Photo via jliba, CC License)

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

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

這些工程師往往可以輕鬆的通過面試，但當他們真正開始工作，卻讓人大失所望。我讀了很多關於這個問題的研究，但當我越看它，就越發現這些「殘障工程師」，就好像我的英語學生一樣。他們有 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)

算起來軟體工程師大概是全世界最特別的一種職業，因為一個最好的 programmer 和一個最爛的 programmer，生產力相差至少 10 倍，有時候甚至可以高達 100 倍。這在其他的職業幾乎是沒聽過的 — 像 Jordan (麥可‧喬丹) 這樣強的籃球員，平均一場比賽的生產力，頂多也只是菜鳥板凳的 10 倍。即使是其他腦力、創意密集的行業，例如：IC 設計、建築、商品設計等等，生產力的差別也都是在 10 倍的這個級距，很少達到 100 倍的。

但又為什麼，當 Jordan 的薪水是 NBA 菜鳥的 100 倍，一流建築師的費用是菜鳥的 1,000 倍時，最好的軟體工程師，他們所賺得的卻往往連新人的 5 倍都不到？這個問題我一直想不透。它也不是壞事，因為很久以前當我第一次發現了這個現象後，我就學會要花 3 倍的價錢去顧一個 10 倍強的工程師 — 多麼划算的一個買賣啊！只是這件事情發生的原因，讓我非常的困擾。第一，它一點都不符合經濟學上「邊際效應遞減」的原則，你看其他職業，例如上面提到的 NBA，當你要雇用一個生產力 10 倍的球員，你必須付出 100 倍的成本。更重要的是，它一點都不公平，生產力 10 倍的人，就算沒有拿 100 倍的薪水，少說也應該要拿 10 倍的薪水。

直到昨天，讀了 John D. Cook (強‧庫克) 的這篇文章：「Why programmers are not paid in proportion to their productivity」，才給我了一個天大的啟發。

原來，這件發生的原因主要有兩個 — John 其實也是引述  Joel Spolsky (喬‧史波斯基，有名的 Joel on Software 作者) 的說法：

第一，雖然全世界的工程師優劣差很多，但是一間公司的工程師優劣卻是差不多的，因為一流的工程師不可能長期忍受跟一群蠢蛋一起工作，所以遲早會離去，於是久而久之這間公司的工程師品質就會趨向一致 — 這也就是為什麼你必須要花很多力氣在團隊上面。

而另一個更重要的原因，是一個好工程師的生產力，其實很難被察覺。如果你要判斷一個業務好不好，那很簡單，看看他的業績就行了。你要看一個建築工人的生產力，那也很簡單，看看他多快把房子蓋好就行了。以此類推，如果你要知道到一個軟體工程師的生產力，就看看他寫了幾行程式…

大錯特錯!!

一個軟體工程師生產力最高的時候，是當他可以少寫幾行程式的時候。當他可以用一些現成的東西，在很短的時間內拼湊出你需要的產品、解決方案的時候；當他可以跟你明確的溝通，不會浪費時間在開發錯誤的東西上的時候；當他可以正確的解讀數據，然後快速的修正產品的時候。這些…

通通不是用幾行程式碼去衡量的!!

問題是當一個優秀的工程師，快速的把產品湊出來，或者是很有效率的溝通時，老闆的反應是什麼？99.9% 都沒有辦法聯想到這就是極致生產力的表現，然後說：「嘿！我應該幫他加薪 10 倍！」所以，難怪好的工程師往往沒辦法獲得合理的報酬。

因此，如果你是創業團隊，該怎麼做？當然是用力的利用這個市場不平衡，把優秀的、在大公司鬱鬱不得志的工程師，通通都吸收到你的團隊來。而這也就剛好解釋了為什麼 EZTABLE 會說：我們在找的是「人」，而不是技術。

PS. 意猶未盡的人，這裡有一篇 Hackers vs. Coders 的故事。

PPS. 我超喜歡下面的討論，比文章本身還精采，大家千萬不要錯過。

(Image via scobleizer, CC license)