職場 | 工做五年以後，對技術和業務的思考

苦海無邊，回頭無岸。

01

晃晃悠悠的，在互聯網行業工做了五年，默然回首，你看哪裏像燈火闌珊處？

初入職場，大部分程序員會以爲苦學技術，之後會順風順水升職加薪，這樣的想法沒有錯，可是不算全面，五年後你會不會繼續作技術寫代碼這是核心問題。

初入職場，會以爲努力加班能夠不斷提高能力，能夠學到技術的公司就算薪水低點也能夠接受，可是五年以後會認爲加班都是在不斷擠壓本身的上升空間，薪水低是人生的天花板。

這裏想說的關鍵問題就是：初入職場的認知和想法大部分不會再適用於五年後的認知。

工做五年以後面臨的最大壓力就是選擇：職場天花板，技術能力天花板，薪水天花板，三十歲天花板。

如何面對這些問題，是大部分程序員都在思考和糾結的。作選擇的惟一參考點就是：利益最大化，這裏能夠理解爲職場更好的升職加薪，順風順水。

五年，變化最大不是工做經驗，能力積累，而是心態，清楚的知道現實和理想之間是存在巨大的差距。

02

回首本身的職場五年，最承認的一句話就是：學會適應變化，並積累能力。

變化的就是，五年的時間技術框架更新迭代，開發工具的變遷，公司環境隊友的更換，甚至是不一樣城市的流浪，想着能把肉體和靈魂安放在一處，有句很經典的話就是：惟一不變的就是變化自己。

要積累的是：解決問題的能力，思考方式，拓寬認知。

這種很難直白的描述，屬於我的認知的範疇，不一樣的人有不同的見解，因此只能站在大衆化的角度去思考。

首先聊聊技術，大部分小白級別的，都但願本身的技術能力不斷提升，爭取作到架構師級別，可是站在當前的互聯網環境中，這種想法實現難度仍是偏高，這裏既不是打擊也不是爲了擡槓。

能夠觀察一下現狀，技術團隊大的20-30人，小的10-15人，能有一個架構師去專門管理底層框架都是少有現象。

這個問題的緣由不少，首先架構師的成本太高，環境架構也不是須要常常升級，說的難聽點可能框架比項目生命週期更高。

因此大部分公司的大部分業務，基於現有大部分紅熟的開源框架均可以解決，這也就致使架構師這個角色一般由項目主管代替或者級別較高的開發直接負責，這就是現實狀況。

這就致使技術框架的選擇思路就是：只選對的。即這方面的人才多，開源解決方案多，以此下降技術方面對公司業務發展的影響。

那爲何還要不斷學習和積累技術能力？若是沒有這個能力，程序員崗位可能根本走不了五年之久，須要用技術深度積累不斷解決工做中的各類問題，用技術的廣度提高本身實現業務需求的認知邊界，這是安放肉體的根本保障。

這就是致使不少五年之後的程序員壓力陡然升高的緣由，走向管理崗的另外一個壁壘就是業務思惟和認知。

03

程序員該不應用心研究業務，這個問題真的沒有糾結的必要，只要不是純技術型的公司，都須要面對業務。

無論技術、運營、產品、管理層，都是在面向業務工做。

從本身職場軌跡來看，五年變化最大就是解決業務問題的能力，職場之初面對不少業務場景都不知道如何下手，到幾年以後設計業務的解決方案。

這是大部分程序員在職場前五年跳槽就能漲薪的根本緣由，面對業務場景，基於積累的經驗和現有的開源工具，能快速給出合理的解決思路和實現過程。

工做五年可能對技術底層的清晰程度都沒有初入職場的小白清楚，可是寫的程序卻能夠避開不少坑坑窪窪，對於業務的審視也是很細節全面。

解決業務能力的積累，對於技術視野的寬度需求更甚，好比職場初期對於海量數據的處理一籌莫展，可是在工做幾年以後見識數據行業的技術棧，真的就是技術選型的視野問題。

什麼是衡量技術能力的標準？站在一個共識的角度上看：系統的架構與代碼設計能適應業務的不斷變化和各類需求。

相對比與技術，業務的變化更加快速頻繁，高級工程師或者架構師之因此薪資高，這些角色一方面能適應業務的迭代，而且在工做中具備必定前瞻性，會考慮業務變化的狀況下代碼複用邏輯，這樣的能力是須要必定的技術視野和業務思惟的沉澱。

因此職場中：業務能說的層次分明，代碼能寫的明明白白，獲得機會的可能性更大。

04

從理性的角度看技術和業務兩個方面，能讓大部分人職場走的平穩順利，可是不一樣的階段對二者的平衡和選擇是不同的。

在思考如何選擇的時候，能夠參考二八原則的邏輯，即在任何一組東西中，最重要的只佔其中一小部分，約20%，其他80%儘管是多數，倒是次要的，所以又稱二八定律。

我的真的很是喜歡這個原則，大部分人都不是天才，因此很難三心二意同時作好幾件事情，在同一時間段內應該集中精力作好一件事件。

可是單純的二八原則模式可能不適應大部分職場初期的人，由於初期要學習不少內容，如何在職場生存：專業能力，職場關係，爲人處世，產品設計等等。

固然這些東西不是都要用心刻意學習，可是合理安排二二六原則或其餘組合是更明智的，首先是專業能力要重點練習，其次能夠根據本身的興趣合理選擇一到兩個方面去慢慢了解，例如產品，運營，運維，數據等，畢竟三五年之後會不會繼續寫代碼很難說，多給本身留個機會老是有備無患。

在職場初期，基本都是從技術角度去思考問題，如何快速提高本身的編碼能力，在公司能穩定是首要目標，所以大部分時間都是在作基礎編碼和學習規範，這時可能90%的心思都是放在基礎編碼上，另外10%會學習環境架構。

最多一到兩年，就會開始獨立負責模塊需求開發，須要本身設計整個代碼思路，這裏業務就會進入視野，要懂得業務上下游關聯關係，學會思考如何設計代碼結構，才能在需求變更的狀況下代碼改動較少，這個時候可能就會放20%的心思在業務方面，30%學習架構方式。

三到五年這個時間段，是解決問題能力提高最快的時候，由於這個階段的程序員基本都是在開發核心業務鏈路，例如交易、支付、結算、智能商業等模塊，須要對業務總體有較清晰的把握能力，否則就是給本身挖坑，這個階段要對業務流付出大量心血思考。

越是核心的業務線，越是容易爆發各類問題，若是在平常工做中不花心思處理各類細節問題，半夜異常自動的消息和郵件老是容易讓人憔悴。

因此努力學習技術是提高本身，培養本身的業務認知也一樣重要，我的認爲這兩者的份量勢均力敵，只是須要在合適的階段作出合理的權重劃分。

05

基於技術能力和業務思惟，學會在職場作選擇和生存，這些是職場前五年一路走來的最大致會。

不論是技術仍是業務，這兩個概念依舊是個很大的命題，不容易把握，因此學會理清這兩個方面能力中的公共模塊是關鍵。

無論技術仍是業務，都不可能從一家公司徹底複製到另外一家公司，可是能夠把一家公司的技術框架，業務解決方案學會，而且帶到另外一家公司，例如技術領域內的架構、設計、流程、數據管理，業務領域內的思考方式、產品邏輯、分析等，這些是核心能力而且是大部分公司人才招聘的要求，因此這些纔是工做中須要重點積累的。

人的精力是有限的，並且面對三十這個天花板，各類事件也會接連而至，在職場中學會合理安排時間並不斷提高核心能力，這樣才能保證本身的競爭力。

職場就像苦海無邊，回首望去可能也沒有岸邊停泊，可是要具備換船的能力或者有個小木筏也就大差不差了。

閱讀標籤

【Java基礎】【設計模式】【結構與算法】【Linux系統】【數據庫】

【分佈式架構】【微服務】【大數據組件】【SpringBoot進階】【Spring&Boot基礎】

【數據分析】【技術導圖】【 職場】