編程語言各有不一樣,不過區別不大。但用語言的人區別就大了。選擇了一門語言你就選擇了一個羣落。html
– Sam Kaufman,自由職業者,iOS 開發者,10x management前端
若是你想快速創建原型(尤爲對於但願對產品進行迭代升級的創始人來講),那就用 Ruby 或者 Javascript程序員
– Erin Parker,Spitfire Athlete 創始人兼首席開發者web
偉大的開發者可以建構並開發應用。驚豔的開發者可以在關注業務的同時作這件事。業務端的人大都不懂編碼,可是確定可以理解特定功能背後的動機。數據庫
別人說什麼開發者就作什麼,沒有去理解爲何要這麼作,致使雙方均錯失了機會,這樣的事情太常見了。編程
– John Coggeshall,自由職業者,web 開發者,10x Management,PHP 核心貢獻者segmentfault
精通編程是一個崇高的職業目標。一旦實現了這個目標,別忘了考慮一下你本身。不要成爲任何公司的奴隸或者在毫無價值的東西上浪費你的時間。後端
— Greg Sadetsky, Python 及 Javascript 專家,10x Managemen;協同辦公空間 Abri.co 創始人服務器
要想定期完成,得在開始技術工做以前事先進行項目溝通(哪怕這並不是先決條件),由於其餘人的響應速度變幻無窮。app
– Andrew Wilcox ,web 應用開發者,Meteor 核心貢獻者,10x Management
早發佈,不斷髮布,邊說唱邊發佈。
– Max Nanis ,自由職業者,web 開發者,生物信息學專家,10x Management
不斷測試。好的測試包如保單和煤礦裏的金絲雀之結合。它能幫助你在生產週期中更早地找出錯誤,而錯誤越早發現越容易解決。
– Jeremy Green,自由職業者,web 開發者,專長 Ruby on Rails,10x Management
快速失敗。編碼(及生活)時我但願儘早知道什麼地方不能工做,而不是聽任無論讓它增殖擴散。全面放開,快速失敗,修補缺陷,不斷繼續。
– Stephanie Volftsun,Knotch 聯合創始人兼 CTO
爲全部代碼編寫自動測試!儘量踐行測試驅動的開發。
– Zoran Kacic-Alesic,Industrial Light & Magic 研發主管
許多項目深受多測試周期之苦。這會拖累項目,致使組織總體出現高級別的問題。
程序員應該專一於對本身的代碼進行單元測試及半迴歸測試。他們比其餘任何人更瞭解代碼庫,也知道本身會影響到哪些變動。有時此類變動會因爲 QA 測試範圍有限而缺失,所以致使生產環節出現重大問題。
– Sanjib Sahoo,tradeMONSTER CTO
要想在力所能及的狀況下儘快開發出完好陷代碼,永遠永遠也不要把寫測試放到後面。咱們更清楚這一點。要檢查一下測試的覆蓋率,確保 100% 無死角。
– Seth Purcell,Signpost 工程副總裁
要對時間和成本有一個合理的評估,而後把它加倍。若是你們都說「這應該很簡單,」那就作
– Ryan Waggoner ,自由職業者,web 及移動應用開發者,10x Management
改進軟件開發質量的最好方式就是去開發軟件。許多雄心勃勃的剛入門的工程師花了不少的業務時間去讀書,關於最新工具的、關於開放流程的,諸如此類的東西。
不少人都是這麼消磨本身的閒暇時間的,但這樣很容易就把你給耽擱了。別這樣,經過儘量用腦來強化大腦負責開發軟件的那部分。
–James Cropcho,General Assembly 的 Ruby on Rails 專家及講師
不斷探索。我見過的許多編碼者手上都有幾個在進行的業務項目。作業務項目迫使你要探索新技術而後學習建立應用的方方面面。你可能須要作前端的 HTML/CSS,後端的 API 集成,數據庫優化,作移動 app,還得設置本身的服務器。
– Andrew Waage,Retention Science CTO 及聯合創始人
結對編程很是必要。兩個程序員聯合開發同一個模塊能夠相互審查對方的代碼。開發團隊每週也要召開代碼審查會議,讓每個開發者給其餘人的代碼提供反饋意見,解釋如何更好地改進代碼。這可以造成一種協做文化,把開發者的自負拋開!
– Sanjib Sahoo
只有在問題和解決方案都出如今你面前時才進行重構—過早重構是時間上的巨大浪費。不要投入半年後可能被扔掉的任何東西的完善上。過早優化是罪惡之源。
–Seth Purcell
不要過早優化!我不斷看到工程師在用戶尚未到 1000 的時候一再對擴充到 100 萬的用戶規模擔憂。
– Mariya Yao,Xanadu Mobile 創始人兼創意總監,移動開發者及設計師
你寫的代碼機器會解析執行,可其餘人卻須要讀你的代碼,理解它,擺弄它。你必須明白,你的代碼會有將來的觀衆。代碼也是一種書寫形式的溝通。
– Tracy Chou,Pinterest 軟件工程師
聽起來很奇怪,可是你永遠都得替本身的將來着想。問問本身:若是你有健忘症的話,你還能不能理解本身寫過的代碼?
– Wai Ching Jessica Lam,Sugarbox 聯合創始人兼 CTO
通讀你的文檔。設計改動不少,有時候代碼更新的時候註釋不必定會跟進。保持文檔的更新,將來的人(包括你本身)理解起來就更容易。我說不清有多少次我看回本身代碼時總在想:「我到底在幹什麼?」只要我寫出了好的註釋,將來頭疼就少不少。
– Kitt Vanderwater,Google 軟件工程師
幫助他人是深層次的人類需求。想辦法用你的工做來改善人類,你就會有成功的把握。
– Greg Sadetsky
via @36kr