15個IT技術人員必須思考的問題

Bugtags發表於2015-12-29

行內的人自嘲是程式猿、屌絲和碼農,行外的人也經常拿IT人調侃,那麼究竟是IT人沒有價值,還是沒有仔細思考過自身的價值?

1.搞IT的是屌絲、碼農、程式猿?

人們提到IT人的時候,總會想到他們呆板、不解風情,專注於IT技術,就算性感的美女躺在旁邊也無動於衷。事實真的是這樣嗎?雖說不能完全否定有這樣的情況存在,但這是IT人普遍的特點嗎?而其它行業也有很多這樣的人,那為什麼人們總是拿程式設計師說事?下圖為2013年網上曾經流傳的一張屌絲分佈圖(圖片來自中國廣播網),程式設計師行業居首。 enter image description here 而實際上,問題並不在於IT行業擁有這些固有的標籤,而是行業內的人看待自己的態度。IT行業大多都很辛苦,“朝九晚五”只是聽說過,很多IT人都沒有見過,這是大家都知道的事實。那麼,不排除某些程式設計師需要在苦中找樂子,好讓辛苦的工作多一份樂趣,這當然是可以理解的了,生活總不能像程式一樣執行。

而正因為IT行業很辛苦,整天只能與機器打交道,慢慢地就不想跟人說話、不想出門,經常就會有程式設計師在社交網路吐槽。“程式猿”是用來形容IT人呆板、情商低的特徵;“碼農”用來形容程式設計師的工作跟農民一樣辛苦,賺不到錢;“屌絲”就是前面兩者的結合了。

因此,程式設計師為自己貼這幾個標籤的原因主要有兩個,一個是找樂子,另一個就是吐槽了。那為什麼行外的人也來湊熱鬧?記得多年前,當筆者還是個朦朧的高中生的時候,就特別崇拜程式設計師,在我心裡他們就是社會的精英。而其他的人,對IT行業也很有神祕感。當時的人要想去程式設計,要麼有興趣和天賦,要麼畢業於相關專業,否則是難以勝任的。而現在的情況就不同了,外面的軟體開發培訓機構都在面向初中和高中畢業生招生了。越來越多的人可以接觸到軟體開發,而進入這個領域的人中,能力參差不齊,目的各不相同,有發展得很好的,也有發展得不理想的。所以,行外的人印象中的高薪行業,行內卻有不少人並沒有拿到高薪;行外的人覺得這是一個精英行業,而行內不少人認為自己跟工地上的搬磚工差不多。

那為何面對行外的調侃時,很多程式設計師表現得如此淡定?原因就很簡單了,如果程式設計師對自己都是這種“調侃”的態度,別人怎麼調侃都無所謂了,甚至還表現出歡迎或者引起共鳴。

2.如何看待工作中的加班以及確保自身健康?

加班可以分為主動加班和被動加班。

先談談主動加班,主動加班也是有不同的動機,很多時候分為兩類,一類是熱衷於自己的事業,願意奉獻更多的時間和精力在事業上面;另一類是,回家後就找不到成就感與幸福感,還不如留在公司,可以做一些工作,也可以玩一會兒遊戲,一般不會有領導去幹涉員工在下班時間做的事情,而且還可以節約一點空調的電費,有些公司還會提供加班補貼,因此他們覺得多在公司呆幾個小時也挺好。

而被動加班的原因就沒那麼簡單了。有可能造成被動加班的原因很多,它可能來自公司、領導、團隊、個人以及一些不可抗拒的因素。

在創業公司,因為業務變動頻繁,公司的決策和方向,也會瞬息萬變,這就需要團隊成員花更多的時間去應對這些變化,因此正常的八小時工作制一般不適合創業公司,除非創始團隊足夠牛,能保證非常好的工作效率、市場洞察力和執行力。當然在大公司一般不會出現業務頻繁變動的情況,不然這家公司就是瀕臨倒閉了。在國內某些網際網路巨頭中,加班不僅已經成為家常便飯,而且有時候可以以“變態”來形容。某985高校畢業生A在畢業後進入某網際網路巨頭(為了保護相關人員或組織的隱私,本文儘量不出現特定人員或組織的名稱)承擔開發工作,在試用期三個月裡兢兢業業,每天晚上24:00左右下班回家,試用期結束以後,轉正考核以優秀通過。A憑藉較強的學習能力,這時對自己專案組的業務和技術非常熟悉,已經可以提前完成領導安排的任務,甚至還主動去改進專案組的程式。隨著工作效率的提高,A感覺沒有必要跟其他同事一樣必須呆到23:00之後才回家了,所以慢慢的他提前離開了,23:30,23:00,22:30,22:00,21:30。隨著時間一點一點提前,雖然他的工作任務都保質保量完成了,但是他在領導眼裡被貼上了“不盡職”的標籤,月度考核從最初的A滑到了C。

而團隊所帶來的加班有些時候也是不可避免的,這涉及到團隊的分工與合作,如果經常出現團隊之間的協作導致的加班,那一定是團隊成員工作的耦合度太大了,就有可能是技術架構或者團隊分工出現嚴重問題。

個人導致的加班,可能是由於自己沒有較為準確地預估工作量,也有可能是自己拖延症嚴重,還有可能是自己對技術不夠熟悉等原因,其實個人原因最好解決,因為自己可以輕鬆地找到這類加班問題的癥結,並對症下藥。

其它一些不可抗拒的因素,包括需求變動、硬碟永久性損壞等,都會帶來很多額外的工作量。

而當前國內大多數IT技術人員都是被動加班,而且是強制性質的,只有極少數公司提供加班費。因此,很多技術人員只有兩種選擇,要麼適應,要麼走人。而在中國這樣一個發展中國家,也很難期待當局會強烈干涉這個現象。

前不久一則“深圳36歲IT男猝死馬桶蓋上”的新聞在網際網路引起轟動,一個清華畢業的程式設計師,在長期連續加班之後,終因身體透支過多,年輕的生命就這樣倒下了。從尊重生命的角度來說,事業、公司和客戶都沒有自己的生命重要,若事業與生死只能選擇一個,相信絕大多數人會選擇生存。而從所謂的“XX比生命還重要”的角度而言,如果你能夠承擔長期過度加班所帶來的後果,或者原意像革命先烈一樣為自己的事業獻出生命,那誰也沒法阻止你。

3.如何平衡工作與家庭?

筆者曾經在參加一期沙龍的時候,一個智慧硬體公司創始人對我說:程式設計師根本就沒有生活,他們的生活就是工作。他作為一個技術出身的創始人,這樣說也是可以理解的,但這種說法並不一定正確。一方面,程式設計師需要爭取到家人的大力支援,如果沒有他們的支援,程式設計師在事業的前進途中可能會遇到很多困難;另一方面,可以想象一下,如果自己生了重病,每天呆在病床旁邊照顧你的人是公司領導還是家人?考慮好了這些,也許就知道該怎麼辦了。

4.資訊檢索一定得用Google?

在很多招聘廣告中,也許你見到過很多類似這樣的職位要求“必須使用Google來搜尋技術資料,如果你用Baidu,那麼你就不適合我們”。首先,我們知道Google的搜尋引擎比Baidu做得好,對關鍵詞進行的資源定位更加精確,理論上來說,輸入同樣的關鍵詞,Google匹配得更準確一些,也就是可以更快速地找到答案。那麼研發團隊是否需要對工具的使用強制立下規矩,必須用Google搜尋,必須用Linux作業系統,必須用機械鍵盤...這又聯想到了小學的時候學到的文章《摔琴》的故事了,雖然便宜的小提琴在某些音調上表現得不是那麼好,而只要演奏者水平足夠高,聽眾根本意識不到演奏者用的是多貴的琴了。再回到主題上來,對於一個資訊檢索高手來說,他可以利用世界上最糟糕的搜尋引擎來查詢到Google上面找不到的內容。也就是說,能否快速查詢到需要的結果,並非取決於特定的搜尋引擎。況且,當你使用Google和Baidu同時搜尋相同的中文關鍵字時,呈現的結果都是大同小異的。有人會說,Google的英文搜尋比Baidu強,那麼你可以試一下,它與沒有被牆的Bing、Yahoo等搜出來的英文結果,也是大同小異的。因此,檢索資訊人的是一種能力,它並非決定於搜尋工具。 5.技術牛人如何對待新手?

在公司裡(特別是大公司),一般有很一些技術大牛,他們是公司核心的技術人員,支撐著整個公司的技術平臺。那些可以稱得上技術專家的員工,一般性情隨和,也表現得非常謙卑,他們對於技術新手的提問特別有耐心。但是也有少數技術還不錯的人,對於職場新手各種瞧不起,特別是對於新手程式設計師犯下的錯誤,他們會用盡可能高的音量指出錯誤,甚至是謾罵,以此來向周圍的人表明自己的技術是多麼牛。只能說,作為IT技術人員,這樣的表現很不成熟。高手或專家都是從小白起家的,今天的小白也許就是明天的專家,根本沒有必要去嘲諷職場新人,那樣只會讓自己在同事眼裡的魅力大打折扣。 6.如何看待IT鄙視鏈?

2014年底的時候,IT界盛傳一篇名為“軟體工程師的鄙視鏈”的文章,主要從程式語言、工具、OS、硬體和職場五個方面來介紹IT界的鄙視鏈。就以程式語言鄙視鏈為例,靜態語言鄙視動態語言,組合鄙視C,C鄙視C++,C++鄙視Java和C#,Java和C#相互鄙視,C#鄙視VB...下面來看一下來自CSDN整理的程式語言歷史排行榜:

enter image description here Java、C和C++在2002年前後使用量很大,但是到了2014年之後,三者都有下降,只是C降幅比較小。在2002年前後,php剛問世就得到大量的應用,而到了2014年就跌了很遠。Python在2002年前後應用較少,而到了2014年應用也很多了...這些變化說明了什麼?程式語言日新月異,它終歸是一個工具,程式語言有個很明顯的特點就是,它們之間相互借鑑,直接導致了設計思想有很多類似的地方,所以,只要你精通了一門或兩門程式語言,其它絕大部分語言學習成本很低。所以,今天你自鳴得意的程式語言,完全有可能在明天變得冷門了,甚至是消失。沒有必要去鄙視使用另一門冷門語言的人,也許他今天使用的程式語言明天會成為主流語言。很多有程式語言情節的程式設計師根本就不相信這句話,他們堅信自己使用的語言是世界上最偉大的,會長命百歲。

換到其它型別的鄙視也是一樣,從事運維的技術人員,在能力上並不一定比從事開發的差,也許街上的某位快遞員之前的職位就是一名比你還牛的程式設計師。社會職位各有分工,各行各業的職位都是不可替代的,否則這個職位就該消失了,沒有被鄙視的機會。也許你做的工作他不會做,而他做的工作你也不會做。

7.為何不自稱工程師?

在中國,很少有程式設計師把自己自稱為工程師,在這些人中,要麼是擔心這個標籤給自己帶來太大的壓力,而自己的能力不匹配;要麼就是希望外界把自己當做一名普通的寫程式的人員;還有一種就是,希望外界不要稱呼他們“程式猿”或者“碼農”,他們不喜歡被這樣調侃,但也不希望被高估,就喜歡低調行事。 8.薪水在選擇工作中的影響力有多大?

當前很多IT行業求職者都有一個信條:“做多少事,拿多少錢”。如果公司願意拿更多的錢,通常求職者在主觀上表現出願意做更多的事。若有兩個offer在面前,offer1錢多,但是你不是特別喜歡它的工作內容,而offer2薪資只有offer1的一半,但是它的工作內容是你擅長並且喜歡的。經常在網上會有這樣的帖子,列出幾個offer,讓網友提建議。其實,遇到這種情況很好辦的。如果你當前最需要的是錢,那麼果斷地選擇錢多的;如果你當前最需要的是一份你喜歡的工作,肯定選擇自己喜歡的了。選擇工作的時候,選擇自己最需要的,這樣工作起來也會更有動力。若聽從那些所謂的牛人的建議(比如應屆生沒必要在乎工資多少,能學到技術就好之類的,其實對於應屆生來說,到哪裡都能學到技術,只是學到得多與少的問題),你很難在工作崗位上認真投入的。當前很缺錢,現在也沒有興趣去幹一番事業,那麼就不要接受一個創業團隊的低薪+畫的大餅這樣的待遇,因為你加入公司之後,對於公司和你自己都沒有好處。 9.程式語言不重要,重要的是設計思想?

這個是那些所謂的技術牛人給新手的建議,學校的老師也會給出這樣的建議。當新手在諮詢學哪門語言的時候,那些所謂的專家建議新手隨便學一門語言,門門語言都想通,哪門語言精通以後都可以找到好工作。雖然這個建議沒有完全錯,但是也沒用完全正確。不同的語言適應著不同的業務需要,比如做企業開發Java語言更合適,php和python在中小型網站開發中更加快速,Objective-C主要用於開發ios...況且不同的語言還有不同的特性,底層的實現通常並非相同,這就需要開發者根據自己喜歡的業務領域來選擇程式語言,需要對所使用的語言相當熟悉。 10.是否經常把自己的思想強加給同事?

程式設計師群體有個比較普遍的現象就是,總覺得自己的想法是最好的。而人人都有自己的想法,只是有些人喜歡錶達出來,而有些是埋在心裡。允許他人評判你的想法,客觀去分析他們的觀點,而不是粗暴地強加給他們,這是一種個人魅力。 11.IT人可以做多久的技術?

筆者在大學期間,經常聽人說IT人是吃青春飯的,過了35歲就寫不了程式碼了。如果幹到了35歲還停留在寫程式碼層面上,估計那時是幹不過畢業沒多久的年輕人了。 12.什麼技術熱門或賺錢,就學什麼技術?

之前Hadoop技術很火,很多公司開出天價招聘Hadoop技術人員,但是如今呢?當Hadoop退燒之後,這個職位的薪資沒有之前那麼有吸引力了。熱門或賺錢的技術很多時候比較短暫,學習自己喜歡的技術才是王道。 13.如果某一天開始計算機不需要人類程式設計了,你還可以做什麼?

隨著人工智慧技術的發展,若未來機器可以代替程式設計師進行程式設計了,程式設計師還能做什麼呢?計算機和網際網路的發展,消滅了很多傳統職位,但隨著科技的不斷髮展,程式設計師這個職位也許會有一天也被消滅了。當全球的IT公司都宣佈廢除人工程式設計時,程式設計師應該是回家還是轉行呢?

14.業務驅動型還是技術驅動型

當前O2O在中國非常火,嚴格來說,O2O公司不算是一個網際網路公司。O2O將傳統行業從線下搬一部分到線上,比如以前需要去餐館吃飯,現在只需要在網上下訂單,餐館就把食物送到家裡來了。很明顯,O2O就是一個業務驅動型的公司。在這樣的公司裡,技術只是業務的一個支撐部門,一般不會用到複雜的技術,但是需要技術人員懂得較多的線上線下業務。而百度這樣的公司,就是典型的技術驅動型的公司,他們在使用和研究比較高深的技術,裡面很多科學家級別的人物。所以,如果想在技術上有深入到專家級別,那麼肯定在技術驅動型的公司裡更容易做到。而如果想利用簡單的技術來改變傳統行業,業務驅動型的O2O就是你想找的。

15.如何定義成功

畢業多年後,同學之間總會有人討論誰混得好誰混得差。那麼好與差的標準是什麼呢?是賺了多少錢,有沒有在北上廣深買房,當了多大的官、是否在BAT工作?不同的人有不同的評判標準,但多數是以錢來衡量他是否成功。但成功的標準就這麼單一?如果一定得給成功下一個定義,那麼成功應該這樣來計算:

成功度(S)=(工作快樂度工作快樂權重 +工作薪資薪資權重 + ... + 生活快樂度×生活快樂權重 + 家庭和睦度*家庭和睦權重 + ...)/n

這裡S最大者才是最成功的人。

原文出處:http://www.sanesee.com/article/15-questions-for-programers

轉載請註明:運維派 enter image description here

相關文章