Ten bad programmer Behaviors

1) Emotional Thinking

If you start to look at the world with different colors, you may become a very bad programmer. Emotional Thinking or attitudes are likely to turn yourself into a monster. I believe you can often see a lot of badProgramThe following statements are used:

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 STL classes like this: Map <char *, char *>. When he finds that it cannot be obtained after being put into a string like this, he thinks it is a bug in the STL library, then I wrote a map myself! 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, most bugs are caused by copy and paste. Because the code can always work normally only 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, when you can't even control the code, what other programs 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 an effective development environment and tools, and double or even ten times as much time during development to avoid some errors. Good programmers always use all tools or means to make their work more efficient and always try to avoid errors 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. Therefore, bad programs usually bring themselves into a vicious circle. They always look exhausted and work very hard, so they do not have time to improve, and the less time they have to improve, there are more problems. 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, you are always making excuses or complaining that this is not good, and that is not good, so of course you are not doing 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, there are also strong team leaders, considerate managers, adequate training, good discussions, and strong support from others ......, This is a kind of attitude of "coming to dinner, coming to your ears". The world is not perfect, and a team needs everyone to work hard. 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. If their programs are not well compiled, they usually blame others, shirk their responsibilities, or crowd out competent people, and so on. 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. One example I personally experienced is that when I saw a new programmer taking the wrong direction when solving a problem, I reminded him that you may have gone wrong, it should be another one, and I proved to him that there is another simpler method. 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, he had to use the method I first told him after a stubborn explanation and a questioning.

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 old man used many uncommon phrases and words in GRE to show his English skills. It's hard for everyone to read. The most ironic thing is that a Native American later asked him about a word in his email. Haha.

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