“要是开发人员认为是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：有些公司允许员工分配一定份额的时间来自由支配，有多少人是愿意做那些“没人应份做的事情呢”？
相关链接：
