寫給即將離開校園的新程序員

日期 2016-06-15 / 人氣 2589 / 欄目： 運營干貨 創(chuàng)業(yè)草根

轉(zhuǎn)眼間又到了一年一度的畢業(yè)季，如今回首自己真正意義上的大學生活已過去整整兩個春秋。謹以此文獻給那些即將畢業(yè)的和還未畢業(yè)的學弟學妹們。

這篇博客的標題定的很大，說實話我不知道自己有沒有資格在這里對如此之多的“互聯(lián)網(wǎng)行業(yè)未來從業(yè)者”的職場起點說三道四。
 

雖然我無法像眾多前輩一樣在博客中站在一個從業(yè)多年的技術(shù)經(jīng)理或技術(shù)專家的角度來談程序員的職業(yè)規(guī)劃，但對于“程序員職場的起點”這個話題，你將要面對的一切都是我不久前所經(jīng)歷的，并且我深知此刻初入職場的你需要這些建議。

初入職場，對一個程序員來說最重要的是什么?
2014年時，在58同城的校園宣講會上，休息時我曾單獨找到當時來到現(xiàn)場的唯一一位程序員講師“沈劍”，詢問了他眼中的初級程序員應有的職業(yè)規(guī)劃，他的回答令我醍醐灌頂，至今記憶猶新：
1、技術(shù)基礎
2、業(yè)務積累
3、職場情商

技術(shù)基礎是指作為一名程序員來講的一些基本的、通用的技術(shù)，諸如數(shù)據(jù)結(jié)構(gòu)、算法、數(shù)學能力、軟件工程理論、操作系統(tǒng)基本知識、編譯原理以及你所從事的技術(shù)崗位所使用的技術(shù).這些是學校里教給你的東西，無論學得怎么樣，在你的程序員生涯中它們都將跟隨你一輩子，因為無論你從事什么技術(shù)崗位，在這個行業(yè)中，這些東西都是共通和必要的，是身為一名軟件工程師的立足之本。

業(yè)務積累指的是你在部門里邊具體承擔的業(yè)務，相對前一條來說，這一條是不存在行業(yè)中的普遍性和通用性的，然而如果說前面一條是使你順利拿到校招offer的前提，那么這一條則是你所在的公司每個月付給你“比任何一個行業(yè)的任何職位在初期都要高得多”的薪資的理由。換言之，如果你是一名實習生而你手上卻沒有任何業(yè)務積累，你該為自己能否得到offer而感到忐忑，而相反的情況如果你手上已有很多業(yè)務，每天忙得要命，你也該清楚現(xiàn)在的這個部門給你發(fā)offer應該是板上釘釘?shù)氖铝恕?/p>

第三點也許是最容易被我們程序員這樣一個群體所忽略的——情商。這也是本文真正想要表達的重點，是我想在這篇文章中給你的建議。

程序員的情商有那么重要嗎?
引用大家所熟知的OOP的思想，無論你是一名服務端、Android還是機器學習算法、數(shù)據(jù)挖掘工程師，你的職位title都是從軟件工程師這個父類繼承下來的，而軟件工程師這個職位繼承于工程師，更繼承于“公司職員”。
但凡是一名公司職員，就免不了職場中的人情冷暖、酸甜苦辣。因為身處公司最基層，每一個工作日你無法避免的要與各種人和事打交道。說的直白一點，有人的地方就有利益，職場中人與人之間的利益不可能沒有沖突。
當你的個人利益與其他同事的個人利益、團隊利益甚至公司的利益發(fā)生矛盾時，你至少應該清楚沒有哪個職場人能夠避免這一點。

在諸多利益交織下，到一定程度以后你會明白始終維持著這一切的不是別的，是人情!
那些充滿“正能量”的新員工培訓可能告訴你什么“主人翁意識”什么“不想當老板的員工不是好員工”，然而在現(xiàn)階段對你來說最重要的卻是融入團隊，和你身邊的同事還有領(lǐng)導搞好關(guān)系。

如果你跟部門里的任何一位同事關(guān)系鬧僵，我敢保證在這個公司里你將舉步維艱，每天上班的心情猶如上墳。
情商體現(xiàn)在哪里?

對于一名初入行業(yè)的軟件工程師來說，你不只需要和代碼打交道，更需要與產(chǎn)品溝通需求、向領(lǐng)導匯報工作進度以及跟其他技術(shù)崗位的同事協(xié)商和聯(lián)調(diào)代碼。

我從沒見過或是聽過哪個公司的哪個項目可以從產(chǎn)品策劃到UI設計再到前后端編程開發(fā)調(diào)試測試上線發(fā)布后續(xù)運營維護等工作全部由一個人來完成的，如果有，這也一定不常見。

我知道校招生們多數(shù)愿意進BAT這些大公司，我當年也不例外，并且回頭看來這一步也確實沒有錯，大公司給你的不只是更高的起薪以及畢業(yè)時在老師們面前優(yōu)人一等的光環(huán)，更重要的是你將會認識更多和你一樣優(yōu)秀的同齡人，你的視野將會更開闊。

然而細細想想在一個大公司里，我們工作的更多時間是開會而不是寫代碼。捫心自問在一個公司里干了一個月以后，你究竟寫了多少行代碼?你又開了多少個會?

這不叫效率低下，在公司體制龐大以后這些溝通我認為全都是必要的，這些花在管理和溝通上面的成本對公司來講絕對值得，就像一塊硬盤能存下多少數(shù)據(jù)就必須產(chǎn)生相應的區(qū)塊保存數(shù)據(jù)的物理地址和邏輯地址，再加上系統(tǒng)級的內(nèi)存管理、應用級的框架消耗和垃圾回收，仔細想想我們每天使用的手機、平板和電腦設備的更多內(nèi)存資源和CPU使用其實都是消耗在了設備自身對數(shù)據(jù)的管理上，機器尚且如此，更何況人呢。

所以不要對開會產(chǎn)生反感，每一次會議都是你學習的機會，更是你表現(xiàn)自己的機會。如果在一次會議上你提出了一處UI設計稿上面的缺失剛好是你的leader沒考慮到的，他下次還會帶上你一起開會;如果在服務端Rest接口確認的過程中你想到了一個leader們沒考慮到的數(shù)據(jù)項，這很可能為整個開發(fā)周期節(jié)省一到兩天;與產(chǎn)品溝通需求時，并不是一味地否定和砍減需求，也不是毫不過腦子的點頭，你應該設身處地的站在把一個產(chǎn)品做到盡善盡美的角度去跟對方溝通，刪掉對大家都沒有利益的需求，必要的時候甚至增添一個對雙方都有收益的需求。

這一切都能夠讓你的工作狀態(tài)更為積極，而積極的工作狀態(tài)對你對公司對所有人都是有利的。
初期應該如何融入團隊?
幸運的是程序員畢竟男多女少，因為我想舉的例子和足球有關(guān).我很愛看球，我們往往關(guān)注的都是那些場上閃耀的球星，然而任何一個年輕的小球員在初入球隊時都是從替補席冷板凳坐起的，哪怕你是羅納爾多這樣的超級巨星(球迷們不要怪我，只是我覺得拿大羅來舉例相對爭議小一些)。

初入職場的你，就如同一個剛進入球隊坐在替補席上的小球員一樣，最初很可能連90分鐘末補時的那幾分鐘上場機會對你來說都是無比珍貴。

在這種情況下，要學會撿別人不要的活兒干，而不是坐在工位上打開qq和同學抱怨自己在部門里不受重視。
舉個例子:如果說部門里缺前端，你作為服務端也該自己學會寫后臺管理頁面，這些東西leader看在眼里，他會明白你的努力。

另外千萬不要放過任何和同事們溝通的機會，哪怕是午餐時的閑談.這恰恰是發(fā)現(xiàn)一些“可撿的活兒”的一個途徑。

遇到技術(shù)上的問題該怎么解決?
對于這個問題的看法有很多版本，我個人偏向于盡量靠自己解決問題。
原因有二:第一個原因是作為一名初入崗位的工程師，不是看不起你，很多時候你對自己遇到的問題究竟該不該問別人，該問的話該問誰你都是不知道的.在這樣的情況下，你很可能把一個google五分鐘就能解決的程序語法報錯拿過去問了你的同事，問問題存在溝通成本和理解成本，你的描述不清以及對方缺乏上下文了解這些都可能增加以上兩個成本，這樣一來不僅耽誤雙方的時間，長此以往還會讓對方覺得你記得技術(shù)基本功不扎實，獨立處理問題能力差.第二個原因是，即使這個問題真的是一個較為冷門的編程語言運行環(huán)境層面的bug，你在不經(jīng)過任何思考的前提下把它拋給了你的導師或是你的leader，他很可能是遇到過這個問題的，于是直接把問題的答案告訴了你，這樣你就完美地錯過了一次在你所使用的語言環(huán)境下親自踩坑然后填坑的機會。

我認為對于程序員來說，總有一天你要獨立面對這些編譯環(huán)境、運行環(huán)境的偏門bug，因為你不可能一輩子只寫一門語言或是只從事一種開發(fā)崗位，你現(xiàn)在可以問你的導師問你的leader，那么你自己當上leader之后又該問誰呢?總不能告訴自己的老板，這問題太難了，我解決不了。

我記不清好像是之前百度的首席工程師說過的一句話：衡量一個程序員價值的標準并不是他掌握了多少知識，而是他掌握的知識與學會這些所花的時間之比。

對于初入開發(fā)崗位的你來說，每一次踩到一個坑然后獨立填坑的經(jīng)歷都將會加速你對更多技術(shù)領(lǐng)域內(nèi)的知識和問題的學習速度，也將會提高你作為一個工程師的價值。

如何與產(chǎn)品溝通?
在技術(shù)圈里這是老生常談的話題，我認為與產(chǎn)品溝通的過程中是最能體現(xiàn)出一個程序員情商的時候.無論對方提出的需求是怎樣的，你考慮問題的邏輯應該是：當前提的這一條需求做完以后對產(chǎn)品有什么收益?對技術(shù)這邊又有什么收益?更重要的是leader們是否會在乎這一點?

然而這一切都應該發(fā)生在你的內(nèi)心中，權(quán)衡利弊之后如果有什么沒考慮到的你可以提出來，如果并不是十分確認自己的想法，你可以等會后私下里和你的leader提出自己的看法，這既是對leader的尊重也是節(jié)省開會時間。
幸運的是，在互聯(lián)網(wǎng)這個行業(yè)里，需求溝通的過程中，技術(shù)人員的話語權(quán)通常還是較大的，然而絕不要濫用你的話語權(quán)。

我可以捫心自問的說，在我正式入職以后溝通過的每一位產(chǎn)品，沒有和任何一位發(fā)生過爭吵，相反的是產(chǎn)品們都愿意與我對需求。

這并不是因為我把PM們當大爺一樣供著，對任何奇葩的需求都有求必應，而是因為我往往把“與PM對需求”這件事放在“人情”這樣感性的層面來考慮，而不像很多程序員那樣只考慮代碼邏輯的理性思維方式。
人是復雜的動物，一個PM提出了一個看似無理的需求，你卻不應該不問青紅皂白直接拒之門外，設身處地將心比心的想一想，公司里這樣復雜的環(huán)境下，他/她是否也有自己的無奈和苦衷?如果有，這個問題是否存在其他折中的解決方案?

武斷砍需求的程序員往往錯過了這樣的商討“折中方案”的機會，同時也錯過了一個讓PM認可你的機會!這一點其實很重要。
我見過很多同期進公司的校招生，他們把職場中“老油條們”習以為常的做事方式直接照搬到了自己的行事風格當中，內(nèi)心里對PM的抱怨將會在潛意識里左右你與PM溝通的態(tài)度和方式。

換個角度考慮，我倒覺得在其他職位的人眼中，你的技術(shù)多么多么的NB他們是無法直觀洞悉的，每一個無理取鬧的需求也都是一個你證明自己的機會。

更重要的是，公司里與產(chǎn)品交涉問題并不同于市場上買菜那樣，你們的工作很可能在接下來的幾個月中都存在溝通和交集，今天你賣給他一個人情，明天他也會替你扛一個線上的錯誤， (說實話程序員在代碼上線之前往往喜歡叫PM來做最后確認，言外之意是上線是你確認的，出了問題也得你扛著.我覺得一個項目是大家一起做的，說句良心話，把所有的責任一股腦全部都推給PM我個人認為也是不公平的，PM往往在很多項目中充當“背鍋俠”，人要相互理解)人非圣賢孰能無過，任何線上的代碼都不可能永遠是不出錯的.PM對于一個之前敲定好的需求的修改，確實有可能是出于他本人工作上的疏忽，但是這不代表你的工作就不會出錯，如果人之間沒有“良好的信任關(guān)系”，問題就會被相互放大，像手電筒一樣給別人挑錯很簡單，難的是互相的彌補對方的失誤從而建立一種長久的友好合作關(guān)系，而能做到這一點也正是所謂情商的體現(xiàn)。

情商不是叫你如何精明的算計對方，那叫“別有用心的智商”，情商是包容與理解。有了人情作為基礎，我覺得沒有哪個PM會和你在一兩天的deadline問題上面扯皮。

即使利益之間的沖突真的無法解決，也沒有任何折中方案，你至少可以把問題記錄下來，拿到leader們那里交給他們?nèi)プ鰶Q定，而沒必要當面撕破臉傷及雙方的感情，畢竟產(chǎn)品是公司的，人際關(guān)系是自己的。

如何看待加班?
加班就像借錢，原則上必然是救急不救窮.然而并不是說對于一個“窮”的部門程序員就一定要選擇離開，這既不是負責任的表現(xiàn)，又錯過了一個成為部門核心骨干力量的機會.很多公司里的leader都是在危難關(guān)頭扛下了部門的人手不足的壓力，leader的職位也就順理成章.除非部門真的氣數(shù)已盡。

ruby on rails的作者曾說過，熬夜加班相當于借高利貸，偶爾一次可能是難免的，但如果你的工作長期需要你熬夜加班(IT運維崗除外)，你可能確實該考慮換一份工作。

最后祝愿各位未來的程序員在校招的潮流中能夠成為offer收割機，并且得到自己真正心儀公司的offer!
如果覺得本文中說的確有些干貨，歡迎各位同學點擊文章底部的打賞按鈕為我的博客募捐.捐款不在多少，卻是一個能夠讓我堅持精品原創(chuàng)博客的動力.對web方面感興趣的同學，可以關(guān)注下我最近在搞的一個開源項目veneno，項目主張以Node.js來進行web安全方面自動化攻擊、防御的一些實踐。

轉(zhuǎn)載整理本文請注明出處【通聯(lián)臺州網(wǎng)站建設中心】

標簽：