1) Emotional thinking
If you start seeing the world in a different color, you're probably going to be a terrible programmer. Emotional thoughts or attitudes have a good chance of turning yourself into a monster. I believe that you can often see a lot of bad programs use the following statements:
-
My program can't have this problem.
-
Java is shit.
-
What I hate most is using UML for design.
-
The needs are always changing, and they are no longer available.
-
I can't stand these people, do they understand?
-
…… ……
These emotional thoughts and attitudes can not only make you a bad programmer, but even affect your future. Because emotionality is usually the devil, it will make you make wrong judgments and decisions, and the judgments and decisions of the wrong code rate directly determine your life.
2) Suspect others
Bad programs always say: "My code must be correct, I suspect a problem with the compiler", "I should be fine, why is the STL library so hard to use". I have seen some programmers use the STL class like this: map<char*, char*>. When he found that he could not get it out after putting it in the string, he thought it was a bug in the STL library, and then he wrote a map! My goodness!
Sometimes it's a bad habit to jump to conclusions too early. Everything has a reason. Only when you know the reason can you know whose problem it is. Generally speaking, it's always your own fault.
3) Too much focus on implementation, getting caught up in the details of the problem
Sometimes, when we are faced with a problem or a requirement, bad programmers will always find a solution or implementation right away, which is a very bad habit. Design patterns tell us that "prefer the interface to the implementation" is to tell us that it is more important to recognize the nature and characteristics of the problem than how to implement it.
-
For a customer's problem, the first thing that should be thought of is how to make the user work normally, how to restore the "bleeding" system, rather than put the user aside and analyze the cause and solution of the problem.
-
For solving a bug, reproducing the bug and understanding the intent of the original program are the first and most important things, rather than modifying the code immediately, otherwise more bugs will inevitably be introduced.
-
For a requirement, we need to understand the business background, use case and real intention behind the requirement, instead of discussing how to implement it. Only when you understand the real intentions of users, the ways and cases of actual use, can you really do design.
糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。
4) 使用并不熟悉的代码
糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V ，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？
5) 拼命工作而不是聪明的工作
对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。
6) 总是在等待、找借口以及抱怨
当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的team leader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting, leading instead of following.
7) 滋生办公室政治
有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。
8 ) 说得多做得少
糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子呢？就是吹啊吹啊。
另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提出可行的解决方案。
这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。
9) 顽固
当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一片质疑声中，他不得不采用了我最先告诉他的那个方法。
这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。
10) 写“聪明”的代码
他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码本应该简洁和易读，而他们喜欢在代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。
记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他某个单词的意思。呵呵。
你是一个糟糕的程序员吗？欢迎你分享你的经历。
原文链接：http://www.daimami.com/software-manage/288382.htm