寫給即將離開校園成為一名程式設計師的幾句忠告

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

這篇部落格的標題定的很大,說實話我不知道自己有沒有資格在這裡對如此之多的”網際網路行業未來從業者”的職場起點說三道四.

雖然我無法像眾多前輩一樣在部落格中站在一個從業多年的技術經理或技術專家的角度來談程式設計師的職業規劃,但對於”程式設計師職場的起點”這個話題,你將要面對的一切都是我不久前所經歷的,並且我深知此刻初入職場的你需要這些建議!

初入職場,對一個程式設計師來說最重要的是什麼?

2014年時,在58同城的校園宣講會上,休息時我曾單獨找到當時來到現場的唯一一位程式設計師講師”沈劍”,詢問了他眼中的初級程式設計師應有的職業規劃,他的回答令我醍醐灌頂,至今記憶猶新:

• 1. 技術基礎
• 2. 業務積累
• 3. 職場情商

技術基礎是指作為一名程式設計師來講的一些基本的、通用的技術,諸如資料結構、演算法、數學能力、軟體工程理論、作業系統基本知識、編譯原理以及你所從事的技術崗位所使用的技術. 這些是學校裡教給你的東西,無論學得怎麼樣,在你的程式設計師生涯中它們都將跟隨你一輩子,因為無論你從事什麼技術崗位,在這個行業中,這些東西都是共通和必要的,是身為一名軟體工程師的立足之本.

業務積累指的是你在部門裡邊具體承擔的業務,相對前一條來說,這一條是不存在行業中的普遍性和通用性的, 然而如果說前面一條是使你順利拿到校招offer的前提,那麼這一條則是你所在的公司每個月付給你”比任何一個行業的任何職位在初期都要高得多”的薪資的理由. 換言之,如果你是一名實習生而你手上卻沒有任何業務積累,你該為自己能否得到offer而感到忐忑,而相反的情況如果你手上已有很多業務,每天忙得要命,你也該清楚現在的這個部門給你發offer應該是板上釘釘的事了.

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

程式設計師的情商有那麼重要嗎?

引用大家所熟知的OOP的思想,無論你是一名服務端、Android還是機器學習演算法、資料探勘工程師,你的職位title都是從軟體工程師這個父類繼承下來的,而軟體工程師這個職位繼承於工程師,更繼承於”公司職員”.

但凡是一名公司職員,就免不了職場中的人情冷暖、酸甜苦辣.因為身處公司最基層,每一個工作日你無法避免的要與各種人和事打交道.說的直白一點,有人的地方就有利益,職場中人與人之間的利益不可能沒有衝突.

當你的個人利益與其他同事的個人利益、團隊利益甚至公司的利益發生矛盾時,你至少應該清楚沒有哪個職場人能夠避免這一點.

在諸多利益交織下,到一定程度以後你會明白始終維持著這一切的不是別的,是人情!

那些充滿”正能量”的新員工培訓可能告訴你什麼”主人翁意識”什麼”不想當老闆的員工不是好員工”,然而在現階段對你來說最重要的卻是融入團隊,和你身邊的同事還有領導搞好關係.

如果你跟部門裡的任何一位同事關係鬧僵,我敢保證在這個公司裡你將舉步維艱,每天上班的心情猶如上墳.

情商體現在哪裡?

對於一名初入行業的軟體工程師來說,你不只需要和程式碼打交道,更需要與產品溝通需求、向領導彙報工作進度以及跟其他技術崗位的同事協商和聯調程式碼.

我從沒見過或是聽過哪個公司的哪個專案可以從產品策劃到UI設計再到前後端程式設計開發除錯測試上線釋出後續運營維護等工作全部由一個人來完成的,如果有,這也一定不常見.

我知道校招生們多數願意進BAT這些大公司,我當年也不例外,並且回頭看來這一步也確實沒有錯,大公司給你的不只是更高的起薪以及畢業時在老師們面前優人一等的光環,更重要的是你將會認識更多和你一樣優秀的同齡人,你的視野將會更開闊.

然而細細想想在一個大公司裡,我們工作的更多時間是開會而不是寫程式碼.捫心自問在一個公司裡幹了一個月以後,你究竟寫了多少行程式碼?你又開了多少個會?

這不叫效率低下,在公司體制龐大以後這些溝通我認為全都是必要的,這些花在管理和溝通上面的成本對公司來講絕對值得,就像一塊硬碟能存下多少資料就必須產生相應的區塊儲存資料的實體地址和邏輯地址, 再加上系統級的記憶體管理、應用級的框架消耗和垃圾回收,仔細想想我們每天使用的手機、平板和電腦裝置的更多記憶體資源和CPU使用其實都是消耗在了裝置自身對資料的管理上,機器尚且如此,更何況人呢.

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

這一切都能夠讓你的工作狀態更為積極,而積極的工作狀態對你對公司對所有人都是有利的.

初期應該如何融入團隊?

幸運的是程式設計師畢竟男多女少,因為我想舉的例子和足球有關.我很愛看球,我們往往關注的都是那些場上閃耀的球星,然而任何一個年輕的小球員在初入球隊時都是從替補席冷板凳坐起的, 哪怕你是羅納爾多這樣的超級巨星(球迷們不要怪我,只是我覺得拿大羅來舉例相對爭議小一些).

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

在這種情況下,要學會撿別人不要的活兒幹,而不是坐在工位上開啟qq和同學抱怨自己在部門裡不受重視.

舉個例子:如果說部門裡缺前端,你作為服務端也該自己學會寫後臺管理頁面,這些東西leader看在眼裡,他會明白你的努力.

另外千萬不要放過任何和同事們溝通的機會,哪怕是午餐時的閒談.這恰恰是發現一些”可撿的活兒”的一個途徑.

遇到技術上的問題該怎麼解決?

對於這個問題的看法有很多版本,我個人偏向於盡量靠自己解決問題.

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

我認為對於程式設計師來說,總有一天你要獨立面對這些編譯環境、執行環境的偏門bug,因為你不可能一輩子只寫一門語言或是隻從事一種開發崗位,你現在可以問你的導師問你的leader, 那麼你自己當上leader之後又該問誰呢?總不能告訴自己的老闆,這問題太難了,我解決不了.

我記不清好像是之前百度的首席工程師說過的一句話:衡量一個程式設計師價值的標準並不是他掌握了多少知識,而是他掌握的知識與學會這些所花的時間之比.

對於初入開發崗位的你來說,每一次踩到一個坑然後獨立填坑的經歷都將會加速你對更多技術領域內的知識和問題的學習速度,也將會提高你作為一個工程師的價值.

如何與產品溝通?

在技術圈裡這是老生常談的話題,我認為與產品溝通的過程中是最能體現出一個程式設計師情商的時候.無論對方提出的需求是怎樣的,你考慮問題的邏輯應該是:當前提的這一條需求做完以後對產品有什麼收益?對技術這邊又有什麼收益?更重要的是leader們是否會在乎這一點?

然而這一切都應該發生在你的內心中,權衡利弊之後如果有什麼沒考慮到的你可以提出來,如果並不是十分確認自己的想法,你可以等會後私下裡和你的leader提出自己的看法,這既是對leader的尊重也是節省開會時間.

幸運的是,在網際網路這個行業裡,需求溝通的過程中,技術人員的話語權通常還是較大的,然而絕不要濫用你的話語權.

我可以捫心自問的說,在我正式入職以後溝通過的每一位產品,沒有和任何一位發生過爭吵,相反的是產品們都願意與我對需求.

這並不是因為我把PM們當大爺一樣供著,對任何奇葩的需求都有求必應,而是因為我往往把”與PM對需求”這件事放在”人情”這樣感性的層面來考慮,而不像很多程式設計師那樣只考慮程式碼邏輯的理性思維方式.

人是複雜的動物,一個PM提出了一個看似無理的需求,你卻不應該不問青紅皁白直接拒之門外,設身處地將心比心的想一想,公司裡這樣複雜的環境下,他/她是否也有自己的無奈和苦衷?如果有,這個問題是否存在其他折中的解決方案?

武斷砍需求的程式設計師往往錯過了這樣的商討”折中方案”的機會,同時也錯過了一個讓PM認可你的機會!這一點其實很重要.

我見過很多同期進公司的校招生,他們把職場中”老油條們”習以為常的做事方式直接照搬到了自己的行事風格當中,內心裡對PM的抱怨將會在潛意識裡左右你與PM溝通的態度和方式.

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

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

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

即使利益之間的衝突真的無法解決,也沒有任何折中方案,你至少可以把問題記錄下來,拿到leader們那裡交給他們去做決定,而沒必要當面撕破臉傷及雙方的感情,畢竟產品是公司的,人際關係是自己的.

如何看待加班?

加班就像借錢,原則上必然是救急不救窮.然而並不是說對於一個”窮”的部門程式設計師就一定要選擇離開,這既不是負責任的表現,又錯過了一個成為部門核心骨幹力量的機會. 很多公司裡的leader都是在危難關頭扛下了部門的人手不足的壓力,leader的職位也就順理成章.除非部門真的氣數已盡.

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

最後祝願各位未來的程式設計師在校招的潮流中能夠成為offer收割機,並且得到自己真正心儀公司的offer!

如果覺得本文中說的確有些乾貨,歡迎各位同學點選文章底部的打賞按鈕為我的部落格募捐.捐款不在多少,卻是一個能夠讓我堅持精品原創部落格的動力. 對web方面感興趣的同學，可以關注下我最近在搞的一個開源專案veneno, 專案主張以Node.js來進行web安全方面自動化攻擊、防禦的一些實踐。