从业十年，看到过许多优秀的程序员，也见过不少平庸之辈，更有不少只能转做其它。原因我想也许他们一开始对自己的要求就不高，更重要的也可能是他们没有抓住程序的本质，没有搞清楚如何才能把事情做好。首先想把每个程序都做到最好这种信念是先决条件，人首先要有志向，只要想做好才有可能做好，下文所有的内容都是给这类人写的，如果只想混口饭吃，或者以后想做市场等其它方面的人就不用想这些事了。以下是我认为比较重要的几个原则，不当之处共同谈讨。
1，思路要简单，这样写出来的代码就会比较简单易懂。在这点上我比较占优势，当年一直没有学好过数学，所以太复杂的问题想不懂，因而一直采取比较简单的方法，容易的思路。君不见有人写代码非要想的很多，本来很简单的一个道理：两点之间直线距离最短，他偏要来个九曲十八弯。这种代码时间长了或者转给别人就不好维护。要做到也很容易，写代码之间大概想一下思路，一开始不清楚也没有关系，写的过程中发现代码有点拗口或者自己也不大明白时一定要停下来想一想这个思路本身是否有问题。当然，在这里我不是在宣扬数学无用论，如果您的数学功力不错，那就恭喜了，关键问题是要把问题尽量简单化。
2，要做思想上的勤劳者，动手时的懒人。代码尽量少，这至少有一个好处：少打一些字，当然附加作用是看的人也容易理解。写好代码之后多想想这些东西是否还可以简化，力争将代码做到最少，代码少有两层意思：源代码量小及机器码也少，所以我们对每句源代码可能产生的机器也要有所了解。
3，代码量要小的另一重要环节是尽量不要调用系统API，复杂操作系统的API一般都是在一个功能提供者进程中实现的，其它调用者调用这些API时需要在提供运者进程中启动一个线程来完成这些调用，如此造成多执行很多代码。而且一次API调用到底会引起系统做什么事情也不尽相同，有些调用可能会引起很多硬件操作，就会花比较多的时间。
4，每个程序都应该很好的模块化，分层定位准确。例如就驱动来讲，驱动功能最简单的描述就是向上（操作系统）提供接口供调用，向下操作硬件实现自己的功能。在这过程中需要经过一些调用，我们需要将这些代码模块化，使得最终操作硬件的代码在一起，不要很多函数都在操作同一硬件，实现差不多的功能，这种函数就可以归结为一个，通过不同的对数来区别各个功能，实现自己的目的，这样出现问题以后就比较好查。
5，要勤动手，勤思考。不记得谁说的“实践是检验真理的唯一标准”，只记得有这么一说。这应该是放之四海皆准的道理，写程序也一样。有的人看了很多书，说起来像专家，可让他调一个问题往往找不着北。
6，代码要整洁，至少每一个源文件的编译风格要一致，这就不用多说了，谁也不想看乱七八糟的程序。
遵从以上原则，再加以下方法，相信我们一定可以做的更好：
1, 勤学习，适当拓宽知识面。这里适当非常重要。就是说自己的知识面的拓宽速度要合适，要有个度。这个度怎么把握呢？每个做过的模块力争弄透彻以后再接触下一个模块。而且，每个模块的上下级模块都应该搞清楚，至少是其功能作用等都要清楚，这样慢慢地就会变成某个领域的专家。如果接触了很多模块，每个地方都是一知半解，那最后就变成了什么都会，就等于什么也不会。
2，多做笔记。记录每一个问题的解决过程，很遗憾我一直没有养成这个好习惯，如果你能，那就恭喜你了！ 但有一点很重要，我希望你做的笔记一次都不看。为什么这么说？我希望这些东西在记录到笔记的同时也印在了脑子里，如此一来我们的知识面才能真正的拓宽，才能做到所有知识融会贯通。想想如果每次遇到一个难题后总要到笔记本上去查以前有没有遇到过，那效率在哪啊？最根本的一点，这种东西进不了脑子，我们永远都是一个记录者，而且面试时总不能带一个笔记本去吧？所以，这是我这篇文章的核心:希望大家做笔记，但从来不需要看，注意是从来不需要看。
3，要有限地相信科学。这里有两层意思，首先我们要相信科学，最基本的东西不要怀疑，例如我们不用怀疑1＋1＝2这个规律，这是最基本的，我们不要怀疑OS的调度器，如果它有问题，大家早都不能玩了；其次是要有限地相信，在某些情况下得想想这些东西是否是对的，例如正常情况下我们不应该怀疑Sleep(10)这样一个简单的语句的正确性，但如果怀疑可以测量一下，那你也许会有所发现，因为如果厂家的BSP实现的有问题，可能它就是不准的。
4，解决问题从易到难。首先，如果我们拿到一个项目而我们根本没有太多头绪，不要紧。将这个大难题目切成块，一点一点的吃掉；其次遇到一个大BUG无从下手时，先想想我们是否犯了最简单的错误，先试容易的方法，花时间少的方法，一个个的排除，这样才不容易进死胡同。
....