這篇的原文是《10 Reasons Why You’re Failing to Realize Your Potential as a Developer》，在文中，作者是歸納出讓「大部分的程式設計師發展停滯的十種主要行為」（10 performance-killing behaviors that stagnate the careers of most developers）；而在大陸那邊，有簡體中文的整理（應該不完全算是翻譯了），有興趣可以參考《如何成为强大的程序员？》這篇。
下面算是 Heresy 自己的整理（也不是完全的翻譯）：
-
太害怕學不會新工具、語言或框架
You’re too afraid of failure to learn new tools / languages / frameworks有許多人因為害怕嘗試、或是可能性的失敗，而害怕去嘗試新的技術。他們可能是害怕去學習新的東西，會丟下自己經年累月的經驗。
但是真正強的開發者會擁抱這些挑戰、機會，學習新的方法來做事。 -
在功能完成前都不送出自己的程式（但是永遠不會完成）
You won’t push your commits until the feature is "done." (It’s never done!)有的開發者因為害怕受到批評或審查，而沒有辦法在「完成」一個工作之前，就把自己的程式碼送出去讓團隊的其他成員也去看；而這樣的行為會導致整個團隊的生產力降低，因為這樣通常會產生一些最後才找到的問題，而導致整個進度的落後。
而真正強的開發者會更常地去把程式碼讓其他成員也可以看到，並接受批評與建議。 -
一知半解是危險的
You know just enough to be dangerous很多時候，對於一個新的東西，比如說新的函式庫、語法，可能可以很快地知道它的用處、以及它可能的好處，但是如果在沒有完全的了解他的強況下，就去使用的話，很有可能變成是一種不適當的濫用。像是 multi-thread 等架構的程式，實際上是很容易寫出危險的程式的。
一個好的開發者，除了要知道一個東西是什麼、怎麼用外，更應該去了解它的他怎麼做的、以及它的使用條件。 -
分析癱瘓
Analysis paralysis一個常見的問題，就是「過度分析」，進而造成害怕做出錯誤的決定。基本上，研究室簡單的、實作是困難的。很多程式開發者會希望在第一次測試前，就可以做出一個完美的決定。
而強的程式開發者，會寫一些程式、然後測試，然後在 45 分鐘內發現這不能用，就把他丟掉。他們會限制自己研究的時間，因為通常這不管用。 -
沒有投資在工具或開發流程上
You dont invest in your tools or development process一般的程式開發者會花很多時間學習一些很炫的語言功能或 API，但是實際上他們還是平庸的。如果希望成為一個好的程式設計師，你需要投資時間來增進技巧與知識，而一個最重要、最有區隔性的，則是讓自己可以快速地寫出產品等級的程式：同時兼顧品質與速度。
大部分的時候，可以做到的最大改進，並不是專注於在改善程式碼上，而是改善寫程式的流程。而實際上，善用現有的工具，可以有效地改善自己的程式開發效率。 -
羞於請教、求助
You’re too embarrassed to ask for help一般的程式開發者羞於讓他人知道自己的無知，所以假裝自己知道，結果產生了許多可怕的程式碼。
實際上，沒不用擔心說出「我不知道這啥」這種話，當自己不行的時候，就需要求助。 -
不知道如何讓別的程式設計師使用自己的程式
You don’t know how to make it easy for other programmers to work with your code.團隊工作時，很重要的一件事，就是要能夠讓多人同時進行同一個程式的開發，同時也要可以非同步地進行：每個人都要可以修改別人的程式。
一般的開發者不會考慮到這些，他們輕易地認定只有自己會用這些程式，然後可能包含一些不好的習慣，或過於抽象的風格，導致別人幾乎無法閱讀。而真正強的程式開發者，則是會盡量讓自己的程式是易於維護、並可以自我解釋（self-explainable）的。要寫出可閱讀的程式碼，是需要程式開發者改變自己的眼界的：你的程式碼在團隊裡應該會待得比你久。 -
不知道如何（或是不想）閱讀他人的程式碼
You don’t know how to read someone else’s code (or don’t want to.)一般的程式開發者在接觸到自己不熟系的語言或框架的時候，第一個想法會是想要用自己熟系的方法來砍掉重鍊，也不想依循他人的程式。
但是，真正好的開發者要能接受：在商業成本考量上，重寫通常是不可接受、而且應該避免的。然後，試著去了解、學習、並修改現有的程式。讀程式實際上比寫程式困難，但是要成為優秀的程式開發者，就要想辦法去學習如何去做這件事。 -
無法從用戶的角度來寫程式（考慮的太少）
You can’t code from the end-user’s point of view (you think too small.)「程式設計師的工作不是解決技術問題，解決技術問題只是為了解決商業的問題」。
一般的程式設計師在解決技術問題的時候，常常會忘了最初的目的；而更糟的是，無法產生任何有商業價值的東西。當接到客戶的需求的時候，會去字面上地死板解讀，做出一個無法使用的東西：他們沒有去考慮到實際使用的狀況、以及用戶的體驗。
而好的程式設計師應該要從用戶的角度，來看自己的程式。號怎麼更容易解決使用者的問題，在字面描述的背後還有哪些可能，可以讓這個功能對用戶來說更好用？ -
無法評斷任何程式工作的商業價值
You aren’t able to judge the business value of any programming task.許多技術能力很強的程式設計師沒辦法發惠他們的潛能，因為他們無法退後一步，由組織或商業的角度，來看自己的工作。好的程式設計師會自我管理、並以業務的考量、決定自己要怎麼分配時間。他們時常會想：「這是我現在最有價值去做的事嗎？」、「我應該花多久時間在這上面？」…等等。
而一般的程式設計師只會看著規格、盲目地去實作他，直到完成。工程團隊的最大的成本是開發時間，一般的程式設計師會花許多時間在細節和技術工作上、最後降低了商業價值。
這篇大致上就這樣了。基本上，不盡然算是翻譯，也夾雜了一些個人解讀。
可以發現，到了後面，其實已經不單純是程式上的技術問題了～而實際上，以現實世界來考量的話，的確這些都是得要考慮的。如果無法真正解決實際問題，而只能解決技術問題的話，基本上並不能算是一個夠好的開發者啊～
Heresy's Space 