做了6年有余的程序员，没有真正想过程序员该做什么的问题，作为项目管理者带了一年多的团队和项目之后，从项目管理和保证项目按计划进行的角度，开始促使我零零碎碎的思考一些有关问题。最开始只是发呆的时候在电脑上打开一个记事本随手写下些能想到的点点滴滴，点点滴滴逐渐汇集起来后我发现它们其实可以归纳成几个方面的问题，剪切调整一番就成了这篇文章的一个雏形，昨天原发公司内部自由论坛，今天略做修改在博客园抛砖，希望和同行们讨论。
作为程序员，我认为我自己该做到或者做好下面这些事：
一、具有基本的兴趣和强烈的责任心
人在江湖最痛苦的事莫过于身不由己，人在职场最痛苦的事莫过于对做的工作没有一点点兴趣。如果迫于生计和大学几年的既成教育事实，没有转行的勇气或目标，那还是应该培养一些对编程工作最起码的兴趣。
责任心也很重要。
每个程序员，包括高程和系分，在专业上都是从不会到会，从不熟悉到熟悉，一步一步走过来，技术可以学习，工作能力可以提升，兴趣和责任心有一个最基本的好处——可以缩短这个过程。
二、随时明确工作目标
关于工作目标，一个形象的比喻就是：一场不知道终点的比赛，不知该如何结束。不过，即使每个程序员都明白这个道理，但是真的就做到了吗？想想这几个问题：
1、项目组的工作目标是什么？
2、项目有几个阶段？每个阶段的目标是什么？
3、我的工作在项目中处于什么位置？
4、本月我的工作目标是什么？
5、本周我的工作目标是什么？
6、今天我的工作目标是什么？
坦白的说，在刚毕业的很长一段时间，上面的问题我一个都没有考虑过，从不考虑自己的工作在项目中是什么环节、什么阶段、重要程度。毕业半年时间，总是出差，我很长时间都认定我的工作目标就是出差，以至于现在回过头来印象最深刻的还是出差，不同的是现在我明白，当初的认识让我错过了一些重要的东西。
项目组由于各种原因一直加班很多，平时加，周末加。我发现，如果周末加班只是单纯的延续周五的工作，效率不高，而且大家情绪低落，如果简单的在加班开始前告诉每个人，今天加班，你做了什么达到什么目标就可以自行离开，不用管其他人和时间的时候，效率会有明显的提升。其实，我不过是明确了一下每个人当天的工作目标。
回到问题本身，能思考到上面列出的全部问题并得出肯定的结论，才能说是基本明确了工作目标。其实，要思考的问题还应该远不止这些，诸如：
今年我的工作目标是什么？
2年内我的工作目标是什么？
……
三、打好扎实的专业功底
练拳不练功，到老一场空。
练拳不练腿，到老冒失鬼。
练拳不练腰，终究艺不高。
回想大学的教育，无论什么专业，开始的第一年一定是大量的基础课程。无论是功夫片还是武侠小说，进入江湖各门各派，开始武学之路的一定还是基本功。甚至，就连追女朋友，也要先做足准备工作。
计算机发展到现在，集成度很高的编译开发环境和面向对象的编程语言，已经带领编程人员进入了一个傻瓜工具和编码蓝领的时代，这对应用和业务是好事，但专业门槛降低对程序员未必见得就是一件真正的好事。工作中因为一开始就大量脱离底层的东西导致程序员对程序和计算机本身的理解急剧下降，代码逻辑混乱、程序效率低下非常常见，一个把C#、java使用得非常熟练的人员，恐怕对声明变量和声明静态变量的异同不见得能说清子丑寅卯。
不会编程的人也能编程，这正是IT技术发展要的结果，但是不会编程的人也能编出让不会编程的人也能编程的工具吗？——所以，IT业，我相信始终还是需要一些会编程的人来编程。
四、保持正确的程序思维和良好的开发习惯
据说电影《黑客帝国》是拍给程序员看的，因为很多人看不懂里面的情节，而要看明白也很简单：不要把自己当人，你需要把自己看做一段程序。这是最娱乐的程序思维。
对于正确的程序思维，我个人观点是，从微观角度，不要想当然的认为你的代码理应是怎么样的结果，而要从你期望的结果来推算程序该是什么样的，这样的程序执行的时候不同的对象会开辟什么样的内存空间、它们的生命周期会经历哪些阶段，寄存器在某行代码运行时分配情况大致是什么样子，操作系统这时会做怎样的进程调度，垃圾回收什么时候将如何进行等等。
宏观的说，实现一个功能，如果只能找到一个方法和途径，一定会遇到重重障碍并且实现得苦不堪言，最后可能还需要别人来当消防队员救你出火海。如果能找到2个以上的方法和途径，即使遇到重重障碍仍然会游刃有余，不过，如果每次你都在2个以上的方法中优先选中最笨重的方法、最曲折的途径或是最后才找到正确的方案，程序思维可能仍然不够正确。
简单自测一下，对于一个布尔变量bFlag：
bool bFlag=true;
如果觉得：
if (bFlag==true)
...
和：
if (bFlag)
...
没有什么区别的话，说明程序思维还可以进一步提高。
再说开发习惯，这不是一朝一夕或是看一下编码规范就可以做到的，特别是在IDE越来越傻瓜化的情况下，如果没有正确的程序思维，要做到正确的习惯就已经有难度了，良好的开发习惯，不仅仅是如何给变量、函数、类命名，如何缩进，如何做好代码注释，如何捕捉和处理好每一个异常。记得以前看过一本书，《高质量C/C++》编程，不管是不是要写C/C++代码，这本书是一本理解程序的好书。
此外，不论开发中使用了VSS还是CVS或是其它版本控制工具，如果使用起来一直觉得别扭和不自在，或者时不时发现同一份代码没有签出的时候，在本机上和版本控制服务器上的内容并不一致，那仍然说明良好的开发习惯还可以进一大步培养。
五、站在用户和QA的角度编码
对于开发来说，程序员自己就是软件产品的第一个用户，很多时候，程序员自己很满意的东西用户不见得接受，但是自己都不满意的东西用户能完全接受并且很满意的情况一定是极端的个例。站在用户的角度编程，每完成一个功能或产品，你的第一反应会是，如果我是用户我会不会接受，还有没有问题，这种思维往往会让你有新的发现和收获；而不会是伸个懒腰对自己说，搞定，收工，然后暴走而去。这样的结果往往是留给测试人员一堆抓狂的bug。
站在QA的角度编程。你看到自己一天前的代码有什么感觉？一周后看有什么感觉？一个月之后再看有什么感觉？我的体会是，看自己写的代码，当时感觉最好，一天之后看感觉有可以改的地方，一周之后看发现有许多可以改的地方，一月之后再看就开始怀疑，这是我写的吗？今是而昨非，带着挑剔的眼光来检查代码，自己就可以发现问题。
六、积极的思考大胆的交流快速的学习高效的做事
第六点的这一行是一口气写出来的，写完想了想，把最后“正确的做事”改成了“高效的做事”。
这几点简单直白到不用做任何解释了，只说最后一个，修改的原因是，不能正确的做事，或是老找不到正确的做事方法，或是最后找到的方法才是正确的，我相信做出来的事很大程度都不会有效率可言，“高效的做事”，前提本身就包含着：快速找到事情的根本和正解，或者快速找到有效资源，然后，搞定它。
回过头来看上面主张的几点，并非是我已经把每点都已经做得非常好了，只是目前发现和遇到的项目组大多数问题都可以在这几点中找到原因和解决方法。广告说，大家好才是真的好。一点不假，如果每个程序员都能做好该做的几件事，最低程度，编码工作会变得轻松有趣得多。
相关阅读：
一个合格程序员该做的事情 你做好了吗？
相关文章
