【聲明】此文爲轉載,只爲收藏。html
按:這幾天我一直在寫這篇東西,原本是成竹在胸,沒想到後來越寫愈加現本身在這個題目下有太多話想說,而以我如今的能力又不能很好地歸納總結,以致於越寫越長,文章結構也變得混亂,到後來修改的時候每次都要考慮很久才能下筆,因此決定拆成兩部分來發,以便閱讀。這篇寫得我心力交瘁,質量不算好,湊合着看吧。程序員
一樣是寫程序,不一樣的崗位工做內容不同,對程序質量以及工程師的要求也不同。程序開發大概能夠劃分紅兩類:開發和研發,相應也就有開發工程師和研發工程師。不少人以爲作開發和作研發沒什麼區別,「都是同樣對着電腦寫程序啊」,但其實這二者是徹底不同的,下面我想拋開公司對員工的指望、社會對工程師的需求等其它因素,單純從國內互聯網行業「工程師我的發展」的角度來講一下我我的對這兩類工做的見解。web
開發通常是指產品開發,開發工程師直接爲產品貢獻代碼。每一個公司都有本身的產品線,拿 Google 來講吧,它有 Gmail, Chrome 等產品,每一個產品都有不少開發工程師在後面支持,這些產品的開發、維護以及升級都是由相應的開發工程師負責的。因爲開發工程師的工做直接關係到產品的質量和在線狀況,因此開發工程師的責任是很重的,他可能常常爲了下個版本的發佈而加班,爲了產品的故障不得不在休假的時候打開電腦工做,甚至在過年的時候都會接到領導的電話。因此你看到那些總抱怨加班太多,老是說本身是「IT民工」的,大部分都是開發工程師。在工程師當中,大部分人都是作產品開發的,畢竟公司都是要靠產品盈利,招聘的大部分人也要直接爲產品服務。算法
作開發是很辛苦,但也有好處,由於須要對產品線負責,因此會是公司的核心,裁人對你威脅不大,若是你負責的產品剛好又是盈利產品的話,那麼加薪、獎金、集體出遊等福利都不會少。若是你足夠幸運地加入了一家快速發展的創業公司,說不定一會兒就發家了。還有很重要的一點是,做爲產品的開發人員能夠看到本身作的東西被那麼多人使用,那是一種莫大的鼓勵和確定。編程
儘管我很尊重開發工程師,可是我不得不認可,在國內大部分的公司,作開發工程師是沒有前途的。首先,從微博到開心,有多少國內的產品不是山寨的?這也罷了,最噁心的是有一些產品經理連產品設計圖都懶得本身畫,直接去截取別人產品的圖片,假如我是一我的人網的開發工程師,天天看到產品經理把 Facebook 新上線功能的截圖拿過來讓我作,你讓我如何對產品有榮譽感和認同感?而若是一個開發工程師對本身作的東西沒有榮譽感和認同感,那麼他堅守本身的崗位要麼是由於公司給的錢多,要麼是由於他尚未找到下家。我我的認爲,作開發最大的一個好處就是能夠親手實現一個「本身的做品」,就算平時很累,但最後完成它的時候也仍是會無比知足,這點被剝奪了以後,和飯店打工的服務員有什麼兩樣?不同是爲了餬口嗎?網絡
我不知作別人怎樣,但我自參加工做以來就一直糾結於此――甚至開發的大部分產品都很差意思寫上本身的名字;直到前不久有機會去作一個公司內部使用的平臺,才終於有個做品讓本身以爲滿意。相信不少開發工程師參加工做以前都對互聯網上不少諸如Gmail, Facebook 等優秀的產品耳熟能詳,本身也常夢想作出那樣的產品,但萬萬沒有想到的是,工做以後要學習的第一課就是「不要對本身作的東西有感情」――有了感情你就不肯意作廣告彈窗,不肯意看到它下線,不肯意爲了短時間利益傷害用戶。與此同時,你還要繼續聽產品經理和老大們滿懷激情地說「咱們必定要讓用戶喜歡咱們的產品」。一個連開發工程師本人都以爲無聊的產品如何讓用戶真正喜歡呢?拿搜索巨人來講吧,Google 把社交網站看做是某種形式的娛樂而不是有用的工具,因此它會在社交領域失敗,再牛的技術也沒法遮蓋情感上的空白。不過話說回來,這好像對於國內大部分的公司都不是問題,由於它們作一款產品只是想從用戶那裏拿到錢,若是之後用戶流失了就下線,而後再開發一個新的。他們要的不是用戶的長期感情,而是一 夜情,開發工程師就是一 夜情的工具。數據結構
其次,國內幾乎全部公司的技術流程和技術積累都作得很爛,大部分都只是片面地追求開發速度。咱們在大學裏受到的教育是「文檔和註釋很重要」,工做以後才發現文檔和註釋是很稀有的東西,只有特別負責任的工程師纔會擠時間去寫。有一個頗有意思的現象是,國內不少產品發佈以後會特別自豪地說「XX 是咱們開發團隊在時間緊迫的狀況下,封閉開發了X 天就完成的!只有最牛的工程師才能創造這樣的奇蹟!!多少個凌晨,XX寫字樓上只有咱們辦公室的燈還亮着……」,而後你會以爲「好感動啊」,但冷靜下來想想,這種拼命趕工作出來的東西質量會過硬嗎?拋開產品質量不談,沒有時間寫文檔、沒有時間寫註釋、沒有時間作 code review, 沒有時間作階段總結……沒有了這些,做爲一個開發工程師你經過這個項目能夠提高多少呢?因此好多開發工程師一開始是「代碼民工」,過了幾年仍是「代碼民工」,而一我的年富力強的時間又有幾年呢?怪不得那麼多人說工程師和妓女同樣,都是吃青春飯的。架構
我我的認爲,國內的開發工程師大概有三個發展方向:1.作管理。 2. 去作架構等與產品關係不那麼緊密的研發。3. 提高其它方面的能力,作 「A+ Player」,而後本身創業。我對管理沒有研究,也沒有興趣,這裏就不說了。研發我會在下篇中細說,這裏主要說一下第三條。ide
若是你只會埋頭寫代碼,那麼代碼寫得再好也可能不會是一個好的開發工程師。作開發不是作學術研究,你的任務不是去鑽研技術,而是利用本身的技術把產品作出來。儘管技術能力是基礎,但若是沒法把能力很好地應用到開發當中,那麼你在團隊中就沒什麼價值。舉個例子,若是你不能很好地理解產品需求,那麼就會根據本身的理解去作技術方面的架構和編碼,等到後來發現了再去修改就特別麻煩,這個時候技術能力強反而成了壞事,南轅北轍的故事我想你們都據說過。工具
不少開發工程師屬於那種「很本分」的人,歷來不會提出意見,不關心產品形態和細節,只是去作產品經理提出的需求。我以爲別人把工程師叫作「代碼民工」也就算了,可是工程師對本身作的東西徹底沒有見解,那就是甘心淪落爲民工了。這也有文化的緣由,國內的公司都喜歡那些不愛抱怨的員工,由於他們聽話並且符合中國傳統的價值觀,但我更喜歡那些愛抱怨而且抱怨得有道理的人,由於國內(不僅是互聯網上面)粗製濫造的東西實在太他媽的多了,不抱怨纔不正常,有不滿纔會去思考如何作得更好。
曾經聽到有人談論如何管理技術人員的時候說:「管理技術人員很簡單,找一個比他們都牛的人就好了。」 這我的很瞭解工程師的脾氣。工程師去判斷其餘工程師的時候,每每只看他的技術能力,以爲誰的技術好誰就最牛,其它的都無所謂。沒錯,技術牛的工程師寫的代碼質量很高,但這只是一個方面而已,判斷一我的在團隊中是否是「很牛」要看他對團隊對產品的總體貢獻,而不是他的我的能力。他能很好地理解產品需求嗎?能很好地理解設計師的意圖嗎?和團隊其餘成員溝通順利嗎?寫出的代碼方便測試嗎?會對產品提出好的建議嗎?……這些都是判斷一個開發工程師的標準,總體素質越高在團隊中的價值也就越大。
因此要想作一個好的開發工程師,就要在寫好代碼的同時努力提升其它方面的能力。我知道大部分的工程師都喜歡和機器而不是和人打交道,因此遇到和產品經理、設計師以及 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 之父」,因此這本書裏面對程序員的批評仍是很中肯的。另外,書中「設計體貼的軟件」的核心思想很是棒,值得程序員好好閱讀和思考。