自己会与能把别人教会是两种不同境界

刚进新公司没多久，公司有个新项目要做。考虑到之前类似的产品在使用前后台系统时代码比较混乱，领导层决定上实时操作系统。巧了，我是这方面的专家。于是，软件就由我来主导了。另外有个同事，年纪比较我小两岁，也做过RTOS。顺利成章，我们两个成了搭档，负责新项目软件部分的开发。

我非常开心能有个搭档一起开发，这样我的工作量就减少了一些；我也知道同事经验有效，并不期望他能分担一半的工作量。然而相处不过几天，我发现自己在这“软件二人组”中，不能仅仅作为核心队员存在；我还必须担负起一个导师的职责。

考虑到自己很少有机会正式地当别人的导师，我对于新角色也充满了热情。

热情持续了两天，我开始有些不耐烦了。因为我不能相信同事居然能有这么多问题爆发出来！“函数怎么写？”“流程图怎么画？”“全局变量怎么用才不会混乱？”类似于这样的问题，每天都有很多个。我心想，这个是问题吗？不是就应该这样的吗？有什么好想的。哎，这技术。。。。。。

但是过了几天，我意识到，问题不在他。

他经验稍有欠缺，冒出这么多问题是再正常不过的了。而我作为导师，我有责任给他讲解，或者至少给他个方向让他自己去查找答案，而不是一味指责他技术水平太差。

我做好了吗？没有。事实上，我非常想做好这件事；但是最终没能如愿。

原因何在？答案是，我的水平还不够。

可能我自己写软件、设计架构都有自己的一套方法，写出来后大家都不会觉得差劲。但是我没办法把它表述出来，我不能清晰地把这么写软件的理由告诉同事。因为我自己也没有好好想过这些问题。我刚开始写代码的时候，就有人告诉我应该怎么写函数、怎么用全局变量；很多书上也是这么教我的，“关于C编程风格的十大指导原则”、“正确的函数书写方式”。但是从来没人解释过这是为什么，我也没有问过这个问题。时间久了，我把这些都当成理所当然的了：没有理由可讲，照这么写就对了。

然而最近这几天自己开始承担导师的职责后，才发现过去落下的这些功课还需要重新补起来。我需要深入地分析每种写法的优劣，错误的写法可能会造成什么后果。如果我不能准确地理解编码风格的意义，不能准确地向新人表述清楚，我又怎么能让人信服呢？

亲爱的同事，你问了这么多问题，不是你的错；是我没能做到“知其然，而知其所以然”。在这里，我要对自己在工作上的不耐烦的态度向你表示歉意。你是对的，继续保持这颗不懂就问的心吧。

我也将继续修炼基本功，保证下次不再犯类似的错误；也保证下次带新人的时候，保持更多的耐心。