Do you have this problem? Seven bad habits of programmers

1.-All programs are poorly written except me.

I want to tell you a bad message, brother. All programs are poorly written, including yours. No matter how much effort you put on it, most other programmers will always think that the code you write is very bad and they can write programs 10 times better than you.

How to correct: Do not pick other people's programs. One day, your programs may be criticized by people in the spotlight. Objective and professional comments should not be easily judged. Be humble, learn from the people around you, and warn yourself not to write such bad programs.

2.-I can change it in a few seconds without having to proceed with the change process.

Shortcuts are tempting, and everyone wants shortcuts. Sometimes it is necessary to copy shortcuts, but in general, copying shortcuts is dangerous and should be avoided. A shortcut may save you several hours, but if you go wrong, it may cause you several months of trouble.

How to correct: do not be too confident when handling things with caution. Let others review what you do. If you plan to take shortcuts, make sure your owner knows the reasons for doing so and the risks involved. Every time you take a shortcut, it is best to ask your manager to confirm the implementation is successful, that is, "Let him wipe your ass ".

3.-this can be done in just a few minutes.

In my hometown of Barcelona, the cathedral of the Holy Family makes me very proud. Its world-famous beauty comes from it, it also comes from the planning of its construction completion date (it started in 1882 and is not yet completed), but it may be because they didn't ask a programmer to estimate the completion time; otherwise, the estimated completion time is likely to be 2 weeks.

How to correct: from the very beginning, you must seriously realize that for a software development process of a certain scale, accurate time evaluation is unrealistic. What we can do is just speculation. Similarly, we often find that many things cannot predict that they will take us several times as much as we initially estimated, my usual practice is to multiply the estimated time by 1.5 or 2.

4.-Only my unique

The seminars attended by many programmers basically look like a fight, not a human discussion, which usually appears at seminars on design and architecture issues. Basically, you can easily see that each of them has a mentality of following us and following us. Basically, you can replace what most advocates say with cool! Cool! Cool! Cool!

How to correct: Keep your self-confidence in your heart. Being too conceited is the biggest non-technical problem for all programmers. Think twice about everything.

5.-This is not my fault!

In my opinion, this other bad problem that most programmers have is lack of responsibility. We are always making excuses... For example, some people may say that, under normal circumstances, this error will never occur, but to be honest, it is hard to convince people.

How to correct: You don't need to worry about making a mistake, or you don't need to commit suicide by submitting an slice. We should have a healthy attitude and say, "Ah, sorry, it's my fault to correct this mistake now." This is a very professional attitude, this will help us establish a good reputation and be better respected by your colleagues.

6.-No passion

Repetitive and simple tasks do not usually bring about any motivation, but these tasks must be completed. When programmers are asked to do these tasks, they are usually dejected and inefficient.

How to correct: disciplinary issues. Unfortunately, I can't think of any other remedy for this problem.

7.-immature

If we think of computer programming as sex, few computers can be satisfied. You don't have to devote yourself to it. If you do it in half, it's over, and then you go to bed. I found that most programmers are struggling with the word "finish. Keep in mind that doing this means that you have tested (not just a unit test), complete the documentation, submitted, merged...

How to solve: This is a very troublesome problem. Compared with solving some functional problems completely, these tasks are not very complex and difficult to handle, you usually need to be disciplined and trained. Perhaps, the simplest two ways for a programmer to understand whether his development is actually completed are mutual review and demonstration.