或许这样的标题，应该是由像Linus或Greg KH这样的大师级的高手才有资格写的吧。但是作为我来说，也许我更想把这个标题作为一个疑问句来使用，整理一下自己的认识，用来勉励自己，和大家一起努力实现这个目标。认识肤浅的地方，还请大家见谅。
何谓优秀的驱动开发工程师
首先要定义，我所认为的一个优秀的驱动开发工程师，应该具备什么样的能力，这里列一下按照从易到难的顺序，个人认为应该会有几个方面的要求吧：
- 能够独立完成驱动的功能开发任务
- 能够分析和优化驱动的性能,针对特定硬件扬长避短
- 能够充分了解模块相关软硬件能力、发展方向，辅助应用工程师最大化利用硬件能力
- 能够辅助硬件工程师规划硬件设计，预防问题，谋求功能模块的最佳方案
- 能够协助定义系统架构，合理规划软硬件，谋求产品实现的最佳方案
作为一个驱动工程师，很多时候不是完全从头开发一个完整的子系统，而是针对特定硬件和平台移植驱动，增加功能，解决Bug等等，如果从这方面外在的表现来看：
解决问题的境界，大概会有这么几个阶段：
- 不知道哪里存在BUG
- 不知道如何解决BUG
- 知道如何解决BUG
- 知道如何发现BUG
- 知道如何规划BUG
知道如何发现BUG（而不是撞上BUG）其实并不简单，需要你对系统有足够的了解，能够察觉可能出问题的地方。 而规划Bug更难，需要你能对问题的轻重缓急做出准确的判断。没有的完美的世界，只有适当的取舍，规避和预防。
而从解决问题过程的角度来看，我认可以分为几个阶段：
- BUG发生 -> 大量跟踪调试代码 -> 终于发现并解决BUG
- BUG发生 -> 理论推测可能原因 -> 迅速定位并解决BUG
- 阅读代码 -> 预测可能出现的BUG -> 证实并解决BUG
号称能光凭瞄一遍代码就找到问题的高手，我想我是没希望了。
应该具备怎样的素质
那么要达到上诉最佳境界，需要具备和发展哪些素质和能力呢？
足够的硬件知识
能看简单的原理图，能够分析硬件异常的可能原因，能够使用常见的硬件调试工具，我想这是做为优秀的驱动工程师，区别与其它软件工程师，所不可避免、必须具备的专业素质。当然取决于你具体从事的工作，对这方面的要求不尽相同。
对于驱动开发者来说，不了解所开发驱动外设的硬件原理和相关背景知识，也许很多时候，也能够完成一些移植，修补的工作任务，但这就好比无源之水，无根之木，我相信是很难走远的。
多多益善的操作系统知识
做驱动开发，特别是纯粹的外设的驱动移植工作，刚开始的时候，也许你并不需要了解很多操作系统本身的知识（像内存管理，进程调度，锁，各种内核子系统的原理框架等等），也能顺利完成手头的一些工作。
但是，如果一但需要优化驱动，需要完善软件框架，或者是遇上疑难问题需要跟踪解决，对操作系统，内核本身的了解，就体现出它的价值了。
对于Linux内核驱动开发者，尤其如此，首先，代码是完全开源的，你有条件去了解背后的运行机制，其次，Linux内核和各个组成子系统总是在迅速的进化发展中，不进则退，你也有必要跟上时代发展的脚步。
强烈的好奇心，持续的热情
如果驱动开发不仅仅是你的爱好，更是你养家糊口的途径，我想，很多时候，你大概不会有机会专注于一两个你最有经验的模块的开发和维护。随着能力的成长，势必会要求你接触和掌握越来越多的各式各样的驱动模块的开发。
对于这件事，包括我自己，有时候大概都会有如下几种反应：
哇，原来的工作做太久了，太乏味了，很高兴能做不同的工作。
啊？又要做别的模块啊？我手头的工作已经太多了！
这个模块没意思，我不想做。
相信多数有志青年们都是第一种表现了 8 ）不过，有些时候，我发觉，很多人的这种热情其实并不持久，一个新的模块没做多久，就再次厌倦了，是已经炉火纯青了么，未必，或许只是修改了几个BUG以后不甚其烦。很多时候，我面试前来求职的工程师时，发现简历上这个也做过，那个也做过，但是一但问到解决了什么问题，所做过的驱动，框架、流程、原理之类的问题的时候，就一问三不知了。
我觉得如果自己的目标是优秀，那么最起码的标准应该是对具体驱动模块相关的子系统的整体工作流程，框架，具备足够的好奇心，乐于去了解和学习，而不仅仅是为了完成任务而工作，否则的话，很难积累下扎实的经验和技术。
清晰的逻辑思维能力
这一点，也许是个软件开发人员都应该具备吧，不过，做为驱动开发工程师来说，有时候，大多数情况下，工作的硬件环境并不是完美的，遇到问题需要分析判断错误的原因是硬件问题还是驱动Bug，这时候，清晰的逻辑思维能力尤其重要。
良好的工作习惯
大多数人都不是天才，要成为优秀的开发工程师，一需要持续努力，二需要时间积累经验，而这过程中，很重要的一点，就是要有良好的工作习惯。譬如，注意设计文档的维护，对工作中遇到的问题的记录，过往经验的及时记录，适当的软件开发流程等等。文档工作，可能很多人很不愿意去做，它的确很花费时间。不过，唉。。。老啦，好记性不如烂笔头啊 8 ）。 当然，其实设计文档更多的是为你提供思考的机会，而过往经验的总结，也可以起到和大家交流技术，共同进步的目的。
英语
这个也是必须的啦，没有办法，邮件列表，技术文档，社区，精通英语肯定是很大的优势，做开源项目尤其如此。阅读各种Spec标准文档之类的速度还是很重要的。阅读无障碍是一回事，能和母语一样一目十行，那才爽呀，唉，人生苦短，效率啊！光读文档，就不知道要比老外多花多少时间。。。。