什麼才是有價值的程序員？

01-05

遇到一種情況，作為一個java程序員工作到現在三年，換了兩家公司，遇到了讓我很矛盾的事情，下面我來說說我的情況：
1、第一家公司是在廈門的一家私企，剛進去的時候研發部門只有一個人，是一個做了七年java的資深程序員，也就成為了我的直接領導（總監），工作了將近一年也玩得比較熟悉，總監是專科畢業（而且每拿到畢業證的那種），開始打拚是做vb後來自學五年java，沒有進行過任何正統的培訓，開發的項目都是用基礎的servlet、原生js等最基礎的技術，但是一些項目都上線了並運維的很好，而且研發能力很強，基本上能用最簡單的技術做出很多前沿的功能，我加入之後開發一個項目，總監要求還是使用原生js等技術開發，jquery什麼的完全不考慮，因為他不熟悉,說用自己熟悉的東西才能更加高效的開發，這也是他堅持了這麼多年還是用這些開發的原因（想像一下一個項目幾十個文件，一個java文件幾千行的樣子），框架倒是採用了ssh但是都是新手，基本上是跟著網上的教程打框架做項目，最後用的不了了之，開發完這個項目之後別的不說但是基礎確實是鍛煉的很紮實，但是在前沿流行的新技術上知識基本為零，最後辭職離開了這個公司，奔著去學習其他技術的想法去各大公司面試，但是筆試題就很難過，張口就是spring閉口就是jquery，最後無奈在家修養兩個月苦學spring jquery最後終拿到工作。
2、第二家公司是一個比較大型的公司，裡面研發中心規模非常之大，分了很多部門，web開發部、美工部、中間層部、數據源部。。等等，總之大家可以想像做一個基礎的數據列表，你先要去美工部拿設計然後做出靜態頁面然後聯繫中間層給我數據、中間層去聯繫數據源部門最後完事再給web部實施展現出來，剛進去非常不習慣，以前的工作都是這些事全部自己一條龍做完，高效便捷，基本上一個下午就能做出功能效果，但是這個流程走下來最少要三天。而且第二個公司就是走了一個極端，所有項目都是用的比較前沿的技術 bootstrap，spring MVC+spring Security等等，接下來的一年中不斷的學各種新技術，最後我向公司申請讓我獨立完成一個項目，最後高效高質量的完成這個任務，最後我便成為一個獨立的部門負責一些棘手的項目開發。
現在的我已經遇到了一個非常煩惱的問題，我是一個有價值的程序員么？
從今年初開始我便開始在網上接私活，主要是做一些web平台以及企業門戶網站，後來項目越來越多就準備拉一些聊得來的朋友合夥一起做，然後問題就來了，我突然發現我的朋友們都是在一個領域熟練的程序員,比如做數據源的只會寫sql，做前端的只會寫js以及html、css，做中間層的甚至是一點html都不懂，更不用說部署伺服器、綁定域名之類的活了，而我雖然什麼都會全部都能幹，但是單獨做一個方面卻沒有他們一個人做的好，更加讓我迷惑的是前端總是想改變後端後端總是想改變前端，例如前端的人員經常會說前端總有一天會取代後端，比如說node.js，後端會後端的活比前端的活高端多了，前端都是一些淺層的東西，然後一堆緩存機制安全機制，我就是那個夾在中間的人，讓我位置很尷尬，因為我前端不如前端後端不如後端，但是他們離開了我卻無法獨立完成任何一個項目，我算是有價值的程序員么？

附加一個問題：作為一個程序員大而全更重要還是小而精？作為一個程序員的第一要素是效率還是技術含量？

自然是效率，但不一定是你認為的效率。

比如，快速寫出能工作的垃圾（醜陋，低效，陳舊等等）代碼，對於某些項目來說，就是有效率的代碼，他是有價值的程序員。但對於其他一些項目，比如一做三五年許多人參與的項目，一個bug分分鐘損失幾百萬刀影響全組年終獎乃至下一年項目撥款減半，那麼誰都沒法接受那種除了能跑一無是處的代碼。

同理，假如你都用高新技術，但工作完不成，也沒意義。項目做久了會發現簡直天天都要追求Practical。當然我的Practical可能是少寫幾個單元測試，你的Practical是性能差點，他的Practical就是「老子懶得做了」的借口。大而全還是小而精，也是要Practical的。

至於你，當然有價值，你都說了他們離開你就無法獨立完成一個項目，這說明你對你項目的價值，簡直大過我對於我項目的價值了，雖然換個項目就不一定了。

感覺題主跟我之前的困惑有些相似，或許這也代表了一大部分從技術入行人員的經歷，找了三句逼格比較高的古詩詞來說明，乃們不要起雞皮疙瘩：

1、少年不識愁滋味。

那些年，我們接觸了編程，不管是從傳統的VB、C、C++還是高端的java、js，我們總是漏掉分號拼錯單詞，總是從網上複製了一段代碼卻發現運行結果跟預期大相徑庭，總是對高手們彈指之間解決我們苦思冥想了半天的問題驚嘆不已。不過，程序調通了，結果成功運行出來，那滿滿的成就感還是能滿足我們小小的虛榮心。

2、衣帶漸寬終不悔，為伊消得人憔悴。

後來或出於工作的目的或出於個人愛好，開始鑽研起編程來，有去鑽研演算法以ACM為己任的時候，也有項目上系統出bug連夜挑燈夜戰的時候，還有誤操作刪了數據直冒冷汗的時候，當然程序猿們是一群好學的好青年，也少不了充電學習恍然大悟覺得自己掌握了一項武林絕學的時候。總之，雖然身體有點發福、腦門有點發亮、眼鏡有點發酸，不過感覺自己走在了成功的路上。

3、眾里尋他千百度，驀然回首，那人卻在燈火闌珊處。

忽然發現，自己也能帶個小弟酷酷的幫別人解決點問題享受別人的崇拜，也能跟朋友吹噓一下當年的事迹侃侃內存溢出、java框架辯論百度谷歌哪家強。自己對參與開發的系統和框架也遊刃有餘，出了問題自己總能找到解決的方案。原來所仰視的高手們好像也不過如此。

然而這個時候，往往卻是迷茫的開始：到了這個年紀，該成家立業了，是不是該多花點時間陪陪家人；身體開始衰老了，不能熬夜了，是不是應該開始學會養生了；對人生有新的認識了，技術是不是能做一輩子，但是不做技術又做什麼？

這可能是一個典型的技術人生，雖說互聯網時代有不少技術出身的CEO、產品大牛，但是相對於龐大的基數，這種機遇概率很小。那麼程序猿的價值在哪呢？是幾十萬行的代碼，幾本邊角發黑的大部頭技術教程，還是認識的一起喝喝酒吃吃肉的好機油？這些肯定都不是程序猿最大的價值所在。程序猿往往沉浸在技術中，當然有的時候這種沉浸是有必要的，但是在互聯網成熟的時代各種技術層出不窮，會了前端不一定會後端，會了後端可能還不能成為資料庫專家，就算是對各種軟體技術了如指掌如數家珍的大神也未必了解如火如荼的硬體技術。程序猿除了沉浸到技術之外，還應當學會跳出技術圈看問題。這時候你會發現：

IT技術無非是一種解決現實問題的工具，程序猿最大的價值應該在於會使用這種工具來解決實際的問題。

一個只會用一百種程序語言列印「hello world」的人沒有多少價值；而一個能帶領工程師團隊通過計算機和互聯網的方法解決中小企業融資難問題的人可以稱得上大牛了。編程的過程實際上是一個現實與計算機結構映射的過程，能夠將二者進行很好轉換的程序猿才是最有價值的程序猿。這種能力會是程序猿一生的財富。

沉下心來好好想一想軟體復用思維，既是自勉，亦是給我輩同僚之激勵。

我相信許多對復用抱怨的人，可能了誤解的復用的含義。而那些強調局限性和折中的人，很可能本身已經擁有良好的復用功底，因此對他們來說，復用的程度更多取決於現實需要。因此這個問題對於開發老手來說或許不值一提，對於新人來說，卻絕對重要，它在某種程度上決定了你作為一個程序員所能到達的技術高度。

直截了當的回答，在我看來，阻礙復用的因素只有一個：開發者自己。具體的說是開發者自己的習慣、思維方式和經驗。軟體設計是一項思維工作，工作的一個重點就是描述流程和劃分模塊。劃分模塊的目的，除了邏輯清晰化和便於分工之外，最重要的就是復用。只有把一大堆功能拆分成若干相對獨立的小功能，才方便我們把小功能封裝起來，隨時隨地被其它功能（模塊）反覆使用（調用），這本身就是復用。

從最原始的程序塊上升到函數、類乃至設計模式和架構，是對程序功能一步步抽象和靈活描述的過程，也是提高復用性的過程。為什麼我們需要架構師？就是因為架構師能夠對整個程序，以及程序可能發生的變化做一概括性的描述，在此描述之內，可容納程序所需的所有具體功能，並可對功能變化表現出適當的容忍性、靈活性和可擴展性。如果不考慮復用，功能稍有變化就要修改或複製大量代碼，我們要靈活性和可擴展性有何用？要架構和架構師又有何用？

或許有人會說，我們開發的程序很小，根本不需要架構師，對復用沒有那麼高的要求，儘快滿足客戶的要求就好。這個說法的邏輯，如同磨刀一定會誤了砍柴功一樣，正確，但不合理。我見過涇渭分明的兩類程序員，同樣從幾乎完全沒有經驗的應屆畢業生開始，一類天天忙的喘不過氣來，成果卻不多。另外一類卻越做越輕鬆，進而經常幫助別人解決問題。除了努力程度之外，是否具有抽象、復用的思維（當然這也可以歸結為悟性），是他們在開發能力上的一大分野。

相信大家見過這樣的優秀程序員，從一個項目轉戰到另外一個項目時優秀，從一種語言轉戰到另外一個語言的時候依然優秀，甚至從一個領域轉戰到另外一個領域時還是優秀。儘管這種優秀是相對的，但是主要原因在於他能把一個項目、語言、領域的經驗復用到另外一個。這是更高層次的復用，而其基礎依然來源於軟體開發時復用思維的培養與實踐經驗。

那麼，具體來說開發者自己的習慣、思維方式和經驗是如何阻礙復用的呢？首先，如果一個開發者在編碼之前根本不做任何「程序設計」方面的工作，一接到任務就開始埋頭於功能的實現，那麼別指望他的代碼能有什麼復用性，也別指望他能培養起什麼復用的思維；其次，如果一個開發者不經常尋找相似模塊之間的共性，不打算讓自己的模塊體現出更強的靈活性，他就沒有復用能力，也無法建立復用的思維；最後，如果一個開發者沒有足夠的經驗，他也很難確定復用的邊界，很有可能引發過度設計或者放棄復用。

因此，作為開發者，抱怨用戶是沒有用的，抱怨需求分析師、項目經理或者架構師也是沒有用的，交給你的模塊在你手中，它的復用性只取決於你，你想讓它復用性高一點，那就花點心思去分析和設計。如果你要偷懶，那也隨你，只是不要把介面放在別人身上。如果你說你的工作實在太多了，根本沒有時間考慮這方面的問題，那我除了對你報以深深的同情之外，只能說一句：同學，身體和職業前途為重。

那麼，如何培養開發者的復用思維？就我的經驗而言：

首先是嚴禁複製代碼，絕不允許同一個項目或產品的成員複製其它成員（包括自己）的代碼直接插入自己的程序，複製已有代碼的願望說明代碼上有較大重複，已經構成了復用的條件，在時間允許的情況下，應該要求原開發人對代碼進行封裝，然後由你來調用。如果時間上來不及，最低限度的折中也是你把這段代碼複製過來之後進行分裝，然後調用；

其次是對設計過程的強調，新人在開發前，一定要有老手帶他進行程序設計和後期的代碼審核，這會花費老手的時間，但是回報絕對值得，設計過程培養的不僅僅是新手的復用思維，而是軟體開發的基本功，這個基本功與對語言的熟悉程度和項目經驗具有同等價值，長期看甚至過之；

最後是適當的交流與指導，實際上，復用問題是新人最容易遇到的第一個顯著成長瓶頸，有經驗的管理者或者同事很容易發現，在對開發語言和項目逐步熟悉之後，編碼成為最不費腦子的工作，而如何避免讓自己成為體力勞動者，或者說如何讓自己的每一次勞動成果都獲得盡量多的後續應用，即復用，開始檢驗新人的悟性。有悟性的人會自己琢磨、學習、嘗試解決，沒有悟性的人就開始苦惱。這個時候，就到了指導他們重溫面向對象的設計、設計模式等知識的時間了，從這些老生常談的知識，結合具體的項目實踐，所能挖掘出來的復用思維和技術，可能超乎大部分計算機專業畢業生的想像。

事實上，為了解決復用設計問題，我曾經為公司的新人專門開過一門夜校課程，名字就叫「軟體復用」。我向他們解釋軟體復用的極端重要意義，過程很簡單，列出了某開源PHP框架對於MVC架構實現的核心代碼，解釋了短短几行代碼所體現的多種設計模式與巨大靈活性。所有人都震驚了，許多人開始意識到編程並不是寫代碼，更是一種邏輯思維，如果把編程只局限於寫代碼的水平，那麼「碼農」的稱謂當之無愧。而在這種邏輯思維中，抽象能力是核心，也是復用的基礎。

通過大約10多個小時的夜校課程，我很難說顯著的提高了他們的水平，但有一點值得欣慰：就是大多數人都接受了「高內聚、低耦合」的思想。眾所周知，「高內聚、低耦合」只是模塊劃分的核心原則，但真正掌握了這個，就基本上邁進了軟體復用的門檻，剩下的是實踐和提高問題。

上面是從培養的角度來說。對於程序員新人的自我學習，如何提高復用水平，答案也很簡單：思考、抽象與重構。首先思考模塊劃分問題，怎麼劃分才能儘可能的保證模塊的獨立性和靈活性，其次尋找相似模塊之間的共性，如果找不到，說明抽象程度不夠，再往上抽象；最後，捨得花時間重構代碼。我完全同意前面大部分人所說的同樣代碼寫到第三遍就會噁心的觀點。如果你有時間寫三遍，卻沒有時間重構後，讓它被調用兩遍，真的很難說到底是偷懶還是過於勤快。

當然復用總是有邊界的，開發過程中總會遇到復用所帶來的複雜性與時間和代碼可讀性之間的衝突。這個時候發揮作用的是經驗，這個經驗既包括復用技術方面的經驗，也包括用戶需求方面的經驗，都需要積累。但是這個衝突不應成為阻礙復用設計的借口，復用首先應該是滲透入程序員血液中的思想，否則前人所作的一切工作，你自己完成的所有任務，理論界、技術界大牛所提供給你的一切工具、模式都是白費。在擁有這個思想，積累的一定的經驗之後，你再說：在這個功能點或項目中，復用考慮的不夠；或者，在那個功能點或項目中，過多考慮復用並不合適；因為blablabla……

恭喜你，這個時候你已經是一個合格的程序員了。

因為在我看來，復用從來沒有該不該的問題，只有夠不夠和多不多的問題。

國內工作過一年，然後去歐洲了，聊聊歐洲的軟體開發：

1. 研究所，基本上都是博士，作為碩士，混進去幫忙寫最基礎的代碼，web展現，rest，soap跨域都是我寫的，博士們寫核心演算法，用各種開源包，每個人負責一個部分，控制一台伺服器，最後我來整合寫界面，很明顯的發現，每一個博士java用的包都不一樣，同一套需要rest格式的代碼，就用了3-4套不同的開源組織包，每一個人都在一台自己的伺服器上面建立自己的服務，源代碼管理也只針對個人，所以最後討論也是我一個人和4個博士討論他們寫的介面，有json，有xml，triples,turtule等不同類型數據，我們之間雖然能讀到對方的代碼，但是極少會有分歧，我們完全不管別人怎麼實現的，討論也只針對介面怎麼傳值的問題，你看這種開發怎麼樣？

2.國內從資料庫，寫到web，每個人分不同的模塊，有架構師寫好調用的主要的方法，資料庫也主要是存儲過程，團隊里每個人不太了解其他人的模塊完成的怎麼樣，有問題，或者沒有實現的底層功能直接問架構師，然後他寫，如果這個功能別人用不到就分配你自己完成，美工什麼的提前做好圖片，設計按照自己的興趣設計，沒有固定死，但要求了每一張頁面的功能。

3.sap，沒在裡面工作，但歐洲sap和我聊了很多次，也聊了很久，各種分散式系統ABAP，大數據管理sapHANA，手機前端最後傳值還是json，所有ios或android用源生代碼……橫向分層，所有人只會一個部分技術，資料庫的做資料庫，手機的做手機，最後討論的只有json的傳值問題，但是資料庫不是一個人而是一個團隊，團隊之間會討論，手機開發也是……

所以樓主的答案是：

1.樓主有價值，或者說是最有價值的一種成長方式。

2. 不同的公司對於價值側重不同，小公司就是追求目的，所以快就好了，大公司追求分工，最專業的人做最熟悉的內容，最不容易出錯，研究所追求演算法，演算法對了，用什麼技術都一樣，怎麼排架構也完全無所謂。所以不同的情況價值不同，不用那麼在意，當出現爭執的時候，他們關注銜接部分，其他的一概不討論。

猜測下題主產生問題的原因，是有些太跟著工作內容跑了，工作中做什麼就擅長什麼，我總覺得人要做自己喜歡的事情才高效，那麼順序應該反過來，先確定自己喜歡什麼，再決定找什麼工作。

那麼問題來了，如果我做不了自己喜歡的工作怎麼辦？我的經驗是曲線救國！先做掙錢的，私下學習自己喜歡的，而且我學發的感覺這個思路不管是救國還是深造都適用

拿我所在的前端開發來說，業務需求無非是做做頁面，兼容下各種瀏覽器，有該死的ie在新技術實踐也很受限，這麼做一陣子你就會發現我擦，這行業還有沒有前途呀，這麼無聊。但是如果跳出需求的圈子就會發現太多精彩的東西了，這些東西pm可不會告訴你。

剩下就是利用業餘時間充實自己，一段時間後再回過頭來看業務需求，會發現這裡面可優化，升級，改進的東西還挺多。

功夫下在工作外，只靠工作經驗的鍛煉嘛，就像小重量鍛煉一樣，最多是能力夠用，我覺得應該成不了高效的程序員，當你的能力大於工作所需時，就高效了

吃飯時候答得回來看了眼似乎跑題了，補充下。

曾經我很鄙視粗糙的代碼，總喜歡搞得精緻而完備，代價就是做的很慢，要知道，世界上沒有不變的需求，有時候有價值的需求就是在一堆無價值的改版中提煉出來的，那麼作為程序員就需要提供快速驗證的能力，不要總想著用完美的代碼對應完美的需求，這兩個都不存在，說白了都是改出來的，我現在理解的高效就是沒時間時能寫出可運行的垃圾代碼，有時間時能改進的精緻。但不要理解為趕需求就可以胡寫了，精緻的能力也是需要在工作外鍛煉的，不然等你回頭想做好的時候發現做出來的和垃圾代碼也差不多

再補充下附加小問題的個人見解，先要有一門拿的出手的絕學，再橫向發展，某個領域的專家光環可以讓你在整個組織中有一定的地位，才能與其他領域的專家平等討論問題（這絕對是客觀存在的理由），然後再去做不同領域間的潤滑劑或者擴展

這是很多人的必經之路，其實跟職業發展相關。做技術方向大體有兩種：一是有技術寬度，可能某個專項也有深度，就像題主一樣。另外一種就是專精某種技術，就像題主提到的其他羨慕的工程師一樣。

先說第一種，之後的職業發展可選團隊領導，PM，系統架構。也就是通常的管人，管事，管技術三條路。為什麼？因為這樣的人是其他成員溝通，合作的橋樑，有系統，大局觀。那麼有溝通，領袖氣質的當團隊領導。對產品有偏愛的走PM,產品狗路線。對技術仍舊痴迷的走系統架構，前沿技術研究，技術路線戰略規劃路線。

第二種，技術專精。請慎重選擇技術，因為互聯網技術的更迭太快了，本身這個行業能夠積累的東西就少，所以選錯的話只能從新打怪升級。這種方向請選擇將要火的技術，請不要選擇現在人人都會的技術。同時，關注技術發展方向，不要掉隊，情勢不對果斷換技術。請參考Flash技術的流行趨勢。個人建議，選擇能積累的技術並積累解決問題的能力與經驗。

單純專精一項技術個人認為在國內有風險。純屬個人意見。

有點跑題，回到樓主問題。只要能解決問題的都是社會需要的，分工不同。你做項目各種不同類型的人都要。一個有價值的程序猿並非是技術牛人，而是能夠符合企業需求，給公司，社會創造價值的人。

是小而精，還是大而全？發展路線已經表明了。如果你是一個致力於解決具體問題的人，請小而精。如果你有系統觀，或者想發展這個方向，請大而全。

要效率還是技術含量？這不是重點，重點是哪一個能帶來利益。如果提前出貨能佔領市場，我希望你效率高點，儘快解決問題。如果高技術含量能夠提高產品技術壁壘，從而帶來更多的市場，那就要技術含量高的。一切根據需要和能帶來的利益決定。

體現價值的幾種方式：

1. 一般價值：把部署給你需要完成的本職工作做好

2. 超出價值：超預期的完成你需要完成的本職工作

3. 不匹配價值：你能完成不是你這個level就能完成的工作，比如程序員干架構師的活

完成一般價值，你對你的公司就是有意義的

完成超出價值，你該漲薪了

完成不匹配價值，你該換工作了

單純意義上，程序員本身沒有任何價值！

樓主應該問的是：什麼才是有價值的IT人員？

我們先來聊一下工廠，一般的工廠大約分工如下：操作工、組長、線長、車間主管、銷售/市場（簡化）、總總總（你懂的）。我現在問你，在工廠的這些分工里，哪個分工收入最高？哪個分工技術含量最高？收入最高的比較好理解，最後那個總總總們肯定是高高在上的，技術含量呢？以我初入社會在工廠擰螺絲的經歷來看，少數操作工和車間主管的專業技能相對會高一些（各種情況不同，大約而論）。

那麼現在問題來了，你指的有價值是收入價值還是技術含量呢？你需要先說將自已定位好，你未來3-5年內希望你的價值體現在哪一塊，把自己對號入座，再來一步一步規劃你的精彩人生。

IT行業既有以技術為路線，也有轉移陣地，以業務或管理為路線，實現自己的人生價值。正如樓上部分朋友所說，現在這個市場經驗里，最終的衡量標準就是收入；但賺錢這事，就像找對象，只有讓對方求著你，你才會更有話語權；那麼如何讓對方求著你呢？增加你的魅力值我想是唯一的方法。

以上結論適合醜小鴨向白天鵝的轉變，但不適合小天鵝向大天鵝的轉變，因為根本不需要轉！

最最最重要的就是賺錢. 是的你工作不就是為了賺錢么?你的公司僱傭你不就是為了賺錢么？

一個能賺錢的程序員難道不優秀么？

問題是怎麼賺錢？用盡量少的資源做出盡量多的成果，不就能賺到更多的錢么？

所以，你要：

１理解需求，我要做什麼？

２實現需求，怎麼做速度快？

３維護需求，怎麼樣更好的維護產品？

至於用什麼語言，用什麼格式，那個都是入門程序員考慮的問題．

不要沉溺於技術無法自拔，那個只是手段．　　

高級程序員只考慮一個問題，怎麼賺錢？

或者說的委婉點,　怎麼滿足用戶需求？

一個有價值的程序員，你得先問自己，什麼是價值？如果賺錢是價值，那麼你現在的工資就是價值，如果創造是價值，那麼你創造的東西就是價值，所以你應該清楚自己的價值在什麼地方，如果有興趣想玩點新東西，我手上剛好有很多點子，有興趣@我

來北京兩年多，第一份工作讓我接觸了Ruby開發，在哪裡學習到了ruby的入門知識，也開始漸漸喜歡上了這樣一門高效簡潔的開發語言，和之前用Java開發相比，至少讓我體會到了開發的樂趣.......第二份工作負責手機應用後台的開發，更多的是負責SQL查詢，數據格式轉換，數據處理的工作，在這裡，讓我了解了更多更深層次的技術，發現之前所掌握到了技能在做後台方面基本沒有什麼大的用處，只要悶頭學習相關的，經過半年的工作及同事的幫(zhe)助(mo)，總算能獨立處理手機端各種莫名其妙的功能需求，由於公司調薪方面的問題，到了第三家，剛到這裡的時候，覺得自己還是有一定的小水平的，經過一周的學習，發現我來這裡負責的不是數據端的處理，而是前端效果展示，這裡就不得不提到我的一個硬傷，完全不會寫JavaScript，哦(keng)買(die)糕(a)！！又是一個悲傷的過程，現在能完成一個小效果JS的功能，頁面透明處理，一些負責的功能還是需要公司專門寫JS的大牛幫助才能實現。。。。。。

作為程序員，只有都經歷過前端和後端的實(zuo)踐(si)，才能讓自己更好的理解程序的實現機制，並不是想像中那麼簡單，每一個簡單的功能背後，都凝絕著很多人的心血和智慧的結晶，引用一個朋友的話 No Can No Bi Bi ,You Can You Up。

另小弟有個疑問：挖掘機技術到底哪家強？

有ruby同仁可猛戳:https://ruby-china.org/lonely21475

======================================================================

所謂的價值，我覺得只要自己內心的目標不斷的在為之努力，不放棄，就是我的價值~

輕鬆解決別人解決不了的問題……

大道入簡能用簡單的技術做出前沿的新東西這個就是有價值的

程序員寫代碼追求的是效率，這裡的效率是指你的代碼有很強的可讀性

便於擴展維護什麼的，當然追求演算法性能什麼的更好

怎麼樣才算一個好的程序員，我也經常在想，現在在一家小公司，工作3年多，前台後台資料庫，一條龍自己動手，最開始覺得很新鮮，熟悉不同的東西，慢慢自己就能掌握整個過程，對項目及業務的理解還是很有幫助的；

過了一段時間，會覺得其實挺累挺操心的，可能我最想做的是自己最感興趣的那塊，我更希望成為某一方面的專家，而不是現在什麼都懂，可其實也沒有專門做這方面的人懂；

所以我覺得，最開始不妨做個全才，個個層面都要接觸一下，看看自己哪方面能做的最好，然後成為這方面的專家，哈哈~~

我被這個問題困擾很久，後來轉變了思路，你的價值不是你，而是你能幫多少人。

http://hui-wang.info/2017/01/01/%E5%A6%82%E4%BD%95%E6%8F%90%E5%8D%87%E7%A8%8B%E5%BA%8F%E5%91%98%E7%9A%84%E4%BB%B7%E5%80%BC/

跟樓主相似，我是搞嵌入式的，都說小公司學做事，一點不錯。單片機，嵌入式，硬體設計，PCB設計，電路焊接、調試，軟體開發，linux驅動與應用, 資料庫， wince , c#軟體開發, python建模分析。。。軟的硬的啥都會！

但是靜下來想想我都會啥啊！啥都不會！沒一個精通的！

正在迷茫中。。。。

題主是在試圖挑起前端和後端的戰爭嗎？

開玩笑。其實題主不正是一個全棧工程師嗎？很多時候小企業就需要這種人才來起步:能力廣，見效快，而且像萬能膠水，粘合力強。

其實還是那句話:金子總會發亮的