对于软件工程师来说，工作也许意味着许多东西 -- 稳定的收入、做自己感兴趣的项目、找一份更好工作的跳板，或者你只是喜欢与其他程序员共事。但说到“效率”，强调的是在一定时间内按质完成项目的能力。
理解你的需求
成为一个有效率的程序员首先要知道如何正确的支配自己的时间。对时间最大的浪费莫过于去做那些没有用处或者永远不会上线的项目。而导致这种结果的根源往往是对需求理解的偏差。
要最大程度避免这种情况的发生，最好的办法是快速建模，尽可能让演示系统早点出来。对于客户来说，只有看得到摸得着的产品摆在面前，他们才会有兴趣去试用观察，才会在实际的操作中发现供需双方在需求理解上的偏差。否则即使你写上几百页的需求分析文档也只能是自己的一面之词，客户可没耐心去检查这些文档写的是否准确。
另一方面，你应该让每一个阶段的开发成果都能够尽早的提交给客户。让他们以完全不考虑操作合理性和业务逻辑性的傻瓜级操作来发现程序员编程中的固有思维局限。尤其必须让QA尽早的介入到项目开发中来。如果能够每天提交一份测试版本给QA自然是最理想的了，但大多数项目开发做不到这样的粒度，那么就争取每周提交一份可测试版本。重要的是应该让QA和开发能够保持交错并行状态。只有这样，才能让QA尽早发现bug，降低每个bug的修复成本，同时缩减独立测试周期的跨度。
程序员往往不愿意把半成品代码交付给测试人员，相反他们更喜欢在所有代码都完工，达到自己满意的程度之后再让别人来测试。因为在这之前的代码往往存在很多程序员自己知道需要修改（或者故意留待后续补全）的流程缺失和Bug，测试人员并不知道哪些是真正的Bug，哪些只是临时性的运行错误，每次都会一股脑儿作为Bug反馈给程序员。这往往让程序员们心烦。同时测试人员有时候也不喜欢测试这种很多分支都走不通的中间版本。
但不管喜不喜欢，测试并发现问题是测试人员的工作；程序员则应该认识到，Bug反馈得越早就越是件好事情。QA和开发之间的关系往往很敌对，可实际上双方的目标是一致的。“忠言逆耳”古训有之，对于程序员来说就应该“有则改之，无则加勉”。总好过项目完成之后才发现一堆的问题，到那时候再要做修改，基本上都会牵一发而动全身，痛苦的还是程序员自己。
保持真实性
尽可能让你的系统运行在最接近真实环境配置下面，使用有实际意义的数据和真实的编译版本，并经常性进行模块整合。如果你的测试环境使用的数据都是些胡乱添加的东西，那么将来和测试数据大相径庭的真实数据这块大冰山早晚会撞沉你的程序。另一方面如果你只在开发环境来编译运行测试，会发现正式发布之后有各种各样莫名其妙的问题产生，到最后原来都是因为环境配置与开发环境有些不起眼的差异所导致。把所有模块整合进行编译联调，看上去应该是最后作的一项附加工作，但实际上这是一项需要在开发过程中经常性进行的工作。只有这样QA才能有最完整的东西拿来测试，得到更多的Bug反馈，同时降低模块整合的难度。
理解你的代码
书写规范的代码，并保持代码的整洁。Coding是一门艺术。正如写作一样，同样的文字在文豪的笔下就能够熠熠生辉，读起来赏心悦目；在普通人的笔下大概就只是词能达意的效果了；在某些人的笔下或许就需要研究半天才能猜出个大概来。当然不可能人人都成为艺术家，但至少你可以学会欣赏艺术、学习艺术。书写漂亮的代码是对自己工作的尊重，也是对其他程序员的尊重。如果你的代码中间充斥着大段过时的注释、可读性差的变量/函数，怎么去要求别人或者自己以后能够理解它们？
最优编程
把你的时间花在代码的功能上, 而不是去把现有的代码改得对自己胃口（尤其对于那些copy/paste过来的代码）；要找到系统的瓶颈进行优化，而不是对那些无益于系统整体性能提高的地方做无用功。
管理好你自己
也许有人会说计划和进度控制是PM的事情，但一个好的程序员应该比PM更了解自己目前工作的进度。不论上头给的进度计划是否合理，你都应该有自己的原则和概念，清楚知道每天该做什么怎么去做。
持续教育
只有不断的学习、实践、犯错误，你才会真正有所提高。在我看来，对于程序员来说最好的老师不在学校，而在书本、网络、社区。学会自我学习才能保持与时俱进。
R-E-S-P-E-C-T
互相尊重是一切的基础。
