“要是开发人员认为是bug没说清楚呢，你打算跟他们争论清楚，还是去调试这个bug来发现真相？”

　　“当然是争论清楚……”

　　“呵呵，谁指派你去跟他们争论呢？”

　　“这个倒没有。”

　　“那又有谁指派你去调试这个bug呢？”

　　“这个当然没有了。”

　　“那两样事情没有人指派你，为什么你偏偏选择去争论呢？是不是这样做更容易呢？”

　　“哦，我懂了，一般人都是挑容易的做，所以你说选另一种做法比较难了。但是如果我去调试这个bug，结果又有什么不同呢？”

　　“调试一个bug，会了解许多系统设计的关键细节，组件之间沟通的协议，支持平台的特点，特别是了解不止一个组件，很多开发人员往往只了解自己负责的组件。这些首先增加了你的发言权，因为你懂得的比别人多；其次因为了解得更深入，你更容易改变测试步骤来探索容易重现bug的方法；后如果你能发现bug的根源，会在开发人员中建立威信。‘大毛发现的bug都是准确的，不需要怀疑。’你想得到这样的评价，还是为每个bug去跟别人吵？”

　　“嗯，后一句比较中听。”

　　“你得有点志气，写代码的人满街都是，深入了解某类系统的专家打灯笼都找不着。不管你是开发测试还是经理架构设计师，缺乏深度什么头衔都是白搭。”

　　“我明白了，那何为没人应份去做的事情呢？”

　　“共用工具、测量指标、推动新技术应用、分享知识、技术讲座、参与招聘……”领导一口气说了很多。

　　“都要去做？”

　　“没人逼你一个月之内都做完。两三年之内把刚才我说的事情都做过的大有人在。”（见作者注2）领导一字一句的说，“态度决定一切。”

　　作者注：软件业兰博式孤胆英雄的时代已经过去了，团队合作才是可持续成功的关键。个人如何脱颖而出？是一个顶十个，还是让一百个顶两百个？

　　作者注1：微软公司流传的员工潜力三大指标：

　　Do those you are supposed to do
　　Do those you are not supposed to do
　　Do those nobody is supposed to do

　　作者注2：有些公司允许员工分配一定份额的时间来自由支配，有多少人是愿意做那些“没人应份做的事情呢”？