Ten actions that turn you into bad programmers

1) Emotional Thinking

If you start to look at the world with different colors, you may become a badProgramMember. Emotional Thinking or attitudes are likely to turn yourself into a monster. I believe you can often see that many bad programs use the following statements:

• My program cannot have this problem.
• Java is shit.
• What I hate most is using UML for design.
• Why is the demand changing.
• They can't stand these people.
• ...... ......

These emotional thoughts and attitudes not only make you a bad programmer, but also affect your future. Because sentiment is usually a devil, which allows you to make wrong judgments and decisions. The wrong bit rate judgments and decisions directly determine your life.

 

2) doubt others

Bad programs always say, "MyCodeIt must be correct. I suspect there is a problem with the compiler. "" I should have no problem. Why is the STL library so difficult to use ". I have seen programmers use it like this.
STL class: Map <char *,
Char *>. When he finds that the string cannot be obtained, he thinks it is a bug in the STL library and writes a map by himself! My God!

In some cases, it is a bad habit to draw conclusions too early. Everything has its own reasons. Only by knowing the reason can you know who the problem is. In general, it is always a problem of its own.

3) focus too much on implementation and get into details of problems

Sometimes, when we face a problem or a demand, bad programmers always find a solution or implement it immediately. This is a bad habit. The design pattern tells us that "like interfaces rather than implementation" means that recognizing the nature and features of a problem is more important than how to implement it.

• For a customer's problem, the first thing we should think of is how to let the user work normally and restore the system that is bleeding, instead of putting users aside to analyze the cause and solution of the problem.
• To solve a bug, it is important to reproduce the bug and understand the intention of the original program, instead of modifying the code immediately. Otherwise, more bugs will inevitably be introduced.
• For a requirement, we need to understand the business background behind the requirement, use case and actual intent, rather than discussing how to implement it. Only by understanding the user's actual intentions, actual use methods, and cases can you really design them.

Bad programs are always easy to get into details, arguing about how to implement and implement difficulties, and the root cause of the problem, ignoring things more important than these. Only by understanding the entire map can we know how to proceed.

4) use unfamiliar code

The best friends of bad programmers are Ctrl-C and Ctrl-v.
Sometimes, they don't know the exact meaning of the code and start to use it. There is evidence that the majority of bugs caused by copy and paste are found. Because the code can always be normal only in a specific environment
Work. If the context of the code changes, it is very likely that the Code will produce a lot of behaviors that you don't know. When you can't even control the code, what kind of program can you compile?

5) hard work rather than smart work

For bad programmers, we can always see that they are desperately correcting their bugs, and they always spend a lot of time completing a job. A good program may take twice as much time to prepare
Effective development environment, tools, and times or even 10 times during development to avoid some errors. Good programmers always use all tools or means to make their work more efficient.
Do not make any mistakes during development. The cost of making mistakes in the future will be huge, and the pressure for correcting mistakes at that time will also be huge. So bad programs usually bring themselves into a vicious circle and they look
It is always exhausting and hard, so there is no time to improve. The more problems there are, the less time there is to improve. Therefore, hard work may sometimes indicate that you are not a good programmer.

6) Always waiting, making excuses and complaining

When the demand is unclear and the environment is not satisfied, they are always waiting for improvement from others. When a problem occurs, I always make excuses or complain that this is not good, and that is not good.
However, it is not done well. Bad programmers always want their own environment to be the best, have clear requirements, have a very good development environment, have enough time, have a good QA, and have a strong team
Leader, considerate manager, enough training, good discussion, strong support from others ......, This is a kind of attitude of "coming out of your mouth, coming out of your clothes", and the world will never end.
Beautiful, a team needs everyone to fight. Besides, if everything becomes perfect, what is your value? Driving instead of waiting,
Leading instead of following.

7) Fostering office politics

There is a saying "ugly girl is a little strange", which means that if a person has no real ability, he will definitely do it in other ways.Article. The same is true for bad programmers.
Otherwise, they usually rely on improper measures to protect themselves by accusing others, shirking their responsibilities, or crowding out competent people. So bad procedures are usually accompanied by office politics.

8) do more and do less

Bad programmers always feel that they understand everything, and they do not feel that their understanding and knowledge are limited. This is what we call it. Yes, what do programmers rely on when they do not do well? It's just blowing.

Another way of doing this is that they are commenting on other people's programs or designs and can always pick out a bunch of bugs, but their programs are also poorly written. Always criticize and complain, without any constructive comments or proposing feasible solutions.

These bad programmers always like to criticize others' programs to show their excellence.

9) stubborn

When you give a dozen pieces of evidence that there is a better solution and there is a better direction, they will always reluctantly think that their own approach is the best. An example I personally experienced
Yes. When I saw a new programmer go in the wrong direction when solving a problem, I reminded him that you may be wrong. It should be another one, and I proved it easier to show him another one.
Methods. However, the programmer told me, "that's my method. I must keep it going, otherwise I will be very uncomfortable." So, during the three-day code review, after a stubborn explanation and
He had to use the method that I first told him.

These programmers will never think about it, nor discuss it with others. They will stick to their own ideas, even if they will go straight forward without hitting the south wall.

10) write "smart" code

The code they wrote requires other colleagues to check the reference manual for the language of the program, or the logic or style of the program looks very fashionable, but it is very difficult to read. The 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 with problematic capabilities need such a display.

I remember one of my previous experiences. A programmer with good English skills joined the company. For us, what we like to see is simple and easy-to-read English documents, the dude tried
Demonstrate how he is good at English and use many uncommon phrases and words in GRE. It's hard for everyone to read. The most ironic thing is that a Native American later asked him in his email
The meaning of a word. Haha.

Are you a bad programmer? Thank you for sharing your experience.

Link: http://coolshell.cn/articles/1081.html