There are loads of posts out there telling you how to be a great Developer, we've even written one here and here. But, what if you're not great? How do you know if you or your colleagues, or the guy/gal you just interviewed are not all they’re cracked up to be?
Here's our guide to spotting 10 common bad habits:
A big red flag is when code is unreadable. When you or any other Developer is unable to follow the flow of code and understand what is going on without help - it's not a good thing.
Sure, everyone has a moment or two when it's necessary to hack something together. But consistently bad style is unforgivable - especially in a team environment.
Everyone reuses code (why reinvent the wheel right?), but how you do so can say a lot about the quality of your work. Blatant copying and pasting of code instead of refactoring the logic shows a lack of understanding, and no thought to the solution's implementation. In short, bad problem solving skills.
Again, it's about making your code legible. Giving variables random names like str, i, j or k doesn't do anyone any favours. Take a moment to consider what the variable is used for. If it’s meant to be a sum of prices, then naming it SumOfPrices would give the reader (and you) more information than just naming it 'sum'.
It's also worth remembering that someone else will have to maintain the code at some point, so it needs to be clear enough for anyone to understand.
There is nothing worse than letting a stack trace bubble up to your users. You not only confuse your users by displaying a whole whack of geek speak on their screen, but you also expose some of the inner workings of your system (security alert!). Make sure that:
(a) Your user interface exceptions are displayed nicely and
(b) You handle your exceptions on the backend.
Use proper logging techniques to log your exceptions and handle the exceptions you expect to receive. The world will be a nicer place for all if you do.
Would you build a website and let it loose on the world without checking that the homepage loads? Or publish a book without reading through the story again to check it makes sense? Probably not. So why would you check in untested code?
Each company has its own testing processes. Even if you do have a dedicated QA (Quality Assurance) or Testing team, it's still no excuse for the dev-and-deploy approach. Don’t rely on QA to find your bugs. An error might be caught, it might not. If it's a really silly one, you may end up with pie on your face.
You are probably a great Developer. You come in, analyse a problem, build a great solution and knock it out the park. That doesn't mean you have to use every single piece of fancy knowledge you learned in school or read about online.
Don't over complicate things for the sake of looking like a rockstar. The simplest solution is almost always the right solution and "Consistency is often better than the most elegant design". ~ Oliver Gardner, Key Account Manager.
This one is true for all professions, but is exacerbated within Development as the industry as a whole moves so quickly. Keep up to date with what’s going on; read lots and ask questions.
"Find a tech news site that suits your personality and your style of humour and read it daily. It's the best place to hear about new concept/tools/hacks and to stay in touch." ~ Manuel De Jesus, SOLIDitech CEO
Everyone makes mistakes, we’re only human after all. If someone points out room for improvement or an error in your code, they are usually only doing it to be constructive. Helping you understand why an alternative path is better.
While one person hesitates because he feels inferior, the other is busy making mistakes and becoming superior. ~ Henry C. Link
Learning from your mistakes will help you become a better Developer.
Development is a detail orientated craft. If you’re not paying attention you can end up wildly off course. You run the risk of creating illegible code, checking in untested code or being fancy for the sake of it. All the while not building the solution, or solving the problem you were asked to. Not good.
Fellow team members, your boss and (heaven forbid) clients are all essential to your role. You are working with your team to create a solution that your client has asked for. Good communication will help you gain a deeper understanding of what challenges your client is facing, and how to best go about solving them.
There you have it: 10 common habits of a bad Developer. Remember though, nothing is impossible. Should you find there are a few home truths listed above, simply take action to avoid becoming a 'bad Developer'.
Can you think of any habits we've missed? Let us know in the comments below.