Everyone isn’t perfect, and it’s the most honest of truths. It is the same with programmers as with any other field in life. There are a lot of good, great, and still-growing-up programmers, but they are often not the best. We all make mistakes and everyone is human. Apart from faults, bad habits can also cause a lot of trouble. These bad habits may seem innocent at first glance, but if not corrected, can cause a lot of problems. In this article, I will discuss 10 bad habits that every programmer should avoid.
1. Working on your own all the time
It is important for you to share your progress and ideas with the team. Building something the right way isn’t always possible, so constant communication is very important. Communication can also benefit others when you work with them. If you talk with them about ideas and mentor the less experienced members of your team who tend to get stuck, their work often improves.
2. Having excessive confidence in your own code
If you write something, don’t assume it’s great just because you wrote it. Throughout your career, you will learn more about programming as you work on new projects and gain experience, so take a moment to reflect on how you’ve grown as a programmer.
3. Refusing to write bad code
There are times when developers will write horrible code because of deadlines. Even though you have warned the client or manager about the consequences, they insist on sticking to their schedule, so you now have to start coding. It could be that there is an urgent problem that cannot wait until you think of a solution. It is therefore important for a programmer to be versatile and that he or she can write good and poor code at the same time. In this way, you can revisit and eliminate your technical debt.
4. Blaming others
Arrogance is a common trait among technical professionals such as developers. Being able to admit your mistakes makes you stand out. Do not shy away from apologizing when you make mistakes. After accepting that fact, you can start learning from your mistakes and avoiding them in the future. Failure to admit to mistakes renders learning impossible.
5. Overvaluing your personal style
Ensure that your working style and environment setup are coordinated with your team. Each member of your team should follow the same coding style and work under similar conditions. If you do things your way, you might not be accustomed to your colleagues’ coding style, and if it’s unusual, the next developer might find it hard to work on what you have built.
6. Romanticizing your developer toolkit
There are times when your preferred editor or command line tool is not the right tool for the job. For example, Visual Studio is a good tool for developing IDEs, Sublime is a good tool for dynamic languages, Eclipse is a good tool for Java, etc. Vim or emacs might be your favorite tool, but that doesn’t mean they’re perfect for every situation.
7. Being too slow on giving feedback to managers/clients
The ability to ensure that everyone knows what is expected of him, as much as possible, is one of the finest traits a craftsman can possess. Your manager won’t be the only one who benefits from this. Furthermore, it is for your own benefit: You will have fewer fears about the future of the project.
8. Using names that don’t add information
Choosing names for variables and functions can be tricky, but you can easily ensure they are named correctly. Adding information to your names will aid others in understanding your code. Names are useful because they describe what a code does. If given a good name, you can see what a piece of code does in seconds without digging into the calculations.
9. Not using Google enough
A complex problem can be solved quickly by not having to solve it at all. Google it if you’re not sure. It is possible to ask the engineer next to you instead, but he won’t be able to provide as much detail as Stack Overflow. Also, you’ll be interrupting him from his work.
10. Giving up
Should you give up so quickly? Despite getting so close to a solution, too many programmers give up before they arrive at a solution. Developers’ lives are full of challenges, there is no doubt about that. Our daily lives are full of new challenges, and occasionally we feel stuck to the point that we want to give up. However, you must remember that giving up is not an option. It is true that there are some technical challenges that prevent us from developing some things. However, a long process does not mean it can’t be done. Giving up is different from knowing when to stop. Do not let the perception of giving up creep into your mind.
Habits are something we tend to get into as we age. Developing habits that you follow can help you not to have to think too much about every situation. When you become accustomed to good ways of doing things, they become effortless.
I’d love to hear what other coding habits you consider harmful. Leave a comment below
You can now extend your support by buying me a Coffee.😊👇
Thanks for Reading 😊
Oldest comments (12)
Some of this is contradictory or confusing. Examples and some reorganizing would've taken this a long way.
In your first point you chide people for not talking to their coworkers, then in the ninth you frame asking your coworkers questions as a bad thing. Which is it?
A lot of this can be boiled down into "Don't be arrogant about your favorites" whether it's your code, environment, IDE, etc.
You mention not being slow about communicating, but all we get is a quote about craftsmen and nothing concrete spelled out for WHY. Like most of this list it should be self-explanatory, but you didn't give much detail.
The mention of refusing to write bad code then picking at naming conventions seems backwards without examples.
It is 100% always an option. Not a great/idea/easy one, but it is always there. You can quit and find another job as worst-case scenario if your current job isn't working for you.
Also, regarding your last point, there actually can be situations for development, which just would need too much effort to solve it (if possible). Just imagine using a bugged product as part of your system and you find, that it does not work as expected and the company (creator) does not provide any fix or solution.
If we think about code (and I guess, this is what the article is about), if you cannot find a solution, you definitely have options, like asking somebody for support or postpone it until you have more experience.
The Google tip cracked me up, almost choked... I too think you mean well but seriously, ignoring the reality that there are many search engines and buying into the use of google as a verb to search the web is so doing dev skills and savvy a disservice IMHO. If anyone knows better it has to be developers surely. Might even have been better to write Not using Stack Overflow enough... though that would stink of the same product myopia.
Don't quit, can also tone down to Don't quit too soon or such... there are plenty of contexts in which refusing to quit is the problem. There's an old pop (or country if you prefer) aphorism that runs "You gotta know when to hold 'me, know when to fold 'em". Point being sometimes it's right to quit, sometimes it's right to power on.
I think the author's point on the Google one? I suspect their were more implying to...
"know your resources and use them!" And to take initiative. And understand what you are looking for and how to use what you find.
Google is still a great resource to remember. Of course, it shouldn't be your only one. And some coding fields would use it for research. There are some where trying to Google would be useless.
Again - comes back to knowing and using your resources. And sometimes that means becoming more familiar with all the in-house resources your company has available. I've worked at such a huge and complex place that this would be several places. It's intensive and you have to even know where to look to find what you need, depending on not only what department you were in but also what project you were currently doing.
Overall, to everyone who didn't like this article...
It isn't the final Bible on how to code. Any coder knows there are no absolutes.
I would have thought that knowing this article was only a slice, and not absolute. And that it may simply just not apply to your world? That other coders would already know this. And set their expectations accordingly for any article about coding.
These are suggestions. And good reminders. Just because this article isn't useful to you doesn't mean it isn't useful to anyone.
Just because your current job wouldn't look anything like what they listed as suggestions doesn't mean that those suggestions are wrong.
I've worked various places. Even for vastly different languages. Totally different environments. I
I often forget that most coders only know their slice of the world. And often don't realize that the coding job can look very different depending on so many factors. Many times things you'll never encounter due to what you specifically do. But... your world isn't everyone's world. Or even the average world. Rant over.
Good article.
Good rant, I've seen more than one person strongly disagree with this seemingly straightforward and uncontroversial article, which is surprising because most articles just have people commenting "nice article". The author is unequivocally pointing out habits that sound bad and giving general sound advice, I don't understand what people are disagreeing with.
The tip about the Google is spot on and I read it to be more like "Don't ask your colleague a question that you can easily find the answer to in a few minutes on Google". If the question is complicated, it's unlikely that an ad hoc chat with a colleague would provide you the answer you need, especially if you didn't do your own research first. If the question is basic, then you'd just be interrupting your colleague from their focus.
Wow. I'd think that anyone who has done coding for at least two years should already know all this. These mistakes not only cause issues for you, the coder, but can easily later cause major issues for the company. Not just that project.
One of my biggest pet-peeves are arrogant coders.
Avoid, when reasonable, working with (or managing) these types of coders.
8/10 items on your list are exactly what arrogant programmers usually do.
And, unfortunately, I've found they are nearly impossible to rehabilitate.
I'm sure that it tied to these types of programmers tend to have all the same personality traits.
Not saying they can't change. But...rarely they do. It's very frustrating working with them.
These types of programmers are FAR more common than you might think. And they can be coders of only a few years experience. Or twenty years in the field.
Hopefully, one of them might read this article and recognize themself. And realize that maybe they need to make adjustments in how they work. Who knows. Could happen!
If you don't want to communicate with the team, you can communicate with others on the network community, such as Reddit, Stackoverflow, Github.
Can you help me with book name that mentions Ramanujan's diaries, writings or thoughts.
I'm not sure which guideline or rule you are referring to in this article with your first sentence, but this article is listing bad habits to avoid, not rules to live by. I don't see how it's even possible to disagree with any of these 10 bad habits to avoid, considering how they are intentionally phrased to sound bad so that you'd avoid them.
While your comment is great advice in it's own right, it sounds like you thought the title of this article was "10 Coding Habits to Pick Up". Maybe the author edited the title or the content after you commented?
I have not changed the title 😀
Very good stuff