10 Things That Make You a Bad Programmer

This site has previously published "Ten Habits of Excellent Programmers" and "Basic Skills Programmers Need to Have", which are what we need to learn and cultivate. Here, we mainly discuss ten characteristics of bad PHP programmers, mainly for us to avoid and be careful about.

1) Emotional Thinking

If you start to see the world through different colored eyes, then you may become a terrible programmer. Emotional thinking or attitude may turn you into a monster. I believe you can often see many very bad programs using the following statements:

My program cannot have this problem.

Java is shit.

What I hate most is using UML for design.

Why are the needs always changing? There is nothing we can do.

I can’t stand these people, do they understand?

… …

These emotional thoughts and attitudes can not only make you a very bad programmer, but can even affect your future. Because emotions are usually the devil, causing you to make wrong judgments and decisions. Wrong judgments and decisions directly determine your life.

2) Doubt others

Bad programs always say: "My code must be correct, I suspect there is something wrong with the compiler", "I should have no problem, why is the STL library so difficult to use?" I once saw a programmer use the STL class like this: map. When he found that he could not get out the string after putting it in like this, he thought it was a bug in the STL library, so he wrote a map himself. ! OMG!

Sometimes, jumping to conclusions prematurely is a very bad habit. Everything has its reasons. Only by knowing the reasons can you know whose problem it is. Generally speaking, it's always your own fault.

3) Pay too much attention to implementation and get bogged down in the details of the problem

Sometimes, when we face a problem or a requirement, bad programmers will always immediately find a solution or implementation. This is a Very bad habit. Design patterns tell us that "prefer interfaces, not implementations" means that it is more important to recognize the nature and characteristics of the problem than how to implement it.

For a customer problem, the first thing that should be thought of is how to let the user work normally and restore the "bleeding" system, instead of putting the user aside to analyze the cause and solution of the problem.

For solving a bug, reproducing the bug and understanding the intention of the original program are the first 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 true intention behind the requirement, rather than discussing how to implement it. Only by understanding the user's true intention and realizing the use can you truly design.

Bad programs always tend to get bogged down in details, arguing about how to implement it, the root cause of the problem, while ignoring more important things. Only when you understand the entire map can you know how to go.

4) Using unfamiliar code

A bad programmer’s best friend is Ctrl-C and Ctrl-V. Sometimes, they start using the code without knowing exactly what it means. There is evidence that, The vast majority of bugs are caused by copying and pasting. Because code can only work normally in a specific environment. If the context of the code changes, it is very likely that the code will produce a lot of behaviors you don't know about. When you can't even control the code, you still What good programs can be programmed?

5) Working hard instead of working smart

For bad programmers, we can always see them desperately fixing their bugs, always spending a lot of time and completing a certain task repeatedly. A good program may spend double the time to prepare an effective development environment and tools, and double or even 10 times the time to avoid some errors during development. Good programmers will always use all tools or means to make their work more efficient, and always strive to make as few mistakes as possible during development. The cost of getting it wrong later on will be huge, and the pressure to correct it then will be huge. Therefore, poor programs usually put themselves into a vicious cycle. They always look tired and hard, so they have no time to improve. The less time they have to improve, the more problems there are. So, working your butt off may sometimes indicate that you are not a good programmer.

6) Always waiting, making excuses and complaining

When the needs are unclear and the environment is not very satisfactory, they are always waiting for others to improve. When problems arise, I always make excuses or complain that this is not good or that is not good, so of course I am not doing a good job. Bad programmers always hope that their environment is the best, with clear needs, a very good development environment, enough time, good QA, and a strong team leader who is considerate. Your own manager, with enough training, good discussions, and strong support from others... This is an attitude of "when food comes, open your mouth, and when clothes come, you stretch out your hands". The world is not perfect, and a team needs everything. People have to struggle. Moreover, if everything becomes perfect, then what is your value? driving instead of waiting, leading instead of following.

7) Breeds office politics

There is a saying that "ugly women tend to make mischief", which means that if a person does not have real abilities, then he will definitely make mischief in other areas. article. The same is true for bad programmers. If they can't program well and can't compare with others, they will usually rely on blaming others, shirk responsibility, or exclude capable people, and other abnormal means to protect themselves. So, poor procedures are often accompanied by office politics.

8) Talk more and do less

Bad programmers always feel that they know everything. They do not feel that their understanding and knowledge are limited. This is what is called rhetoric, yes, what can a programmer who can't do anything well do to get by? Just blow and blow.

Another way of showing it is that when they comment on other people's programs or designs, they can always find a lot of flaws, but their own programs are also poorly written. Always criticizing and complaining without any constructive suggestions or feasible solutions.

These bad programmers always like to criticize other people's programs to show their excellence.

9) Stubbornness

When you give a dozen evidences that there is a better solution, there is a better direction, they will always stubbornly think that their own approach is the best. An example I have personally experienced is that when I see a new program going in the wrong direction when solving a problem, I remind him that you may have gone in the wrong direction, and it should be the other way, and I prove it. There is a simpler way to show him, yes. However, this programmer told me, "That is my method, and I must follow it, otherwise I will be very uncomfortable." So, during the code review three days later, after stubborn explanations and a lot of doubts, In the sound, he had to adopt the method I first told him.

These programmers never think about it, nor do they go to people to discuss whether there is a better way. Instead, they stick to their own ideas, even if it is a dead end, they will always move forward without hitting the wall. Look back.

10) Write "smart" code. The code they write requires other colleagues to check the programming language reference manual, or the logic or style of the program looks quite fashionable, but is very difficult to read. Code should be concise and easy to read, and they like to express themselves in the code and try alternative things to show their talents. Yes, only programmers of questionable ability need to resort to such a display.

I remember a previous experience. A programmer who was very good at English joined the company. Originally, for those of us who are good at English, what we like to see is simple and easy-to-read English documents. Then, the guy wanted to Showing how good his English is, he used many unfamiliar phrases and vocabulary in the GRE. Make it difficult for everyone to read. The most ironic thing is that a native American later asked him in his email the meaning of a certain word. hehe.

Are you a bad programmer?

Receive LAMP Brothers’ original PHP tutorial CD/"Essential PHP in Detail" for free. For details, please contact the official website customer service: http://www.lampbrother.net

PHPCMSSecondary development http: //yun.itxdl.cn/online/phpcms/index.php?u=5

WeChat development                                                                               

Mobile Internet Server Side Development http://yun.itxdl.cn/online/server/index.php?u=5

JavascriptCourse http:// yun.itxdl.cn/online/js/index.php?u=5

CTOTraining Camp