謙遜是什么，其實我很難給出文學上的解釋。從百科上釋義如下：
謙虛、不浮夸、低調、為人低調，不自滿。是一種自我的認識，良好的品德
我理解的謙遜就是 Modest，是對于身邊人或者個人習慣的一種尊重。為什么會談到這個問題，是因為最近在工作中遇到一些事情，讓我開始了自我反思。
場景一
我在和 Mike 結對編程時，我會提前看一下他的工作年限。從工作簡歷上看起來，此人工作了五六年，應該是個大神。于是我和他工作時傾向于被他帶著走，逐漸的缺少思考。因為我覺得他就是個大神，大神做得應該都是對的。
場景二
我在和 Allen 結對編程時，我注意到 Allen 其實只工作一年，看起來工作年限并沒有我時間長。這時候我在和她結對時，會傾向于表達自己的觀點，并且有些時候對于自己的觀點更是根深蒂固的堅持，很少去考慮她的想法。
場景三
我和 Mike 正在為一個按時間分類的問題犯愁，Mike 想了好一會兒，好像沒有好的結果。于是我自己在紙上畫了畫，似乎有點想法了。于是我問 Mike 我是不是可以試試。Mike 也友好的示意我試試。所以我一股腦兒把自己的想法用代碼實現出來了，用幾個測試用例跑了下，似乎結果還可以。于是 Mike 從簡單到難，用一個個測試了來覆蓋。最后我們再重構了下代碼。
場景四
我和 Allen 就多環境一個URL的配置問題，引起了討論。我堅持認為直接把整個的URL配置放在配置文件中就可以了。 Allen 認為把URL的域名部分放在配置文件中，具體的頁面放在代碼中，這樣別人更容易看懂。當然我在盡力告訴她我這樣是最好的，因為她那樣并沒有提高重用性等等。
似乎 Allen 也沒有被我說服，午飯時我又在思考這個問題。我想到了什么，下午開始工作時，我說我們先按照你的方法做吧，因為我覺得兩者差別不是太大。當然我不想為了一個問題請第三者仲裁，這樣沒有被采用方案的哪一方豈不是很尷尬。通過 Allen 的做法，在最后資源命名時，我們發現這種做法，最后命名時的尷尬揭露了這種做法的不合適。最后我們愉快的采用了另外一個方案。
反思
為什么我在開始合作時，會先看同事的簡歷？
這是個很錯誤的習慣，因為我潛意識里會把一個人的項目經驗作為一個人資質的評判。似乎這樣子能讓我“知已知彼，百戰不怠”。但是事實似乎并不是如此。
首先，做決策溝通過程中，我們應該充分考慮互相的想法。因為我們永遠不能說，經驗豐富的人說的話就一定是對的。特別是在寫代碼過程中，每個人看到的問題角度不一樣，所以每個人處理問題的手段也可能有差異。結對編程的目的就是幫助你們作出最好的決策。
其實，要敢于發聲。強者不必咄咄逼人，弱者也不必一言不發。你不說出口，沒人知道你的想法。同樣，你有不懂的問題，憋在心里也永遠沒有答案。所以你應該借助結對編程這個合作形式，把想問的，不懂得，想說的都及時的拋出來。才能給同伴一個反饋。
理解
Mike 遵循嚴格的 TDD
Mike 在寫代碼時，遵循很嚴格的 TDD，Java 里面的一個注解都需要用測試覆蓋。如果沒有測試覆蓋的情況下，你添加的任意一行代碼，他會立馬給你刪掉。也就是如果按照這種方式寫代碼，測試率百分百應該不是問題。
Mike 認為單元測試就應該測單元
和 Mike 同學結對過程中，發現他對單元測試的界定很嚴格。比如 A 類的職責是調用 API 獲取數據，調用 B 類處理一個復雜的分組處理，然后簡單的過濾進行返回。首先我們給 B 類這個分組器添加了嚴格的單元測試，確保其功能的正常。當我給 A 添加測試時， Mike 堅持將 B 類這個分組器給 Mock 掉，因為在給 A 類測試時，我們不希望受到 B 類的影響，所以即使 B 類只要一個簡單的方法，他也需要保證 A 的測試只是在測試 A。
對于以上兩種情況，你很難說這樣有什么問題。因為測試驅動開發或者單元測試不就是應該這樣嗎？所以當你嘗試去遵守時，卻發現比如確保每一行代碼都有測試，真是太難了。
這時候，首先我理解 Mike 這么做的初衷，他看起來是一個完美主義者，而且是一個資深的 TDD 捍衛者。我應該尊重他的這個習慣，因為這的確是個好習慣。問題在于我們在平時做事過程中，是不是要嚴格這樣遵守呢？其實這就要看項目里面的 “潛規則”。一般大家都會達成共識，比如怎樣的代碼塊需要嚴格測試的，什么樣的代碼只需要稍微測試下即可的。有了共識，其實按照大家的工作習慣來，就基本沒什么問題。
開放
除了上面具體的編程習慣，不知道你是不是遇到了下面這些問題：
- 產品代碼沒有單元測試的公司不是好公司
- 編寫 Java 還在使用 Eclipse 的
- 還在用 Windows 機器開發應用程序
- 竟然還在使用 SVN 進行代碼管理
- 只知道 CSDN，不知道 Github 的開發人員
- 公司內部網絡訪問不了 Google
- 手工部署，沒有使用過 Jenkins 等工具
- 傳統的瀑布流開發方式
- 每天有上司盯著你，公司有嚴格的 KPI
- 開發 Android 竟然還在使用 Eclipse，說好的 Android Studio呢？
多少次，我嘗試去了解一家公司時，會使用這些指標給一家公司定性。似乎只有和我現在的公司開發方式以及文化相似的公司才是好公司?，F在想來也有點過了。
畢竟，任何一家公司都有自己的做事方式，其實你很難評價這種方式是好還是不好。比如下面幾種：
- 扁平化組織一定比傳統的層級化組織有優勢？
- Mac 就一定比 Windows 高效？
- 所有的互聯網公司都應該使用 TDD？
- Eclipse 真的就是一坨渣，好程序就應該使用 Intellij？
其實上述問題，大家每個人都有每個人的看法。拿扁平化組織而言，我司難道就比組織層級化的華為優秀？
對于 TDD 而言，國內的創業公司節奏很快，當你的 APP 還在寫測試時，別人的產品也許早就上線了。等你花了三倍的時間把產品開發完，發現別人早就驗證這個市場不靠譜。然后你一堆代碼就爛在那里。
對于操作系統，Mac 和 Windows 各有優勢，相信每個人都有自己的偏好，并且每個人都會根據自己的實際財力情況，進行取舍。
當我們在噴 Eclipse 時，其實我自己當時也是用 Eclipse 來寫 Java 程序，來寫 Android 程序的。后來工作后，在新公司的要求下，才放棄 Eclipse。
謙遜
恰巧前段時間讀到了陳先生公眾號里面一篇文章，講的是一個年過半百的老者去面試的故事。文中老者在面試時表現的恭敬與認真的態度著實給我上了一課。因為我曾經也有個面試，那個意外的面試純粹是為了探探其他公司招人的要求，因為我根本沒有想到去那家公司。于是面試時表現的可漫不經心了。沒有簡歷，隨便的自我介紹，其實完全是一種無所謂的態度。
細思極恐，面試官看到我這個樣子該是多么的嫌棄。我竟不曾想到我這樣留給別人什么印象。雖然我沒有想過得到別人的認可，但是我應該給予每個人應有的尊重。應該時刻保持謙遜。這樣我才可能在花甲之年，成為文中那個受人尊敬的老者。
結語
當你遇到不同的人，不同的公司時，千萬不要見怪。其實一切的不適應都只是你不喜歡變化的爛借口。而且當你足夠牛逼時，你可以影響他人，當你有足夠的影響力的時候，你有能力改變一些事情。
