程序员在编程的时候难免会发生这样那样的错误，对此，我们除了从错误中吸取教训，还可以从前辈得到的经验，避开这些错误。
一、不提升非技术技能
我们认为非技术技能是项目成功的主要因素。这些非技术技能也可以称之为“软技能”，总体上来说，它已经被公司证明为能够驾驭企业和客户之间的长期商业关系，因此也能决定公司的成长发展路径。一些关键的软技能指标包括：
a.纪律——这是最重要的特征之一，缺乏纪律，最终会让这个开发团队在开发能力上“缺乏自信”。解决这一问题的矫正方法就是每天制定详细的to-do清单：兑现你的承诺、完成你开始做的事情、避免多重任务，因为这些往往会让你的生活产生混乱。
b.顾客的声音——不把客户置于决策的核心地位只会跟你们业务的原始目的相冲突。如果客户不高兴，即使你拥有世界上一流的专业知识和资源也不会起什么作用。保持符合客户期望的解决方案、及时交付才能体现出项目的真正价值。
c.沟通——尤其是当客户和供应商并不在同一地点的时候，明确而及时的沟通是填补服务空白的极好措施。主要集中在这三个方面你就能克服问题——进行主题讨论、清晰表达、干脆简洁。
d.了解需求——在整个开发生命周期过程中，决定成功和失败的之间的一个至关重要的区别将会给人留下深刻的印象。通过最初的头脑风暴法了解问题状态，以及后续的交货程序，，这其中都要和客户完美配合。只有这样，客户才会赞赏你的工作，给你好评。
二、对编码不理智
古人云：善泅者溺，善骑者堕。但估计绝大多数 的程序员都认为自己的编程技术绝对的牛。而同样真实的是，每一个代码，让不同的程序员去实现的话都会不可避免地发现它所存在的缺陷。所以说，只有通过在一 个项目上的合作，程序员之间必然有的摩擦才能证明谁是最好的。健康的竞争是好事，但它不应该成为一个本来可以成功的项目的负担。
另一个创意阻碍是无法将预定义的模板使用在对你有利的开发项目里。几乎所有的编程语言有一个很好的在线 /内置的代码片段存储库，可以修补代码，防止重新编程。然而，如果因为不理解需求或缺乏接触各种可用库/模板的话，这就意味着程序员最终会无意间将一开始 就创建的代码付之东流。这不仅增加了开发时间，也提高了总体成本。另外一点就是，发布了的代码已经经过了质量检测，所以只有将它用作模板才能发挥它更大的 价值。
三、不一定什么都要被理解
如果你是刚调到这个团队来的编程人员，对于手头的工作并不是很熟悉，那该怎么办?肯定是先看一些前任留下来的工作计划，要是他写的详细倒也没什么，如果写的不详细，估计会让你更加的挠头。
因此，推己及人，在需要交代的工作上，最好是把任务写的尽可能的详细。这么做也是非常现实的原因：能够把编程问题解决掉，最好是保证使用解释性的语言和英语发音来表示变量。一些基本的指针可以让你的程序更容易被理解，包括：
a.把所有参数、引用、方法和变量名称尽可能接近英语表达。保持文件名简短但有助于理解的功能。
b.使用++包装文字是一个好办法，能让代码和注释更加清晰。
c.将编写的程序保持在一个连续的流程上，尤其是在使用OOP基础上的语言：C#、C 和 C++。
d.对于不同的代码块使用不同的描述名称。
四、不使用经过验证的工具和技术
程序员的好坏从他使用的编程工具和调试工具上就能看出。在异常情况的跟踪上，下面就是程序员经常会出现的常见错误。
对一些可能会对其它代码有影响的常见案例进行捕捉，处理这些比较常见的异常情况(而不是特殊的异常)意味着无意中除除掉了会抑制整个程序的残留部分，因此并不会影响他人的代码。
也许程序员可能带有恶意的意图来捕捉所有的异常情况，但即使是捕捉到了也不实施采取措施，这就是常说的“虚假安全阀”，这种异常处理手段是对整个软件的稳定和安全的一种妥协方式。
五、较差的控制版本
在任何涉及多个团队的项目里，当谈到版本控制的时候不去介绍使用最佳实践都是一个十足的罪过。版本控制的目的是确保由一个人执行的编辑或修订不去影响另一个人的工作。
版本控制不仅有助于将由两个或两个以上的程序员的编辑工作合并到一起，还有助于跟踪程序的更改历史。所以说，任何开发团队都应该做一些好的改进措施以确保强大的版本控制，这其中就包括：
为每个解决方案创建一个“逻辑单元”
给解决方案制定描述性的名称
确保你所使用的都是最先进的文件
频繁的向团队分享你所做的各种改变
六、拥有最新信息的个人代表不了团队
生活若剥去了理想梦想幻想，那生命便只是一堆空架子
