—“聽說我們的PM被綁票了！綁匪要我們送200萬不然就要澆汽油把他燒死！你要不要捐點？好多人都捐了?！? —“一般是捐多少？” —“不好說，有捐10升的，也有捐5升的?！?/p>
使用“碼農”這個說法純粹是一種個人習慣。我有不少程序員朋友，這個稱謂并不包含任何貶義或侮辱。事實上，他們也經常自稱“碼農”——有時還自稱“碼畜”，這種惡習你就當沒看見好了。
小時候，90年代初，我學過一點編程。當時用的機器是Laser310，語言是BASIC。后來上大學，學了一陣Fortran；2000年網絡時代開啟，研究了一點HTML、Javascript；再往后因為搞數值策劃要用Excel，還用過Excel里的VBA。我的主業(yè)是PM也即產品經理，但粗通一點最基本的編程算法，這是個大前提。
接下來插播個老笑話：
“聽說我們的PM被綁票了！綁匪要我們送200萬不然就要澆汽油把他燒死！你要不要捐點？好多人都捐了?！?/p>
“一般是捐多少？”
“不好說，有捐10升的，也有捐5升的?！?/p>
這個老段子說明PM與碼農之間的干群關系那是相當緊張了。作為粗通編程的PM，我有時會（跳出工作）思考一個問題，那就是編程到底有多難？如果難，有可能是難在什么地方？（還有一個問題就是“我要怎么學會編程，成為一個內行，然后再抽打這幫碼農干活”，不過僅是想像）這種思考的歷史相當悠久，有時會促使我去自學編程，但往往由于沒有專業(yè)指導、缺乏實例，最后不了了之。
恰好最近出了個游戲《Human Resource Machine》，中文或可稱為《碼農游戲》。作者號稱……（省略200字常見忽悠）基于上述原因，我斥資人民幣30元，全款購置了這款游戲。玩了2個小時后，獲得一些感受，現在與大家分享。
第一個感慨是“需求”。我玩的是英文版本——下載下來就是英文，沒找到在哪改語言選項。反正也勉強能看懂，就湊合著玩了（據說中文版是機翻，比英文版還要難懂）。但是人生總有不能湊合之處，比如在第4關就整了半天過不去，最后發(fā)現是讀常量后取常量的順序不對……
這讓我想到碼農們平時的抱怨：你們PM連個需求都提不好！天地良心，我本人做的策劃和提的需求都無懈可擊，因為我是編輯出身，“描述”于我而言不過是雕蟲小技——但我也確實看過一些略顯猙獰的需求文檔。假如一定要下個結論，我覺得市面上起碼有70%的需求文檔、產品文檔是有問題的，強于Sense，但輸在Description。
為了避開這個問題，很多情況下PM提的需求是“下載xxx（APP名），然后照著抄一個！”這個段子經常被拿來調侃PM的無能。事實上在我們看來，效率最高的方法就是最好的方法；所以如果這種方法程序員能理解，那也沒有什么不可以，反正也沒有更好的方法。但不管怎么樣，需求，或說為了實現需求而必不可少的溝通，是PM和碼農之間最重要、同時也是最困難的事。
本著有限的編程知識，我曾作出總結：算法就是條件跳轉+定義過的數組存取。在這么說的時候，我并沒有意識到自己用的是何等高級的語言——BASIC很高級嗎？好像還真是，因為Laser310上可以跑匯編語言（我不會，學長們用過）。當我開始玩這個游戲時，才明白BASIC、C、Python是何等方便……
舉個例子。游戲里有一關要求你取兩個數；如果它們同為正或同為負，輸出結果0，否則輸出結果1。這聽起來非常容易且清晰，if a*b=|a*b| then print 0 esle print 1，一句話的事（||是數學上的絕對值符號，函數形式是Sab()）。在不同語言里它的寫法可能略有區(qū)別，但意思是清楚的。問題是，這一關里根本沒有乘法讓你用！不但沒有乘法，當然也沒有絕對值函數，沒有條件判斷或說不支持這個格式的條件判斷……你定睛一看，除了最后輸出的部分，這整行命令里沒一條是能使的，好比讓你造條航母但不給螺絲刀，你得徒手去把螺絲都給擰上……
后來我是用一個三叉判斷實現了目的：英語不好的人想不出一個意思怎么說，就用一個從句代替，最后句子里從句套從句像野生糖葫蘆。算法思路不清晰的人會大量使用條件判斷，最后整個程序里滿是條件判斷和跳轉，是數碼版野生糖葫蘆。這樣做的惡果，下面馬上就要講到。
游戲大概有30多關（我現在玩到19關），過關條件是完成經理的要求，但還有2個獎勵目標（類似手游里的三星過關，打不到三星就掃蕩不了，這么說你應該懂了），分別是命令數和步驟數。前者要求你盡可能少用命令，多用循環(huán)；后者相反，希望你提高效率少用循環(huán)。這兩個目標一定程度上可以說是對立的，所以你往往需要寫出兩種風格截然不同的程序，分兩次來完成。
還有一種可能就是兩個目標都完成不了，對于那些半路出家的PM尤其如此——我寫的程序，我自己都覺得臃腫而笨拙。我知道它一定能跑通，也知道它一定能實現需求，但同時我也知道它效率極低：游戲提示若只用30步實現就可完成任務，而我用了60多步！這個事情告訴我們老程序員的意義，那就是提高程序的整體效率。
諷刺的是，這種提高很多時候并不能體現出價值。王小波講過一個故事，那是他在美國跟著導師（又叫“老板”）做項目、寫程序的故事。第一個程序寫完了，特別短，老師驚呆了。結果一跑之下居然沒問題，老師大喜，但最后算錢時他的錢最少，原來程序是按行算錢。這可把他氣壞了，第二次他就拼命往長里寫——我們知道這相當簡單——結果程序交上去老師一看長度，根本沒問能不能跑，直接給他退回來了。
（這事情還有個后續(xù)。他被老師整得不輕，敢怒而不敢言，就把程序名取成"Caonima1"，“Caonima2”這樣。老外不發(fā)“C”這個音，導師老是念成“Kaonima”，他就糾正，不是Kaonima，是Caonima?。?/p>
確實“效率”二字很難具現化為KPI。評論車的好壞，一個標準是“百碼加速”，加速時間越短就越好，但程序卻沒有類似的“百毫秒響應值”，即便有，在整個產品流程里究竟占多大比重也值得懷疑。我看過一些關于傳奇程序員約翰·卡馬克的故事，內中提到他如何用一個天才公式進行顯卡的多邊形貼圖運算。毫無疑問，卡馬克是一個出類拔萃的程序員，碼農之王。但說實話，他做的引擎不錯，他出品的游戲（比如Doom4）卻相當垃圾；他知道怎么讓畫面精美，卻無法設計出有游戲性的關卡，更不知道怎么搞市場營銷。他是碼農之王，不是游戲制作人之王，更不是CEO之王。
不幸的是，今天的行業(yè)里，經常要求一個人同時成為碼農之王，制作人之王，CEO之王，甚至包括美術之王、市場之王、運維之王乃至成本控制之王。更不幸的是，一位碼農如果真的精于Coding，他就難得在其他方面亦有建樹。小團隊的悲哀，一部分就在于此。
（反例肯定是有的。比如那位在常用表情里睜大眼睛對你說“想想如果不花錢你會變得更強嗎”的人，他就是碼農出身。但話說回來，這樣的例子相當少?。?/p>
還有一點小感受是UI方面的。這個游戲非常不友好地禁止了路標（或許是因為匯編語言特性），從而BASIC語言里極為方便的“Goto 行號”用法不可能有了，你必須手動把箭頭拖曳至目標位置。當條件跳轉超過5個時（由于沒有循環(huán)，這個數量很容易達到），你會看到滿天都是跳轉軌跡。另一方面，屏幕所能顯示的命令行有限，在拖動時又可能誤操作、拖到跳轉軌跡。而你根本不可能記住“那個箭頭之前在什么位置”，于是唯一的解決方案就是拉到最下去使用游戲提供的“Undo”按鈕，但這個拉動本身又可能觸發(fā)其他的誤操作……
我的意思是，一個好的編輯器很關鍵。我現在用的Sublime Text是以前一個寫Python的好漢推薦的，當然我主要用它來做文字錄入（取代了以前用的Notepad）。編輯器具體要用什么，碼農朋友們肯定各有各的愛好，而類似的道理也可以應用在其他方面。就像我組電腦時，別的無所謂，但屏幕和鍵盤一定要選最好的。這個道理是這樣的：屏幕天天看，鍵盤天天打，不選好的那不是和自己過不去？CPU慢你可以少開幾個窗口，硬盤小之前下的片子你就勤刪一點，未必屏幕15寸的你還能在自己臉上架個放大鏡假裝是17寸？
找到工作中的“關鍵點”，也是一種能力。當然，這個能力的主要因變量是工作經驗。
現在我卡在第19關了。這關要求對4個量進行排序然后依次輸出，如果用BASIC來操作可能早已完成，但這該死的匯編……我現在寫到69行了，還有最復雜的一個情況沒有處理，最終結果應該會超過100行，這一定有什么地方不對：游戲給了Bump+、Bump-兩個操作到底要怎么用？昨天玩到3點鐘含恨睡下，今早8點起來之后還一直在思考——這游戲是有點燒腦子。有鑒于此我想起另一個關于碼農的段子：
“昨天晚上我走的時候問你什么時候好，你不是說下班前一定給我？怎么今早來了你還沒弄完？”
“我也沒說我已經下班了?。俊?/p>
* 本文系作者投稿，不代表觸樂網站觀點。
