剛進新公司沒多久，公司有個新項目要做。考慮到之前類似的產品在使用前後臺系統時代碼比較混亂，領導層決定上實時操作系統。巧了，我是這方面的專家。於是，軟件就由我來主導了。另外有個同事，年紀比較我小兩歲，也做過RTOS。順利成章，我們兩個成了搭檔，負責新項目軟件部分的開發。
我非常開心能有個搭檔一起開發，這樣我的工作量就減少了一些；我也知道同事經驗有效，並不期望他能分擔一半的工作量。然而相處不過幾天，我發現自己在這“軟件二人組”中，不能僅僅作爲核心隊員存在；我還必須擔負起一個導師的職責。
考慮到自己很少有機會正式地當別人的導師，我對於新角色也充滿了熱情。
熱情持續了兩天，我開始有些不耐煩了。因爲我不能相信同事居然能有這麼多問題爆發出來！“函數怎麼寫？”“流程圖怎麼畫？”“全局變量怎麼用纔不會混亂？”類似於這樣的問題，每天都有很多個。我心想，這個是問題嗎？不是就應該這樣的嗎？有什麼好想的。哎，這技術。。。。。。
但是過了幾天，我意識到，問題不在他。
他經驗稍有欠缺，冒出這麼多問題是再正常不過的了。而我作爲導師，我有責任給他講解，或者至少給他個方向讓他自己去查找答案，而不是一味指責他技術水平太差。
我做好了嗎？沒有。事實上，我非常想做好這件事；但是最終沒能如願。
原因何在？答案是，我的水平還不夠。
可能我自己寫軟件、設計架構都有自己的一套方法，寫出來後大家都不會覺得差勁。但是我沒辦法把它表述出來，我不能清晰地把這麼寫軟件的理由告訴同事。因爲我自己也沒有好好想過這些問題。我剛開始寫代碼的時候，就有人告訴我應該怎麼寫函數、怎麼用全局變量；很多書上也是這麼教我的，“關於C編程風格的十大指導原則”、“正確的函數書寫方式”。但是從來沒人解釋過這是爲什麼，我也沒有問過這個問題。時間久了，我把這些都當成理所當然的了：沒有理由可講，照這麼寫就對了。
然而最近這幾天自己開始承擔導師的職責後，才發現過去落下的這些功課還需要重新補起來。我需要深入地分析每種寫法的優劣，錯誤的寫法可能會造成什麼後果。如果我不能準確地理解編碼風格的意義，不能準確地向新人表述清楚，我又怎麼能讓人信服呢？
親愛的同事，你問了這麼多問題，不是你的錯；是我沒能做到“知其然，而知其所以然”。在這裏，我要對自己在工作上的不耐煩的態度向你表示歉意。你是對的，繼續保持這顆不懂就問的心吧。
我也將繼續修煉基本功，保證下次不再犯類似的錯誤；也保證下次帶新人的時候，保持更多的耐心。