Developers are notoriously susceptible to ‘impostor syndrome’ – the feeling of not being as good or as skilled as others think. Take a glance at any dev community, and you’ll find plenty of people knocking themselves down over some bug they could not solve or some project that took them too long.
Whether you started coding in recent times or have several years of experience behind you, you may also have sometimes asked yourself, ‘Am I a bad developer?’
I don’t know you and I don’t know how you work. Yet I can still answer that question for you, because I’ve spent long enough among outstanding developers to know what makes them good or bad.
Do you recognize yourself in at least a few of the following traits? Then perhaps it’s time to get to work on changing them!
I am not curious
For all of my own tendencies to compare programming languages to musical instruments, a developer is unlike a violinist in that the nature of their work changes substantially over time. The hard truth of coding is that your skills are perishable, and if you’re not keeping up to date with new technologies or expanding your skills, either at work or in your own free time, then you may well become a bad developer (or at least an obsolete one) in the space of 5-10 years.
Even with tools that you already know quite well, you should be constantly researching new things. Several of the languages and frameworks in modern programming are far too large for anyone to know everything there is to be known about them, but a good programmer should consider which features or commands to use before s/he starts writing code. You will not be in a position to do that if you have never investigated these options beforehand.
I don’t think outside the box
Imagine that you give two developers a complex task. One of them immediately starts writing code, while the other just stares at the problem for 15 minutes. The developer who started coding right away may look like the more expert of the two, but I for one would be more inclined to trust the other one.
That’s because a good programmer will start by considering a problem from different points of view, and mentally break it down into smaller parts, considering all the possible options.
When working as a developer, you will inevitably come up against some brick walls – problems that can’t be solved with your traditional routines, and which look insurmountable at first. Those will be the times when you need to look for a lateral approach to the issue, some way of stepping around the obstacle which you cannot climb over. A good developer tends to be one who can do this sort of thing consistently.
Nobody understands my code but me
Suppose that your client assigns you a task, and you come up with a solution that is so exceptionally clever that nobody else is able to understand how your code works. If it does the job, that’s great – except that your code will have to be updated (read: changed) in the future as the product itself evolves and new problems emerge. If you are working as part of a team, your fellow developers may also need to recycle your solution in other parts of the project.
You should always be writing code commentary or documentation that explains how your code works and why, especially if what you are doing is very clever. Remember that you are not working for yourself, but for a client. Learn to put their needs before your ego.
I always choose the clever solution
Even if you provide ample commentary for your clever code, does that code need to be so clever in the first place? A bad programmer is typically one who thinks the purpose of their code is to show off how intelligent they are.
In reality, the smartest thing you can do when coding is to find the simplest solutions consistently. This isn’t just a matter of making your code easier to maintain, but also of using your energy wisely. An unnecessarily clever solution will take up more of your time and effort, making you a less productive developer – and therefore a worse one – than you could be by taking it simple.
Final thoughts
Do you recognize yourself in the above traits? Then this is NOT the time to despair! Instead it’s the time to get to work, and the good news is that if you are asking yourself if you’re a bad developer, than you are already on the right track towards self-improvement.
Start researching new topics regularly, take more time to think of your problems in the abstract, get used to documenting your code, and take off your Smarty McSmart hat when looking for solutions. Every single problem I described above can be addressed with no more than time and a little diligence.
All masters in this field started off as bad developers. If this really is where you are now (and it’s not just another case of impostor syndrome), then it’s your choice whether to stay there, or whether to do what every developer should be doing all the time – work on getting better.