5 Habits to Avoid as a Developer

Regardless of your job title - are you a junior or senior developer or even are you frontend or backend developer, some bad habits are developed through career or learning experience. In this article, I would like to take a look at some common and annoying habits that can do damage to your career and further personal development.

1. Not asking for help

I can't emphasize this enough. All of us occasionally get stuck at some code/problem solving. That is completely normal and legit. Like the picture below explains:

Whether you are proud and curious so you want to resolve problem by yourself or you just started working at new company and you are a bit fearful, finding the solution for your problem should be time-limited. Do not spend days searching for solutions if you have someone next to you that can give you an answer in second.

2. Stop learning

It's well established by now that we are living in a modern era now. It doesn't matter are you a developer, doctor or even mechanical engineer - because everything is changing every day. No one knows everything about anything. If you stop reading, experimenting with new technologies/projects, you fall behind a lot. The time you read and try something, new things come out other day and you have to keep with it.

You should do this aside from your work, because of yourself and your position on the market. In my opinion, no employer is required to pay you to learn in your 9-5 work time, but if they are already doing it you should use that chance 100%.

3. Code (Dis)organization

Don't convince yourself that code styling is not important. It is very important!

Writing readable code is art that needs a lot of practice and discipline. Some people have that, some have to learn it.

Some advices regarding code styling:

1. Use indentation where needed - If you are not sure where, ask your senior colleague to review your code. If you are even writing simple HTML, indentation is very important for code readability.
2. "I'll fix it later" - There is no later, if you don't fix it now then that will arise later when you don't need it or as an issue or you have to upgrade that part of code.
3. (Not) Using informative names - Naming is very hard, but as long as the names contain some information, other developers will have an easier time reading your code. Just give a general idea to the name what does that part do. Good name can help you understand what that part of the code does in seconds.
4. Ignoring best practices - This depends on company culture and yourself. There should be code reviews, test-driven development, quality assurance, deployment automation, and several others. Take the time to learn how to do them properly and your process will improve in all projects.
5. Error and warning messages - Please don't ignore this. I saw some developers not having window for error and warning message opened at all. That shocked me a bit.
6. Reinventing the wheel - Nope, there is for sure some library or code example that is doing exactly the thing you need.
7. Comment your code - No description needed.

There are many more advices that could be written here, but I saw this at all seniority levels and it really annoys when you have to spend hours because someone named control 'LinkButton1'.

4. Take a break, spend quality time with family

The first thing that I advise when you are at work - take often breaks. We often get deep into the coding and sometimes we even forget to eat. Programming is a cognitive process and there are days where you can give full 8h from yourself and sometimes even less per day. You are not working something repetitive that can become routine and you don't have to think about it. When you're coding, after some "coding chapter" get up, walk to the window or go to the kitchen, take a glass of water or something.

I understand you get paid for what you are doing, but work is not everything in life and we are not robots - we are social beings. Make time for your family and friends. Make balance.

5. Know-it-all and owning the code

Don't be this kind of person. Stay humble. We are not perfect and our code is and will be always away from perfect. You don't own the code - it will change next day or in a year by some other developer. Don't get me wrong, you should own your code in the terms to support it and help others to understand it, but accept criticism or code review or even change on your code.

Having excessive confidence in your own code is also dangerous. Please take a look at the code that you wrote 1 year ago and get back to this article.

Also, last advice regarding this - take time to learn how things really work and what project asks you to do it. Don't assume anything and don't have in mind that you know what is best for the client/software.

I hope you enjoyed reading this article :)