學習語言而不是框架
我喜歡PHP、Python和JavaScript，喜歡用他們做些東西。但我卻不是Symfony、Django、jQuery開發人員。
我認為這有很大的區別。一個人很有可能成為一名jQuery程式設計師而非JavaScript，也有可能成為Django程式設計師而不是Python。在實際應用中，的確存在許多有價值且非常實用的工具和框架，但如果我僅知道如何使用一個框架，我想表達的觀點是在工作上只使用合適的工具其實會給任務帶來一些限制，你可以檢視一下，看看你用的工具，看看你用的框架。以我的經驗來看，一些複雜的全棧（full-stack）框架並不是非常合適的工具，尤其在靈活性和效能方面都不是太好。
集中精力學習一門語言會讓程式設計師變的更加靈活。全棧式複雜框架可以幫助我快速的構建某個產品，但當我需要一個不屬於框架範圍內的解決方案時，它反而會變成一種傷害。我經常會採用“plug和pray”方法進行開發，當我發現某個庫或外掛可以滿足需求時，我就會把它們應用到產品裡。這樣可能會使應用程式快速推出，但在以後的道路上會留下很多障礙。
此外，學習全棧框架和學習新語言一樣複雜。它們通常都有複雜的體系結構和術語，並且有些部分並不適用於其他框架和工具上。當然框架也有許多好處，但前提是你必須要懂這門語言，然後才能理解其真正的工作原理，所以我寧願花時間學習更多關於語言本身的東西，並且把所學的技能應用到其他語言或者庫上。
構建小模組
有些小型的單元程式碼是很好很討程式設計師們喜歡的，因為越小越容易理解且很難把它弄的很糟，所以限制編寫冗長複雜的程式碼是非常重要的。
所以有目的的構建一些小模組——儘可能的接近需求目標。它們應該是獨立的塊，單純地解決某方面問題，但是把它們結合起來時，就可以解決許多大型的、複雜的問題。
像這些簡單的模組程式碼修復起bug來也會非常容易。因為這些單獨的塊通俗易懂，一看就會知道其用途。如果模組是自我包含的，那麼測試起來會更加簡單。
程式碼越少越好
套用Biggie Smalls的一句話：“程式碼越多，問題也就越多”。
誰都喜歡管理少的程式碼。估計大家都有過這樣的體會，當審查一個功能模組的程式碼時，如果程式碼很多很亂，第一印象肯定不好，相反，如果該模組程式碼簡潔明瞭，你會非常愉悅。更通俗點講就是程式碼越多，管理起來也就越困難：搜尋程式碼庫的時間會變長、檢視檔案導航也需要較長的時間、跟蹤執行也會變的困難等。
你是否發現，程式碼審查、還有你使用的工具，很大程度上都是用來減少程式碼量的。那些龐大的庫和長程式碼似乎會溢位人們的大腦緩衝區。當我在追蹤一段較長的原始碼或執行跳躍好幾個原始檔的功能時，我會感到很苦惱。這就是為什麼我會喜歡給語法進行著色的編輯器，並且保持一致的空格對我也非常有幫助。
除了喜歡管理較少的程式碼外，我還支援開發者們儘量簡化程式碼。程式設計師要為應用程式所使用的程式碼，不僅僅是自己編寫的部分負責——甚至是這些應用裡的每行程式碼。這也就意味著要替這些應用裡出現的bug或者安全漏洞負責。
你會在程式中使用自己不理解的程式碼嗎？這並不表示我從不使用他人的程式碼——坦白說，世上有許多優秀的程式設計師，但是在應用他人程式碼的時候，你必須理解程式碼，因為應用程式裡的每行程式碼都很重要。在編碼時千萬不要忘記思考，編寫最少程式碼的背後應該是多思考，這樣就不會給自己帶來不必要的麻煩。
編寫簡單、有用可讀的程式碼
編寫容易理解的程式碼，少編碼多思考，這樣完成一個功能就會很快，生產力就會得到提高。
當然，我也希望程式碼是可驗證的。並且我一直認為簡單、模組化的程式碼是更容易被測試。
程式碼應具備的另一特徵就是可讀。程式碼應簡潔明瞭，語義清楚。在編寫程式碼時，我會思考其他程式設計師在第一眼看到它的時候會花多長時間來理解。或者一兩個月後我自己能一目瞭然嗎？正如大家熟知的那句程式設計諺語：任何一個傻瓜都會寫出能夠讓機器理解的程式碼，只有好的程式設計師才能寫出人類可以理解的程式碼。當我試圖發現它們工作原理的時間越少，做的事情就會越多。
但是很少有人能堅持這些規則，如果我說是，那麼我肯定是在撒謊。有時候我也會很懶惰，甚至由於時間限制，我會編寫一些複雜的、難以理解的程式碼或者使用沒有審查的庫來實現某個功能。想要在短期內編寫簡單、清晰的程式碼會很困難——它需要更多的紀律和不斷的技術評估。特別是那種對時間敏感的專案，實行起來將會更難。
但是，當你花時間和精力去做的時候，你會發現功夫不負有心人——不僅僅對自己有幫助，還會給其他團隊成員帶來很多益處。