開發與研發

無意間看的一篇文章,讓我思緒有了些波動...

 

 

同樣是寫程序,不同的崗位工作內容不一樣,對程序質量以及工程師的要求也不一樣。程序開發大概可以劃分成兩類:開發和研發,相應也就有開發工程師和研發工程師。很多人覺得做開發和做研發沒什麼區別,“都是一樣對着電腦寫程序啊”,但其實這兩者是完全不一樣的,下面我想拋開公司對員工的期望、社會對工程師的需求等其它因素,單純從國內互聯網行業“工程師個人發展”的角度來說一下我個人對這兩類工作的看法。

開發

開發一般是指產品開發,開發工程師直接爲產品貢獻代碼。每個公司都有自己的產品線,拿 Google 來說吧,它有 Gmail, Chrome 等產品,每個產品都有很多開發工程師在後面支持,這些產品的開發、維護以及升級都是由相應的開發工程師負責的。由於開發工程師的工作直接關係到產品的質量和在線情況,所以開發工程師的責任是很重的,他可能經常爲了下個版本的發佈而加班,爲了產品的故障不得不在休假的時候打開電腦工作,甚至在過年的時候都會接到領導的電話。所以你看到那些總抱怨加班太多,總是說自己是“IT民工”的,大部分都是開發工程師。在工程師當中,大部分人都是做產品開發的,畢竟公司都是要靠產品盈利,招聘的大部分人也要直接爲產品服務。

做開發是很辛苦,但也有好處,因爲需要對產品線負責,所以會是公司的核心,裁員對你威脅不大,如果你負責的產品恰好又是盈利產品的話,那麼加薪、獎金、集體出遊等福利都不會少。如果你足夠幸運地加入了一家快速發展的創業公司,說不定一下子就發家了。還有很重要的一點是,作爲產品的開發人員可以看到自己做的東西被那麼多人使用,那是一種莫大的鼓勵和肯定。

苦悶的開發工程師

儘管我很尊重開發工程師,但是我不得不承認,在國內大部分的公司,做開發工程師是沒有前途的。首先,從微博到開心,有多少國內的產品不是山寨的?這也罷了,最噁心的是有一些產品經理連產品設計圖都懶得自己畫,直接去截取別人產品的圖片,假如我是一個人人網的開發工程師,每天看到產品經理把 Facebook 新上線功能的截圖拿過來讓我做,你讓我如何對產品有榮譽感和認同感?而如果一個開發工程師對自己做的東西沒有榮譽感和認同感,那麼他堅守自己的崗位要麼是因爲公司給的錢多,要麼是因爲他還沒有找到下家。我個人認爲,做開發最大的一個好處就是可以親手實現一個“自己的作品”,就算平時很累,但最後完成它的時候也還是會無比滿足,這點被剝奪了之後,和飯店打工的服務員有什麼兩樣?不一樣是爲了餬口嗎?

我不知道別人怎樣,但我自參加工作以來就一直糾結於此——甚至開發的大部分產品都不好意思寫上自己的名字;直到前不久有機會去做一個公司內部使用的平臺,才終於有個作品讓自己覺得滿意。相信很多開發工程師參加工作之前都對互聯網上很多諸如Gmail, Facebook 等優秀的產品耳熟能詳,自己也常夢想做出那樣的產品,但萬萬沒有想到的是,工作之後要學習的第一課就是“不要對自己做的東西有感情”——有了感情你就不願意做廣告彈窗,不願意看到它下線,不願意爲了短期利益傷害用戶。與此同時,你還要繼續聽產品經理和老大們滿懷激情地說“我們一定要讓用戶喜歡我們的產品”。一個連開發工程師本人都覺得無聊的產品如何讓用戶真正喜歡呢?拿搜索巨人來說吧,Google 把社交網站看作是某種形式的娛樂而不是有用的工具,所以它會在社交領域失敗,再牛的技術也無法遮蓋情感上的空白。不過話說回來,這好像對於國內大部分的公司都不是問題,因爲它們做一款產品只是想從用戶那裏拿到錢,如果以後用戶流失了就下線,然後再開發一個新的。他們要的不是用戶的長期感情,而是一夜情,開發工程師就是一夜情的工具。

其次,國內幾乎所有公司的技術流程和技術積累都做得很爛,大部分都只是片面地追求開發速度。我們在大學裏受到的教育是“文檔和註釋很重要”,工作之後才發現文檔和註釋是很稀有的東西,只有特別負責任的工程師纔會擠時間去寫。有一個很有意思的現象是,國內很多產品發佈之後會特別自豪地說“XX 是我們開發團隊在時間緊迫的情況下,封閉開發了X 天就完成的!只有最牛的工程師才能創造這樣的奇蹟!!多少個凌晨,XX寫字樓上只有我們辦公室的燈還亮着……”,然後你會覺得“好感動啊”,但冷靜下來想一想,這種拼命趕工做出來的東西質量會過硬嗎?拋開產品質量不談,沒有時間寫文檔、沒有時間寫註釋、沒有時間做 code review, 沒有時間做階段總結……沒有了這些,作爲一個開發工程師你通過這個項目可以提升多少呢?所以好多開發工程師一開始是“代碼民工”,過了幾年還是“代碼民工”,而一個人年富力強的時間又有幾年呢?怪不得那麼多人說工程師和妓女一樣,都是吃青春飯的。

發展方向

我個人認爲,國內的開發工程師大概有三個發展方向:1.做管理。 2. 去做架構等與產品關係不那麼緊密的研發。3. 提升其它方面的能力,做 “A+ Player”,然後自己創業。我對管理沒有研究,也沒有興趣,這裏就不說了。研發我會在下篇中細說,這裏主要說一下第三條。

爲什麼要關注代碼之外的事情

如果你只會埋頭寫代碼,那麼代碼寫得再好也可能不會是一個好的開發工程師。做開發不是做學術研究,你的任務不是去鑽研技術,而是利用自己的技術把產品做出來。儘管技術能力是基礎,但如果無法把能力很好地應用到開發當中,那麼你在團隊中就沒什麼價值。舉個例子,如果你不能很好地理解產品需求,那麼就會根據自己的理解去做技術方面的架構和編碼,等到後來發現了再去修改就特別麻煩,這個時候技術能力強反而成了壞事,南轅北轍的故事我想大家都聽說過。

很多開發工程師屬於那種“很本分”的人,從來不會提出意見,不關心產品形態和細節,只是去做產品經理提出的需求。我覺得別人把工程師叫做“代碼民工”也就算了,但是工程師對自己做的東西完全沒有看法,那就是甘心淪落爲民工了。這也有文化的原因,國內的公司都喜歡那些不愛抱怨的員工,因爲他們聽話而且符合中國傳統的價值觀,但我更喜歡那些愛抱怨並且抱怨得有道理的人,因爲國內(不只是互聯網上面)粗製濫造的東西實在太他媽的多了,不抱怨纔不正常,有不滿纔會去思考如何做得更好。

曾經聽到有人談論如何管理技術人員的時候說:“管理技術人員很簡單,找一個比他們都牛的人就行了。” 這個人很瞭解工程師的脾氣。工程師去判斷其他工程師的時候,往往只看他的技術能力,覺得誰的技術好誰就最牛,其它的都無所謂。沒錯,技術牛的工程師寫的代碼質量很高,但這只是一個方面而已,判斷一個人在團隊中是不是“很牛”要看他對團隊對產品的整體貢獻,而不是他的個人能力。他能很好地理解產品需求嗎?能很好地理解設計師的意圖嗎?和團隊其他成員溝通順利嗎?寫出的代碼方便測試嗎?會對產品提出好的建議嗎?……這些都是判斷一個開發工程師的標準,整體素質越高在團隊中的價值也就越大。

所以要想做一個好的開發工程師,就要在寫好代碼的同時努力提高其它方面的能力。我知道大部分的工程師都喜歡和機器而不是和人打交道,所以遇到和產品經理、設計師以及 QA 等部門協調溝通的時候就皺眉頭。協調溝通確實是一件鬧心的事情,但從另一方面來說,這是開發工程師的一個得天獨厚的優勢:你可以深入接觸產品生產線上的所有環節。需求評審的時候,你可以瞭解產品設計;開發界面的時候,你可以瞭解到視覺和交互設計;測試的時候,你可以瞭解到產品測試的細節;上線的時候,你也可以多觀察 Ops 同事的操作。如果你可以在協調溝通的時候學會換位思考,多從對方的角度看問題,多想一下“他爲什麼要這麼做”,那麼不知不覺就會對各個領域有一些瞭解,進而發現原來每個領域都大有學問,就不會因爲周圍那些學藝不精的人而輕視他們所在的領域。

學習設計

對於工程師來說,測試和上線都是技術性的工作,和開發有很多相通的地方,而產品設計、交互設計和視覺設計等設計領域則比較陌生。對於自己不瞭解的東西,我們的看法往往會趨於兩個極端:要麼是看得高深莫測,要麼是看得一文不值。其實對於大部分的東西,只要不笨並且願意下功夫學習,總是可以學會的。儘管達到大師的水平可能需要傳說中的“天賦”,但做到中等水平並不是特別困難。關於設計領域我一直在斷斷續續地在學習,到現在可能連略窺門徑也算不上,這裏只是說一下我個人對設計的理解和心得,供大家參考。

產品設計

產品設計看上去比較簡單,因爲只要清楚自己想要做什麼,那麼自然可以慢慢勾勒出產品的形態和功能。要做好產品設計,就需要平時多下一些功夫,多研究一下互聯網上那些已有的產品,另外還需要多看一些諸如社會學、歷史等“閒書”,舉個例子,假如你想開發一款針對臺灣用戶的產品,那麼瞭解一下臺灣的文化肯定是有必要的。總之,學習產品設計是慢功夫,沒有什麼速成的捷徑,只有一點一滴地不斷積累才能培養出敏銳的產品意識和深刻的洞察力。

工程師學習產品設計有一個優勢,那就是設計出來的產品是自己親手實現的,你可以在實現的過程中不斷重新反思原來的設計,然後加以修改和完善。這就好像寫文章一樣,很多時候你寫東西的時候並不清楚自己具體要寫什麼,但只要是下筆開始寫,寫着寫着就會發現新的想法,寫作的過程同時也是思考的過程。寫作和寫代碼很像,它們不僅可以表達想法,還可以創造想法。

視覺設計

很多工程師聽到視覺設計會立刻退避三舍,覺得自己“不會畫畫”、“不懂配色”是不可能學習視覺設計的。誠然,視覺設計是需要更多藝術方面的基本功,要完全掌握需要長期的訓練,但我們還是可以從簡單的學起,慢慢培養對設計的感覺。我個人在這方面所知非常有限,但是對視覺設計中的完美主義印象深刻。

編程的時候,如果你的某行代碼多了一個空行可能不會有什麼問題,但在視覺設計中差了 1 個像素或者 10% 的透明度就是不可容忍的,很多設計師要求的都是 “Pixel-Perfect”——像素級別的完美。如果你不苛刻地追求完美,幾個這樣的“小瑕疵”就可以把整個作品毀掉。在我沒有接觸過視覺設計的時候很難理解這一點,切頁面的時候並不會特別仔細地去看設計圖,而且爲了降低技術難度會想當然地篡改設計師的意圖,比如把一些微小的漸變用純色代替,這是很無知的做法。所以當設計師要求你做一個 1px 的修改的時候,即使會花掉你幾個小時的時間也要聽他的——只有這樣纔可以把界面做到百分之一百的完美。當然,設計師自己做不到完美另當別論。

此外,作爲一個頁面設計師,從職位名稱上來看他的最終作品應該是頁面,而不只是視覺效果圖。所以我覺得頁面設計師應該精通 CSS,只有自己纔可以精確實現自己的設計意圖。對於那些沒有受過設計訓練的工程師來說,很難注意到頁面上色彩、字體和漸變的細節,讓他們精確實現一個設計師的意圖幾乎是不可能的。精通 CSS 對於頁面設計師來說並不算一個過分的要求,很多國外的設計師甚至可以自己用 PHP 寫出產品原型,相比之下,國內的頁面設計師進化得實在太慢了。

交互設計

交互設計是有關行爲的設計,它更關注如何讓產品更好用。舉個例子,網頁中一般都有很多超鏈接,當你把鼠標移動到超鏈接上的時候,鼠標形狀會變成手型,暗示它是可以點擊的,而且訪問過的超鏈接和普通超鏈接的顏色是不同的,這樣就很好地引導了用戶行爲。

之前我一直把設計和“視覺設計”等同起來,但在深入瞭解了之後發現,對於互聯網產品來說,交互設計要比視覺設計重要得多,而且交互設計相對於視覺設計也更加有跡可循,對“感覺”要求沒那麼高,工程師完全可以把重點放在交互設計上。如果交互設計做得好,視覺設計遵循一些標準,那麼完全可以做出一款“不難看並且好用”的產品。沒有人特別誇讚 Google 的產品“好看”,但它們都特別好用,Google 注重的是易用、快速,用戶體驗是很棒的。

互聯網行業的大部分頁面設計師(Web Designer)都是學習平面設計出身的,但我覺得網頁和軟件設計更像是“顯示器裏面的工業設計”。很多平面設計師設計出的頁面很好看,好像海報一樣,非常適合打印出來,但往往對交互方面重視不夠。不太好看影響不會很大,但不好用就沒有辦法留住用戶,而且有時候太注重外觀的視覺效果反而會分散用戶的注意力進而影響產品的使用,這種 “eye candy” 是糟糕的設計。現在專門培養交互設計師的機構不多,我很希望對互聯網有興趣的工業設計師們到這個行業中來。

關於設計我就說這麼多,以後有機會再另外撰文專門探討這些主題。值得一提的是,沒有人可以真正把設計和開發全部精通,如果深入到細節,無論設計和開發都會佔用你大量的時間和腦力。單從設計來說,需要掌握的就有顏色、字體排印(Typography)、排版(Layout)、交互設計等,其中每一種技能又涵蓋無數細節,真的是要皓首窮經纔可以在其中的某個領域成爲大師。不過,即使你對這些知識只是有一個大致的瞭解,以後在看一款產品的時候也可以從功能、交互、排版、頁面代碼、整體性能以及URL語義化等各個方面進行全面而細緻的分析,明白它哪裏做得好,哪裏做得不好,而不是在那裏想當然地說“真酷”或者“狗屎”。真正瞭解什麼是好的什麼是差的,自己做東西的時候纔會心中有數。

一專多能的好處

很多人可能會說:“一個人要是可以把所有事情都搞定,那還要其他人幹嘛?我更相信團隊的力量。” 沒錯,一個人就算從設計到開發都精通,如果只有他一個人做東西,開發效率也不會高。但是若你真的花心思去了解那些“與代碼無關的事情”,你就會在寫代碼的時候更多考慮到產品經理/設計師的想法,對產品經理/設計師疏忽的地方也可以及時提醒,讓自己真正地融入整個團隊。目標並不一定要實現,它是用來指明方向的。開發工程師提高自己的產品意識和設計能力絕對不會是白費心血,不然的話你就只是一個實現產品的工具。你只會回答別人提出的問題,而好的問題要比好的答案有價值得多。

當你各方面能力提高得差不多的時候,應該就可以出來創業了(注意,我說的是創業,不是去創業公司打工)。因爲對各個領域都有一定的瞭解,平時也經常接觸到各個領域的人,那麼在創業的時候你就很清楚自己需要什麼樣的產品經理/設計師,知道具有什麼樣能力的產品經理/設計師纔是最好的,這樣就可以從一開始就保證團隊的質量和氣質。很多互聯網的業界前輩都說過“要招聘最好的人”,但問題是你如何判斷一個人是不是該領域最好的呢?如果一個人對程序和設計一竅不通,滿腦子都是商業運作,你覺得他有可能找出最好的工程師和設計師嗎?有一次和一個創業公司的CEO聊天,他和我講他們“只招聘 Geek”,後來我才發現他其實根本不知道什麼是 Geek,只是不知道從那裏聽到 Geek 這個詞,他真正想要的應該是那種只知道寫代碼願意沒日沒夜任勞任怨給他當牛做馬的人。國內大部分的創業公司就是這樣,老大們喊着技術密集型的口號,實際上做着勞動密集型的事情,金玉其外,敗絮其中。你可以和他們不一樣。

我自己並沒有創業的經歷,也沒有創業的打算,所以對創業的理解可能很片面而且天真。但是我相信,找到最好的人永遠都是關鍵,不然即便後來成功了,也不過是多了一家靠人數取勝的血汗工廠。假如你選擇成爲移動互聯網的獨立開發者,對一個產品各個環節的全局把握也是有必要的。如果一個團隊的每個人都能獨當一面並且可以很好地理解其他人的意圖和專業技能,就算最後在商業上失敗了,那也會是一個幸福的團隊,比那些除了盈利之外找不到任何亮點的團隊好太多。

對產品經理的偏見

在“開發”這個小節的最後,我想多說一點自己對產品經理這個角色的看法。在國內絕大多數公司,開發工程師的作用就是把產品經理的想法以代碼的方式寫出來,“代碼民工”這個稱呼倒是很恰當。我對互聯網行業的產品經理們一直感到很奇怪:他們沒有能力把自己的想法實現出來,但是卻幾乎總是認爲自己比其他人更理解產品;當工程師對產品提出自己的意見的時候,他們往往會心中不屑但儘量保持禮貌擠出微笑說一句:“呵呵,工程師不是普通用戶”。一個產品本來就是需要很多人齊心協力一起完成的,產品經理和工程師的地位也是平等的,但是由於產品經理在工作流的上游,所以情況往往演變成工程師在爲產品經理工作。如果產品經理真的對產品負責也就罷了,可惜的是大公司的產品經理大部分是對KPI負責,小公司的產品經理大部分是對老闆的個人好惡負責,結果就是工程師跟在產品經理屁股後面做一些莫名其妙的事情。我接觸到的幾乎所有開發工程師都對他們的產品經理頭疼不已,據他們說,好的產品經理就像真正的愛情,是極爲稀有和可遇不可求的。

按照現在大部分公司的分工方式,產品經理是產品的總負責人。根據我個人的理解,產品經理之於產品,應該相當於導演之於電影,建築師之於建築。一個導演如果對拍攝一竅不通,那麼就很難控制鏡頭的表現力;一個建築師如果對建築材料和結構一無所知,就不可能把握建築整體的感覺。那爲什麼那麼多人會覺得產品經理可以不懂技術不懂視覺設計,只需要寫好文檔畫個框圖然後交給別人去做就可以做出好的產品呢?本來是一個需要對各個領域融會貫通最難做得好的角色,現在反而被很多人視爲清閒的差事,不愛幹活的人紛紛想要轉去做產品經理,實在是可悲至極。

我一直堅信好的工程師是不需要產品經理的。如果一個產品非要有一個什麼產品經理的話,Google 的很多產品都不會出現,DropBox 這種只招聘工程師的公司也早就完蛋了。很多偉大的產品都是幾個工程師想到一個點子然後慢慢做出來的,比如 Paypal 和 Google. 但需要說明的是,我討厭產品經理並不是說我推崇“技術導向”——無論怎樣產品都應該是讓用戶使用的,而不是用來炫耀技術的,只不過工程師不需要產品經理也可以設計好一個產品並且實現它。產品設計不是產品經理的專利。

想知道懂得設計的工程師沒有產品經理的時候可以做出什麼東西嗎?去看一下 Livid 做的 V2EX 就知道了。在國內,設計和代碼都有品味的網站可不多,我覺得 Livid 同學真是開發工程師的典範。

 

接下來我們說一下“研發”。

 

研發

相對於開發來說,我個人更喜歡研發一點。研發和開發的一個不同之處就是研發有更多的“研究”成分在裏面,也就是說研發的時候會有更多“光明正大”的學習時間,這對於那些對技術本身有追求的工程師來說是很有吸引力的。有一些人做工程師是爲了可以創造出好的產品,然後掙大錢或者改變世界;也有一些人做工程師是因爲對技術本身有興趣,想要好好研究。可以憑藉技術名利雙收變身成功人士固然很有吸引力,但不關心世事鑽研一些自己喜歡的東西也自有它的樂趣在。

如果說開發產品是“輸出”,那麼學習思考就是“輸入”,只有輸出沒有輸入整個人就會廢掉,完全淪爲一顆螺絲釘。在很多公司尤其是那種經常加班趕項目的公司,你每天都會處於很忙碌的狀態,腦子裏想的都是趕緊把指定的任務完成上線。因爲時間緊,所以你在開發過程中遇到什麼問題都是隻求解決,沒有心思和時間去搞明白爲什麼會出現那種問題,在這樣的工作狀態下完全沒有辦法積累工作經驗,看上去好像工作了五年,其實是工作了一年,然後重複了四年。

做研發一般不會直接爲產品貢獻代碼,更多做的是一些基礎架構或者實驗性的產品,所以它有幾個很明顯的好處。首先,很少開會。其次,沒有產品經理。第三,一般都會把質量放在第一位,時間不會特別緊。這是三個非常巨大的優勢,這意味着你絕大部分時間都可以安心學習、思考、設計、編程,幸福指數會飆升。如果你是做基礎架構,那麼代碼質量就會有硬性要求,你不得不寫得健壯、易用、鬆耦合並且易於調試,要花心思和時間細細打磨,對個人的能力提高、習慣養成和經驗積累都非常有幫助;如果你是做實驗性的產品,那麼你就有大量的機會和時間去調研最新的技術,而且最棒的是你可以在產品當中使用它們——這對於開發線上產品的工程師來說是不太可能的,因爲不成熟的新技術存在太多未知的風險。

此外,做研發對工程師的素質要求很高,需要很好的技術基礎、學習能力和研究能力——我把它看作是一個優點。從個人角度來說,我寧願一家公司招聘非常嚴格需要竭盡全力纔可以進去,因爲嚴格的招聘可以保證團隊所有成員的質量,不用擔心進去之後會“和臭棋簍子下棋”。既然選擇去做研發,那麼基本可以說明你是一個對技術有追求的人,也肯定希望周圍是一羣和你一樣的人,而不是連基礎知識都不夠熟悉的傢伙。只有這樣一羣“互相看得起”的人在一塊研究、學習、思考、切磋纔會其樂無窮,才能夠產生更多創意,做出好玩的東西。

當然,做研發也有不好的地方。只有大公司纔有研發部門,這些公司一般都已經上市或者員工已經很多,你不太可能有機會一夜暴富。當你埋頭做了幾年研發之後,某一天去參加同學會,發現大學時候那個數據結構不及格總是求你讓他拷貝編程作業的張三衣着光鮮四處敬酒。他所在的公司剛剛上市,因爲進去得早,現在他變成了百萬富翁而且榮升高層。於是你忽然開始懷疑自己當初的選擇,連學習和編程的樂趣都變得很不真實。所以,如果你渴望建功立業,那麼就不要選擇做研發,或者做幾年研發之後就出來闖蕩。成功需要的條件很多,而編程只是你的優勢之一,只有這一個優勢你需要太多的運氣纔可以得到你想要的。

不過,我們也可以換個角度看。“亂世放不下一張安靜的書桌”,現在到處都無比浮躁,有個地方可以讓你安安心心做一些自己喜歡的事情已經非常難得,多少人拼命掙錢就是爲了可以和你一樣做自己喜歡的事情。儘管那麼多人在叫嚷“搞原子彈的不如賣茶葉蛋的”,但總有一些人願意去追求人類最高財富——知識和藝術家般的技藝

本來做研發成就感會少一點,作爲一個 Twitter 的開發工程師看到那麼多人在用 Twitter 肯定會特別開心,相比之下某個在 Google 做基礎研究的工程師的成就感可能沒那麼強烈。不過在國內環境比較神奇,開發工程師非但成就感不多,反而會不少捱罵,還經常會有負罪感,相信做過郵件推廣和廣告彈窗的工程師都深有體會。這樣一來,研發工程師的“清苦”反而變成了一個優點,可以遠離很多“不得不做”的違背良心的事情。

相信很多工程師在入行之前是喜歡技術的,但是工作之後發現完全不是自己當初想象的那個樣子,然後就變得失望麻木,不再對技術有熱情。其實你可以把熱情延續下去,只不過要去做研發,而不是做開發。大部分由於興趣而不是生計學習編程的人,內心真正渴望的都是去做研發,只不過沒有人告訴他們開發和研發的巨大差別。現在不少大公司都有自己的研發部門,有一些還成立了自己的研究院,想要一直做技術的同學不妨嘗試一下。

如何選擇

很多人在大學裏之所以會選擇計算機爲自己的專業,並不是因爲自己對計算機和編程有興趣,而是因爲計算機是“熱門專業”,在畢業之後也渾渾噩噩地找了一份工作進入了這個行業,做着自己並不喜歡的事情;還有一些人則是畢業之後找不到工作,然後看到一些培訓機構的廣告就去報名學習編程,希望廣告上描繪的“月薪過萬”不只是一場夢。於是就有了越來越多的“代碼民工”,在形形色色的大小公司做着又髒又累的工作,只爲了“混口飯吃”。

我並不想批評這些人,畢竟在這個大環境下有着太多無奈,逼得我們無從選擇。對於這樣一些只想找一份好工作的人,是被騙到這個行業中來的。仔細回憶一下,這些年來我們看到的業界新聞,瞭解到的互聯網公司文化,大部分都是有關諸如 Google, Facebook 等國外公司的;我們平時學習和使用的技術,幾乎都是國外發明的。這讓我們深信互聯網就是那樣美好,那些激動人心的東西觸手可及,但請你關上電腦出門好好看一下週圍:這是在中國。互聯網沒有國界,但互聯網公司有。Google 和 Facebook 這樣的公司看上去離我們很近,我們每天也使用它們的產品,但國內的互聯網公司可能要幾百年之後纔會有那樣的氣質和文化。所以如果你不幸誤入了這個行業,還是及早打算改行或者轉型做管理比較好,這樣就不需要再學習自己並不喜歡的“枯燥”技術了。

對於那些“真的”對技術有興趣的人,要麼去做一個同時具備軟件設計能力的開發人員,也就是富有創造力的 Hacker;要麼去做一個自得其樂的研發工程師。雖然環境惡劣,但是任何東西都擋不住真正的熱愛。在這個幾乎人人都把金錢作爲衡量標準的社會裏,你真是得到了上天的眷顧,不僅能夠以自己喜歡的事情謀生,而且收入還過得去。

Hacker 是適合創業的,因爲他擁有創造一個產品的全部能力。電影《社交網絡》讓很多以寫代碼爲生的人產生了幻覺,Facebook 創始人傳奇般的經歷好像在向全世界宣佈:世界是程序員的。很多人只是激動地看到扎克伯格的技術能力,但是卻忽視了他的軟件設計能力和對產品細節的重視程度,好像只要埋頭編程就可以做出 Facebook。除了優秀的技術能力之外,扎克伯格的思考能力和創造力同樣出類拔萃,可以感受得到他眼裏的世界是不一樣的。我們的工程師又有多少人對生活中的事物有獨特而深刻的理解呢?獨立思考也應該是 Hacker 的必備技能。

很多工程師都覺得自己會編程,只是缺少一個“好的 idea”;很多非技術人員則覺得自己有一個“好的 idea”,但是缺少編程能力來實現。要做一個產品,好的 idea 和實現它的能力缺一不可。然而,我們可以看到最後成功的往往是那些非技術人員,因爲他們可以清楚地看到編程是一件可以學習的事情;而工程師們則往往天真地認爲好的 idea 靠的是“靈機一動”,不會有意識地培養自己的觀察能力和想象力。很多好的 idea 都是來自於平日對生活的敏銳觀察和思考,然後這些點在某個時候忽然連成了一條線,把它簡單地歸結爲“天才”是懶惰的做法。

“成爲一個 Hacker”和“做研發”,很難說二者哪一個更困難。Hacker 在技術上可以不是一流,但他運用技術創造產品的綜合能力肯定是一流的;而研發更注重技術上的造詣和理解程度,關注的是深度而不是廣度。如果想要做研發,那麼就要好好把基礎知識研究透徹,比如數據結構、算法和網絡協議等,不然很容易就會遇到瓶頸。我遇到過的每一位研發工程師都是技術上的大牛,在很多技術問題上都有非常深刻的見解;他們會從本質上分析問題,而不只是糾結於語言細節。

如果你想要通過自己的作品改變世界,那麼就好好提高一下編程之外的能力,做一個好的 Hacker;如果只想埋頭技術,就應該選擇去做研發。不過,無論是想要做一個 Hacker 還是一個研發工程師,都需要長年累月地不斷學習和思考。聽上去好像非常辛苦,不過每一個熱愛技術的人應該都會把學習和思考當作一種樂趣,而不是一種苦役。如果你無法享受學習和思考的樂趣,那麼還是不要在技術這條路上走下去了,你會活得特別累,並且毫無幸福可言。

在這個充斥着“代碼民工”並且缺乏“技術文化”的國度,我們只是關心怎麼樣可以活得更舒服,似乎忘記了編程本身所具有的迷人色彩。Joel Spolsky 說過,許許多多的人選擇編程,首要的原因就是,他們寧願將自己的時間花在一個公平有序的地方,一個嚴格的能者上庸者下的地方,一個只要你是對的就能贏得任何爭論的地方。此外,我覺得選擇編程還可以獲得最大限度的自由和獨立。因爲找工作的時候只需要憑藉自己的編程能力,所以不需要見人說人話見鬼說鬼話,不需要去結交權貴達人,不需要去爲了所謂人脈去混圈子,也不需要看到郵件列表裏有領導的郵件就去“頂”。平日裏寫寫代碼,其它時間喝酒吃肉,只交性情相投的朋友,武俠小說裏的暢快適意也不過如此。這種獨立和自由是極爲寶貴的,你可知道有多少人在醉酒之後哭喊“安能摧眉折腰事權貴,使我不得開心顏”?

所以說,編程這件事情關乎公平,關乎自由,關乎美。而作爲一個擁有編程能力的人,你可以親手創造美。只有藝術家纔可以創造美。希望有越來越多的人可以真正領會到編程的魅力所在,喜歡上這種藝術。正如 Raymond 所說,軟件設計和實現應該是一門充滿快樂的藝術,一種高水平的遊戲。你需要用心。你需要去遊戲。你需要樂於探索。

黑客事業之未來, 全依賴我們今日之創造。

最後推薦一些文章和書,這些文章和書大部分都與技術細節無關,它們討論的是基於編程的令人心醉的文化,也適合非技術人員閱讀。

1. 如何成爲一名黑客。所有學習編程的都應該多看幾遍這篇文章,至少把 Hacker 和 Cracker 的區別弄清楚。

2. 大教堂和市集。這是一篇關於 Linux 的經典文章。這裏需要聲明一下,我對那些 Windows 程序員沒有偏見,只是我覺得作爲一個以編程爲職業的人,如果不參觀一下 Linux/Unix 的深邃世界,未免太過狹隘。

3. UNIX編程藝術。這本書雖然名字叫做“編程藝術”,但裏面並不講授如何編程,而是全面展示了迷人的 Unix 哲學和文化。看完之後你會發現,那些看上去不修邊幅、整日對着電腦屏幕編寫代碼的邋遢程序員,對於美竟然會有那麼高的追求。“美在計算機科學中的地位,要比在其他任何技術中的地位都重要,因爲軟件太複雜了。美是抵禦複雜的終極武器。” 這本書的作者 Raymond 同樣是《如何成爲一名黑客》和 《大教堂和市集》的作者。

4. 黑客與畫家。這篇文章是 Paul Graham 寫的,文中詳細描述了黑客與畫家的相似之處。這裏所說的“黑客”和《如何成爲一名黑客》中所說的“黑客”略有不同,但你可以看到他們很多共同點。本文也已經被收錄到 《Hackers and Painters》一書,該書的中文版《黑客和畫家——Paul Graham文集》由阮一峯翻譯,應該很快就會面世,我十分期待。

5.創造者的品味。作者同樣是 Paul Graham,文章觀點獨到,見解深刻,每讀一次都有新的收穫。

6. 軟件隨想錄:程序員部落酋長Joel談軟件。這本書是 Joel Spolsky 的精華文章結集,作者寫文章寫得非常有趣,擅長講故事,前幾天我翻譯的那篇《程序員阿士頓的故事》就是他的手筆。本書由阮一峯翻譯,翻譯質量非常高,有興趣的可以先去試讀幾篇

7. About Face3交互設計精髓。本書是交互設計領域的經典著作,作者之一 Alan Cooper 原來也是知名程序員,被稱爲 “Visual Basic 之父”,所以這本書裏面對程序員的批評還是很中肯的。另外,書中“設計體貼的軟件”的核心思想非常棒,值得程序員好好閱讀和思考。

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章