Bad Habits of Web Developers (That NEED to be Broken)
Bad habits are easier to pick up than good habits, and often, these habits are bred from laziness or improper training. For web developers, whether you’re fresh to the game or a long-time pro, here are some habits that should be avoided or broken — today.
Relying on what you already know.
As a web developer, you have to be self-sufficient and motivated. Your main job is to learn new things, constantly. If you can’t keep up, or don’t try to learn the newest tech of the day, you’ll be left behind as new programs and trends come out. If you’re out of date, fewer people will want to work with you.
Letting organization slip.
If you’re not organized, you make it harder on yourself and anyone who collaborates with you. Whether it’s commenting code, using best practices, or making sure your naming conventions make sense, be organized and consistent throughout every project you work on. Your colleagues and clients will notice.
Not utilizing Version Control Systems.
Tools like GIT and SVN allow more efficiency and collaboration with other web developers, and reduce the risk of overwriting another person’s work. Even if you’re currently working in an environment where you’re the only one coding, it’s important to be familiar with these version control tools because it’s likely that at some point down the road you’ll be working with a team.
Saving messy backup files.
Making backup files for projects you’re working on can be a good idea, but using version control tools is better. If you use backup files as a shortcut when you’re adding new code or functionalities to ensure you don’t break any currently working logic, be sure to clean up them up upon completion. Having numerous unclean backup files leaves a confusing trail for anyone working from your files in the future.
Creating inconsistencies in a project you adopt.
Every web developer has their own way of writing and organizing code. However, if you’re taking on a project someone has already started, and it’s obvious that things are set in place (folder or naming structure), you should continue that organization method — even if you don’t agree with the way it’s being done. Respecting the existing structure ensures that if someone else takes over after you, it will look like one cohesive project. At the end of the day, keeping a cohesive structure saves you time because you don’t have to rewrite existing code and makes things easier on whoever comes next.
Thinking your code is easy to understand.
Just because you think your code is easy to understand, doesn’t mean other web developers think it is, too. That’s why comments, naming conventions, and best practices are so important. If someone working on a project after you happens to be less experienced, you’re making it harder on them. Make your code straightforward, and if it requires explanation, write a comment. This is a step that takes a whole five seconds, but for some reason a lot of web developers just don’t do it.
I’m not talking about intentionally creating vulnerabilities in security; I’m referring to essentially putting code together with toothpicks and gum. It’s important to understand the system you’re working with and get used to its documentation. You might “hack” together some makeshift code that functions and creates the same result as doing it the right way (for now), but this practice could create problems down the road. When new updates change how codes work, a client wants a new functionality, or a new web developer adopts the project after you, your “hacked” code could cause major headaches.
Of course this list could go on and on, but these core habits are ones all web developers should consider adjusting to make their lives, and the lives of those they work with or those who come behind them, much easier.