作為一個開發者，最關心的不外乎提高自己的軟體開發水準。那要從何做起呢？積累技術知識（比如 Node 或者 No-SQL）？死命嗑那些經典的演算法問題（比如氣泡排序法或者網址縮短程式）？或者是穩固基礎？
作為一個工程師你的價值不是由你知道什麼來衡量的，而是由你能做出什麼來衡量的。兩者看起來相似，但有著天壤之別。你的價值在於如何將專案不斷向前推進，並帶領團隊一起進步。15 年的開發生涯中，我從未需要去實現一個氣泡排序演算法或是網址縮短程式。我要做的是花成千上萬個小時來編寫和重構帳戶管理工具、郵件系統，編輯套件、測試套件，整理業務邏輯，部署腳本、JS 層，進行架構分析以及文檔管理等等。這些才是真正有意義的東西，完成了這些我們才能往前邁進一步。
開發這些組件，就像搭建專案的一磚一瓦，需要花費幾百上千小時的努力來琢磨。它們組成了複雜的系統，但它們本身卻保持簡單。軟體之美就是「簡單」。這些年的經驗讓我悟出的道理是，把時間花在編碼和重構上，這比純粹靠「才華」和空想更能實現目標。
執行、完成任務然後迭代，才能實現軟體開發「簡單和高效」的目標。深植於我們腦海深處的關於創業的宗旨，就是先構建基礎，然後迭代。軟體開發亦是如此。先開發一個粗糙的版本，然後重構、修補錯誤、精簡。要得到結果，你得老老實實去寫程式！去執行！
“Your value as a developer is measured not in the height of your peaks, but the area under your line.”
— Peter Nixey (@peternixey) April 22, 2014業界一直存在這樣的誤解：一個商業公司要完成出色的產品，需要靠那些小圈子的名人怪咖。可是在現實生活中，這樣恃才傲物的一小部分人雖然在感興趣的方面有著驚人的才華，但與團隊相處很不融洽，工作起來也很不沉穩。他們不僅沒有實際成果，自以為是的優越感還會影響團隊的氛圍。他們總認為自己天賦異禀，想幹才幹，愛幹才幹，但他們影響了團隊，還會扭曲其他人的價值觀。
要成為真正傑出的開發者，應該從實幹做起，遵循以下準則。
規範的函數和變量命名
難以置信，這在編程中這是如此簡單卻又如此重要的法則。清晰的函數命名，常常伴隨著清晰的邏輯實現。例如：
…
end
def safe_convert_to_html string
……
end
這樣的函數命名方式，準確反映出了函數有什麼而且僅有什麼作用。
Function names create contracts between functions and the code that calls them. Good naming defines good architecture.
……
這樣的命名方式很難讓人讀懂，即便讀懂了，也很難保證完全了解的作者的意圖。這個變量命名很糟糕，不能傳達任何信息。而且「AND NOT」(&& !) 這樣的語句本來就非常晦澀難懂，更別說在語句後面還跟著一個名詞了。如果有人要重構這段程式的話，恐怕需要先費盡腦子搞清楚原作者是在幹什麼。如果將變量命名規範化，情況會很不一樣。
我們可以進一步藉由分開和命名，強迫註釋if中的每一個部分的意圖，將這段程式撰寫成這樣：
invitation_is_unsent = !user.invitation_token
user_has_not_yet_edited_profile = (user.created_at == user.updated_at)
if user_is_recently_created
&& invitation_is_unsent
&& user_has_not_yet_edited_profile
...
我們鼓勵開發者寫出像是 user_is_recently_created 這一行程式碼，因為這是一個模糊的邏輯，藉由這一行可以提醒讀者先前程式的假設。請注意，這樣的程式碼會比程式註解來得更有力。一旦邏輯改變，那麼你就立刻被迫要改變變量命名。我同意 David Heinemeier Hansson 的說法，註釋是危險的而且近乎陳腐的，最好是寫出能自我註釋的程式碼。
“If you want to be a great developer, make sure you write Ronseal Code that does exactly what it says on the tin.”
工程師在開發過程中，常常會遇到各種各樣的問題，但很少是完全陌生、其它團隊也沒有遇到過的。在 Stack Overflow 上最吸睛的提問，大多曾在其它地方出現過。
“Most programmers waste huge amounts of time by lazily re-creating implementations of pre-existing functionality.”
好好穩固自己的基礎吧！如果你是一個 Ruby 工程師，就好好學習 Ruby 豐富的數組方法；如果是 Node 開發者，就好好去理解 Node.js 的架構；如果是 Angular 工程師，就去理解其內核背後的邏輯。在動手實現之前，先仔細查閱文檔。記住，我們都站在巨人的肩膀上。把時間花去學習那些頂尖工程師的思路和方法，要正確的多。
培養對程式的嗅覺
很多工程師水準不錯但是遇到了撞牆期，問題常常出在他們不知道如何提升自己。這也許是技術生涯裡能夠遇到的最糟糕的事情了。要想知道如何提升自己，首先得知道需要在哪方面有所提升。一個優秀的象棋手，總是會花時間研究其他優秀棋手的路數，對於一個優秀的工程師來說，也是如此。
要想提升自己，最好的辦法莫過於培養對程式的嗅覺。哪怕不能清楚地說出原因，也能察覺到一段程式的問題在哪裡。什麼是程式嗅覺？比如讀到一段很難懂的程式，會察覺到哪裡有問題。面對一個很基礎的功能，你會覺得語言本身應該有函數封裝。要培養對程式的嗅覺，需要培養對程式的審美水準。程式之美，簡單優雅！
在開發的過程中，應該力圖將程式寫的簡單優雅。如果只能用複雜醜陋的方法實現，那起碼要邏輯清晰。沒有對優雅和糟糕程式的嗅覺，技術水準將難以提升。
提升程式可讀性
Joel Spolsky 曾經說過，Stack Exchange 不僅造福那些提問者，也造福那些看到提問的閱讀者。為什麼？因為許多人遇到的問題都是相似的，這些相似的問題都可以參考這個解決方案進行處理，效用便最大化了。
“Write your code through the eyes of someone who is coming at it fresh in a year’s time.”
重視產品的生命週期成本
新手開發者們熱衷探索和折騰。他們熱愛那些最新最閃亮的技術，不管是No-SQL數據庫還是高度平行處理的移動伺服器，總是恨不得儘快把所有新工具新特性使用起來，但是這樣往往會給後來的開發者留下一堆爛攤子。
Dogs aren’t just for Christmas and features aren’t just for the next release.
除非你有足夠的理由，否則千萬不要使用那些尚處於測試中的功能。所有主要專案的開發，都應該小心翼翼。如果非要嘗試這些新特性，最好在那些輔助專案上嘗試，這樣保險得多。為了將來不把大量的時間都用來彌補前期捅的婁子，要謹慎使用新特性。
Just use Postgres.
Stop being a hipster, and just use Postgres.
— Tony Million (@tonymillion) December 29, 2013技術負債是指那些你必須使用它們，可是它們是欠佳的但還能工作的程式。它們是惱人但卻較不緊急的錯誤。比如：倚賴伺服器服務的單一app架構的複雜度問題；或者一個重構後只需要十分之一執行時間的cron任務腳本。
技術負載不僅會累加，還會帶來複合效應。愛因斯坦說過，「世界上最強大的力量是複利」。類比到軟體開發上，技術負載的複合效應也最具有毀滅性。多數開發者遭遇過這樣的專案：程式碼只要一點點輕微的改變，都不得不花費幾個月的時間。或是開發者失去撰寫優雅程式的意志，而只求不要搞壞整個服務的這種專案。
Like all debt, when used correctly, technical debt can give you tremendous leverage.
技術負債，就像一個蛙跳遊戲。最初的程式都只是嘗試，只要能實現目標快速推進就好。這讓我們有足夠的時間來提出解決方案，足夠的空間來建立基礎設施。產品的生命週期越長，投入在基礎設施上的時間就越長。有了穩固可靠的基礎設施架構，才能支撐起一個高品質的產品。
Check and re-check your code. Your problems are yours to fix
Engineers who “throw code over the fence” are awful engineers. You should make sure your code works. It’s not the testers’ job and it’s not your team-mates’ job. It’s your job. Lazily written code slows you down, increases cycle times, releases bugs and pisses everyone off.
If you constantly commit code that breaks things then you are a constant tax on the rest of your team.
Don’t kid yourself that you’re anything less than a burden and get it fixed.
Do actual work for at least (only) four hours every day
For all the talk about self optimisation, focus and life hacking that goes on amongst developers, the simple truth is that you don’t need to do that much work to be effective. What really matters is that you do it consistently. Do proper work for at least four solid hours each day, every day and you will be one the best contributing members of your team.
However, doing four hours of work every day is harder than it seems.
Proper work is work that includes no email, no Hacker News, no meetings, no dicking around. It means staying focussed for at least 45 minutes at a time. Four hours of work a day means that one day lost in meetings or on long lunches and foosball breaks means you have do eight hours the next one. Believe you me, eight hours of solid work is almost impossible. Four hours a day on average also means you should be aiming for five or six in order to prep for the day when you only get two.
However it also means you can be a huge contributor to your team while still having a fully rounded life. It means that you don’t need to post that self-indulgent “I’m burning out, please help me” post on HN. It means that simply by being consistent you can be valued and respected.
Software teams don’t slow down because people work four pure hours a day rather than seven (which is insanely hard to do consistently by the way). They slow down because people spend weeks with no direction, or because the louder and emptier vessels dedicate their paid time to discussing Google v. Facebook’s acquisition strategies over endless extended coffee breaks.
Just work. Doesn’t matter how incremental or banal your progress seems…
Do four pure hours of work each day, every day and you’ll be one of the best people on your team.
不管用什麼樣的風格來註釋文檔，不管是用郵件還是Wiki，一定要花時間記錄開發流程以及所用到的資料，並分享給其他團隊成員。他們和你一樣，也會遇到各種安裝和調試的問題。軟體開發中，最令人頭疼的事情就是花費大量的時間來解決bug和安裝調試。如果你用一點時間來製作文檔或者教程的話，將為團隊省下更多的寶貴時間。
把握好測試的平衡
Think of testing like armour. The more of it you wear the harder it is to hurt you but the harder it is to fight too.
至於進行多少量的測試，沒有直接的答案。每個專案需要的測試總量和測試點都不同。在開發的過程中，我們應該下點功夫理解什麼部分是真正需要測試的，什麼時候測試才會產生價值。不要害怕進行測試，也不要害怕不進行測試，只要找到其中的平衡點就好。
讓團隊進步
你的存在，是讓你的團隊變得更好了？還是拖累了團隊？
你的程式品質、文檔和技術水平，是不是幫助周圍的人有所提升？
你有沒有啟發和鼓舞隊友，讓他們變得更好？
或者，你是那個bug製造者，浪費時間爭論無意義的架構問題，到最後沒有實際產出的人？
一個傑出的開發者，應該影響他周圍的人，讓團隊一起進步。
成果最重要
「你是誰並不重要，重要的是你做了什麼」，電影《蝙蝠俠》裡這句台詞很適合用在軟體開發者身上。
作為一個開發者，你有多聰明，了解多少技術知識並不能衡量你的能力。你的簡歷上，會寫你會什麼語言、在哪裡上的大學、在哪家公司工作過等等，這些只能顯示出你會什麼，能做什麼。但真正衡量你作為一個開發者的價值的是，你做了什麼，專案和團隊因你而改變了什麼！
原文來自 ："How to be a great software developer"
http://peternixey.com/post/83510597580/how-to-be-a-great-software-developer
作者簡介： Peter Nixey，Ruby on Rails 工程師，前電腦視覺學者、企業家，Clickpass 公司 CEO，YC 育成中心的企業規劃導師，Brojure 公司 CTO。
參考雷鋒網翻譯：
http://www.leiphone.com/how-to-be-a-great-developer-1.html
翻譯錯誤部分已經修正，包括程式碼說明和部分專業術語解說。
