"Mark Zuckerberg’s Letter to Investors: ‘The Hacker Way’Code wins arguments."
工作時，我們常常會花時間在討論、或是說辯論、亦或是只為堅持己見而吵架討論。
從以前到現在，我一直都很重視自己所做的東西。越是在乎越容易陷入迷思，越是迷思更討論不清楚。不了解，是許多失敗會議的主因。
"Code wins arguments" 讓我反思。花這麼多的時間虛擬的討論，只要花一點時間，攤開程式碼來順過流程，問題便迎刃而解。能與人"溝通"與"講清楚"的能力，此能力並非普遍與生俱來的，是練習就能學會。在軟體設計裡面，不斷的加強溝通一環我認為非常重要。
下圖是最近滿流行的，在達成同樣功能下，不同的類的程式設計師寫法。在裡頭，我看到在程式內的溝通，是一個軟體未來能高速成長的關鍵因素。
常常看到軟體工程師不夠。明年要開 1000個職缺，大聲疾呼必須要重視資訊人才數目的培養。現在人才真的不夠多，政府請注意等等。
主要的因素在於容易修改、可擴充的程式碼過少，工程師重寫相同功能的次數過多導致。我認為這不是工程師的問題。而是組織內，有沒有把"程式"本身當成資產。
在寫每段程式時，一定有不可分割的部分(Lagacy)、可模組化的部分(Modulized)、可提供外部資料(Application Interface)。說穿了，就是用 Framework的概念，設計軟體。
在追求個人的程式精簡之美的反義就是只有自己看得懂。開發團隊舊人會離開、新人會加入。我認為從最底層的程式起，做架構管理是有其必要的。開發團隊建議迭代(iteration)的制訂團隊內，開發程式的共識、設計方法、注解、Commit log等，這些規定形成一個開發系統不斷成長。強調只做出功能的公司，稱不上軟體公司，只能是 Hackerathon罷了。
軟體開發跟硬體時代最大的不同，就在於此"軟體資產"是可以累計的。一次次的開發，多花一點時間，保存或進步自己的程式，才能築起通往成功之路。
編按：透過文章，把自己的想法整理、讓別人看得懂。果然是需要練習的。
此句子原文出處：
http://www.wired.com/2012/02/zuck-letter/
圖片原文出處(Picture reference)：
http://9gag.com/gag/apqNxqD/code-written-by-a-student-at-a-hackathon-at-a-startup-at-a-large-company-by-a-math-ph-d-and-your-cat
http://www.wired.com/2012/02/zuck-letter/
圖片原文出處(Picture reference)：
http://9gag.com/gag/apqNxqD/code-written-by-a-student-at-a-hackathon-at-a-startup-at-a-large-company-by-a-math-ph-d-and-your-cat
