10 bad habits programmers should avoid

Every programmer will inevitably develop some bad habits during his or her working life and study experience. I n this article, the editor shows the reader some bad habits that are with and are difficult to change. Hopefully, if you're new to the programmer profession, try to avoid these bad habits, and if you've got them, hopefully you'll be aware of them and start to change

First, not enough rest

I'm sure many or almost all of you feel guilty about this bad habit. M e too, and I still feel guilty about not having enough or not taking enough rest. T here was a time when I went to sleep at 6 a.m., got up for lunch around 1 p.m., and worked until 6 or 7 a.m. the next day. I t's almost so common, almost every day. I 've done a lot of ridiculous things when the task is urgent. I think each of us has been in this situation when faced with DDL, and I'm not talking about that, it's your daily habits.

I suggest you take as much rest as possible every day. I can't say that specific plan, because everyone is different, but in a general sense, you should get up every hour to stretch your limbs, move, have a cup of coffee, and have something to eat. A lot of times, if your mind is stuck, then you need to take a break, and getting the brain to rest can help solve problems more easily. S o find the right way to rest. Even if you don't think you need a break, try it and you'll find yourself much more efficient.

Second, refuse to seek help

This article is common in both learning and work scenarios. M any of us don't ask for help. T here are many reasons, but I think the main reason is nothing more than self-esteem and fear of making people think they will do nothing. M any of us have impostor syndrome and feel that we are not fully qualified for our job. I feel this way in the company, in dealing with clients, even in classes and coaching. W e think asking for help reinforces that feeling. But in fact, it wastes a lot of time and hinders your growth.

• Other real developers are video or book-like resources, even much better than these. They can answer your question directly and help you really understand it.
• Only assholes criticize you for asking questions, and I try to avoid them.
• If you want to find the answer yourself and don't want to ask for help, that's fine, give yourself a time limit. Don't waste a few days searching for answers when your predecessor is right next to you and he may know or at least help you.

Third, stop learning

Whether you are a senior developer or not for more than 20 years, you should always think of yourself as a student. T his is more demanding than most occupations because the line is always changing. N o developer can know the full contents of everything, they do it this minute, change happens in the next minute, and they have to learn more. I f you are complacent and stop reading and studying, you will fall behind. E ven if you have a job that doesn't require learning anything new, once you lose it (which is not impossible), you'll fall far behind. So even if there is such a job, I also recommend that you study while working.

No matter what language, framework, library you like, you should keep your knowledge up to date. T his is understandable if your position requires only old knowledge, as many leaders tend to think that if the company is not gone, there is no need to fix it. S o you'll still find that some teams use outdated, unsupported technology just because it works. I f you're working on something new, you can show your team that new technologies that are faster, more efficient, and simpler are possible. You may be able to persuade them to update their technology and improve their company.

Four, confusing code

This article is more of a technical habit, but it can also mean a lot of things. Y ou should write code in an intuitive, efficient, and secure way. I t's hard to teach yourself, because what you learn in the relevant courses is not the best way to write some code, but the core concepts that the instructor thinks are easiest to understand. So you have to do some extra research to find the best way to clean up your code.

• I definitely recommend that you use the DRY principle of avoiding duplicate code (DRY principle, don't your repeat self). I f you encounter a common block of code, create some kind of class or function to combine this part of the functionality, rather than just repeating it. This makes the code cleaner, saves a lot of lines of code, and is easy for others to use.
• You should also pay attention to performance, such as compressing pictures, shrinking JavaScript, and CSS. You can use task runners (such as gulp) or other tools to automate compression, and in the face of small tasks, you can even do it manually, such as minifier.org.
• Also, don't make unnecessary API interface calls to get your full-stack application to do all the functionality you need with as few requests as possible. a nd testing... I made a lot of mistakes on this and didn't do enough testing. A s far as I know, unit testing helps build healthier applications, avoid potential problems, and save time and money. B ut I just hate it, and it's probably one of my worst habits, and it's a big problem I need to solve as a better developer. S ometimes we try to save time by reducing testing, but in reality, doing so reduces the performance, efficiency, and readability of the application, and it can cause more trouble in the future than using the right approach in the first place. So keep that in mind.

The imbalance between work and life

Work-life balance is really important, especially when we have a family. N o matter what type of programmer spends a lot of time at work, there are many reasons: things are always changing; the problems we encounter make it difficult for us to move forward; we need to study these problems, and so on... T his leads to a lot of times when we have to work late, start working early, and work overtime on weekends. T his will keep you away from everything in life, such as the people you love, your personal hobbies. You may like sports, hiking, or eating out, but if you're working overtime all the time, you can't do the things that make you happy.

I have a lot of experience in this field. M y wife and I have two children, one of whom has autism, but I can't spend as much time with them as I thought. I'm faced with a double dilemma because I have to deal with both coding and content creators, constantly coming up with new ideas, documenting them in a quality way, and so on.

If you're a freelancer and work for yourself, all your livelihood depends on getting the job done, and you'll only get paid if you've done everything. W hen you're paid, you have to worry about whether you can keep up with the schedule and whether you can get the job done. I t's really stressful and we have to squeeze other things out of our lives. I t's not that people who work for the company don't go through this, it's that when you need to think about everything, the stress levels are completely different. So I sympathize with people who have their own businesses.

But even so, you can't let it take control of your life, you have to make time for your family and friends, or, more frankly, for yourself. L ife is much richer than writing a few lines of code. Do what you love and balance your life.

Bad office politics

This article is for those who work in the company. Y ou work with other people, but this in turn leads to conflicts, disagreements, arguments, and so on. M any developers are arrogant and always think they're right, and even if they know they've made a mistake, some of them will never admit it. I 'm not saying it's most developers, but I think we'll meet at least one of those people. I've heard a lot of people say that their team is great and their members get along very well, which is great, but not all teams do.

• A lot of times you clash over ideas and solutions, trying to be sophisticated and respectful of each other, but at the same time, don't be too easily persuaded, especially if you're confident in your proposal.
• Don't shout, don't swear, don't do these things, it's no use.
• If they start treating you like this, you leave and be a stronger person.
• If you're unlucky enough to meet a team member who's a complete asshole, he doesn't listen to reasons at all, and you have no choice but to find a way to avoid him.
• In some cases, you may have to talk to your leader, but I suggest you talk to that person first.

Seven, can not learn from the mistakes

As a developer, you make a lot of mistakes, and it's inevitable that it's no big deal. But if you always make the same mistake and can't learn from it, there's a problem.

When you make a mistake, I recommend that you follow such a process:

• Find out what the root cause of the error is;
• Find a process that prevents errors from recurring;
• Find out if you've found an error earlier, and you can avoid the consequences.

When you make a big mistake, think about these three things, and chances are you won't make it again, or at least you'll find it early next time to avoid getting worse. At the same time, don't be too yourself for making mistakes.

Eight, give up too early

Frustration is an important part of programming. I made some videos about setbacks and how to deal with them. I 've also seen a lot of people talk too early about specific projects and programming because of frustration. S ome projects are really difficult, as if once you fix some bugs, it will lead to another bug, bug complex bug endless also. Y ou may start to feel that you can't handle it, that you could have done something else, that doing this is a waste of time, a waste of life, a waste of money... Y ou start to have a lot of negative thoughts. If you give up a project quickly, or quit soon, everything you want to put into the project or work will come to naught.

I'm not saying you can't give up on anything, I've seen people give up too many times on the eve of their impending success. S o before you give up, make sure you've tried everything you can: you've been asking up and down, asking for help, using methods, changing techniques, taking a long break to get your mind back to normal, and if possible, shelving for a while... Y ou did everything you could before you gave up, and if you fail, maybe it's time to give it up and move on. Success may be in sight, and if you give up at this time, it's a shame.

Nine, be an all-knowing person

As I mentioned earlier, I think some developers are arrogant because they think they know everything. T hey never listen to other people's opinions. T hey know all the answers. I f you're surrounded by people like that, it's terrible, and it's not good for you, because you think you know everything, and you don't actively study or improve yourself. I bet one day you'll be woken up by your own mistakes because you don't listen to anyone or do your own research.

Most of these people are the devils of Stack Overflow, an IT technology question-and-answer site, who make fun of new developers' questions, laugh at other people's answers, and click "No" at the first opportunity. I hate to die these people. I think a lot of them are always being approached at school, using their knowledge to bully other developers who may have problems or don't get anything, and it seems like they've forgotten about being bullied and just want revenge. There may be a problem with my theory, it's just a family statement.

Whatever the reason they do it, I think if they're open-minded, welcome different ideas, and respect others, they'll be happier than people who always want to be "right." T hey are probably the smartest and worst people on the team because no one wants to work with them and can't communicate well. C ommunication and unity are necessary for a team that wants to succeed, and omniscient people can destroy that. So if you're such a person, try not to be so conceited, be open, respect a little bit, and you'll go further.

10. Do not accept constructive criticism

The last one is somewhat related to the previous one and cannot accept constructive criticism. T here is still a big difference between an omniscient devil and someone who really wants to help you. Sometimes it's hard to see the difference because people point out your mistakes or imperfections, and you may not feel so good and feel attacked by others.

But in many cases it's not, it's just someone who wants to teach you a better way or share their opinions. A s a content producer, it took me a long time to learn to distinguish between pickers and well-intentioned people. A t first, when someone talked about how I did something, I was wary. B ut I realized that many of them were just trying to provide reasonable help. If they're not disrespectful, or just pick and choose something that doesn't matter, then I need to think of it as something that's good for me and for my knowledge.

Constructive criticism is a great resource for learning, because constructive criticism is very targeted, is your existing problem, is the specific solution given to you by others, which is priceless. In fact, code reviews are fantastic, and you can get suggestions from others to improve your code or even yourself.

So don't treat all of these things as personal attacks unless you're really under attack, or deliberately making fun of and disrespecting them. It's always hard to hear criticism or suggestions for improvement, but in the end, it makes you a better developer.

Whether it's new developers or experienced veterans, I hope these suggestions will help you.

Here's a look at W3Cschool编程狮 description of 10 bad habits programmers should avoid, hoping to help.