有點失落、迷茫，差點在上班的時候發了火。原因是之前離職的一位同事，在代碼里不加注釋，而且百般偷懶，致使很多應該的驗證沒有驗證，很多應該考慮到的情況沒有考慮。因為是老員工，我相比他來說是新員工。氣勢上總是差那么一點點的，不敢去質疑前輩們的代碼。但是這樣下去，項目的質量一直提升不上去，講他還不能講，對於整個項目管理來說這樣的員工就是一顆定時炸彈。雖然是寫了代碼，恭喜還能跑，但是這是在浪費公司的資源，也是在浪費同事的時間。這樣的代碼以后維護起來，是要花費很大的代價的，是非常大的代價。然而現在已經是這種情況了，沒有辦法，只有錯上加錯，在慌亂的代碼里東湊西補，使得項目更加難以維護。
另外一個原因，就是項目的設計。從公司的管理層面上來講，管理是基於兩種前提的：信任，不信任。在信任的前提下，企業會給足員工的發展空間，讓員工去發展。但是就我所在公司與管理層的領導風格來看，是基於后者的。無論是基於信任還是不信任，其實都不是最主要的。就如同人性本惡與人性本善的悖論。關鍵的點在於，我們公司的產品設計人員是從程序員出身的，這一點就十分有必要說說了。
一個好的產品首先應該是一個好的消費者，其產品的設計應該是為用戶服務的。技術干煩了，就轉管理或者轉產品設計人員。優勢是有的，例如對產品的技術上可能了解的更為透徹，在產品的一些邏輯難點能夠給予關鍵幫助。但是弊端也是顯而易見的，就是程序員做久了，其審美能力的嚴重缺失，在乎數據、邏輯的正確性程度要遠遠大於界面的美觀度頁面的加載速度，也就是通常我們所講的用戶體驗。其設計產品的時候過分關注與邏輯層面，而忽視用戶層面。作為一名用戶來說，我是不管你的這個數據是連接多少張表去查詢出來的，也不管你攻克了什么難題，使用了什么牛逼的技術，你只需要在我需要的時候，將頁面以我察覺不到的速度展示在我面前就行了，一切要以用戶的角度去思考程序。其管理與設計要從大處着手，不能太過關注與某部分細節。
產品與程序分工不同，薪酬不同。所以如果做產品就不要再有程序的思維，以人的思維去考慮。程序思維可能讓你擁有解決問題的能力，但是也限制了你設計產品的能力。
產品設計人員的溝通能力是至關重要的。程序員整日埋頭敲代碼，言語表達能力交際能力都不如專業的產品設計。你有一個牛逼哄哄的設計，你自己很清楚它能夠達到什么樣的效果，能夠帶來多少的利潤。但是你表達不清楚，一切都是扯淡。跟你干活的程序員不知道，不知道你想要表達什么。以我做的產品為例，是關於大數據的整理加工。多表聯查，數據之間邏輯異常復雜。我做的時候雖然明白數據與數據之間的邏輯，但是僅僅是明白，但是這些數據有什么意義呢，我是不清楚呢。就如同我荒廢的大學時光，雖然每天都在上課，但是卻渾渾噩噩度日。顯而易見是非常低效率的。
好的產品設計一定要表達出來。你用不了聲情並茂的講演表達出來，那總可以用翔實的設計文檔來描述吧。口述是萬萬不可的，人在說話的時候，邏輯的嚴密性是非常差的，而卻不具備整理性。基本上是想到哪，說到哪。其中會遺漏很多的產品邏輯細節，這些設計人員是心知肚明的，就是忘記告訴你了。但是產品設計認為你們之間很有默契，你懂他。事實上，人與人之間言語的交流是非常低效的，據說不到50%。因此凡是產品設計一定要有文檔，這是確定的必須執行的。
產品設計人員要將產品設計給程序人員講解一遍，然后程序人員整理產品設計稿件給產品。再開一次會議來共同確認討論結果，一定要確認好，程序做的產品是否是設計人員想要的產品。一流的設計，三流的執行，會做的不入流。三流的設計，一流的執行，做出來至少要比三流強。
最后一些話是想對自己說的。低頭干活，抬頭看路。做程序員的時候，要先把本職工作做好，但是不要把所有的精力都放在程序上，程序只是實現一種服務的方法。生活中有很多的樂趣需要去體驗，我們還年輕，還要玩耍還要瘋狂。所以寫程序的時候，站在產品設計的角度去寫程序，往往會有一種暢快的感覺。至於那些名詞花哨的技術，身邊牛逼哄哄的大牛，我們要學會視而不見，因為這些我們都終將學會，這些大牛我們終將超越。所謂大牛，無謂庖丁解牛，無它，惟手熟爾。