在寫這篇文章時，我是滿懷感激與賞識之情的。 來誇一個人，講一個道理，寫給大家，也是寫給自己。 來自讀者的反饋 先說說事情的經過。 新書出版之後，昨天第一次看到（抱歉看到的比較晚）讀者的反饋。所謂反饋就是在書中留了GitHub的地址，如果書中有錯誤的地方，讀者可以通過該鏈接提交Issues（問題），來 ...
在寫這篇文章時，我是滿懷感激與賞識之情的。
來誇一個人，講一個道理，寫給大家，也是寫給自己。
來自讀者的反饋
先說說事情的經過。
新書出版之後，昨天第一次看到（抱歉看到的比較晚）讀者的反饋。所謂反饋就是在書中留了GitHub的地址，如果書中有錯誤的地方，讀者可以通過該鏈接提交Issues（問題），來進行反饋。
如果能夠收到讀者的反饋意味著：讀者認真讀了書，發現了問題，並熱衷於幫忙，找到了反饋鏈接，再把問題描述出來……
有這樣一位讀者的出現，對作者來說是最欣慰的事了：我的書幫到了他，而他也願意來互動，一起改進。
因此，真的是滿懷感激與欣慰，自己所做的努力已經值了！
對讀者的欣賞
感激很正常，但為什麼會欣賞呢，又為什麼會誇贊他優秀呢？
不論你是否是開發人員，看了這位讀者的反饋，或許你也會萌生欣賞之意。
反饋的三個問題的標題如下：
標題明確，把頁碼、章節、錯誤原因清晰概括出來，看一眼標題你便知道他要表達什麼。
回想一下，我們在工作中寫郵件的第一個要求不就是“標題明確”嗎？又有多少人能夠做到像上圖這樣？
再來看看其中的兩個問題的細節描述：
上面的截圖你看到什麼了？他讀的很仔細，發現了問題，把問題圈出來，寫代碼驗證，然後又反饋回來了，附上圖和自己寫的代碼。要不要太贊！
上面的問題，因為在書中描述方法名時首字母大寫了，這位讀者專門將方法用熒游標註出來，提醒“Java方法首字母應該是小寫”，我們都知道這是Java代碼編寫的基本規範。
細緻、遵守規範、勤於動手實踐、樂意反饋……各位領導，如果你們團隊中有這樣的人，你是不是會另眼相看？如果你看到這樣的人是不是想挖到自己的團隊來？
一個故事
也是昨天，聽羅胖講了《城的燈》中的一個故事：
“軍隊里有一個參謀，苦出身，就是一路向上奮鬥那麼個人。有一次，軍隊的首長晚上開會，突然一下燈滅了，停電了。這個參謀坐在會議室的後排，他站起身，從兜里掏出了一截兒蠟燭，啪，點著，把蠟燭按在了桌上，然後轉身出去。
“那個時候其實不是停電，就是保險絲燒了，換上保險絲，幾分鐘之後會議室燈光大亮。要知道這個會議室從來沒有停過電，沒有發生過保險絲被燒了的事。
你知道這意味著什麼嗎？意味著這個參謀到這個職位上幾年來，他兜里一直備著這一截蠟燭，從來沒有被用到過，今天被用到了。那麼你想，在座的所有首長對他有好印象，覺得這個小伙子靠譜，然後提拔他、重用他，這個判斷在那一瞬間就可以做出。”
老喻的一個問答
同樣也是昨天，看到老喻文章中的一個問答，就是那個運營“孤獨大腦”的老喻。
有一個問答是這樣的：
讀者問：請問老喻，一匹千里馬能遇到伯樂的概率有多大？謝謝。
老喻：接近於100%。這年頭是伯樂常有而千里馬罕見，你看投資公司和好的創業公司的比例。
想到了什麼
三件事，同一個底層道理，發生在同一天，衝擊力可想而知。
是不是很多人都曾有“懷才不遇”的感覺？
如果感覺自己是千里馬，而卻遲遲未遇到伯樂，難道是伯樂都瞎了嗎？不，非常非常大的可能只是因為這匹馬的腳力還不夠。而現實就是這麼殘酷。
如果真的是千里馬，就像第一位讀者那樣，我這麼眼拙的人都能看得出他是如此的優秀，何況伯樂乎？
昨天的我，思想上發生了很大的扭轉：此情情景，唯有俯下身子，努力提升自己。
與君共勉。
