Top Programming Mistakes

We came up with a list of mistakes we think developers make through their careers. Check it out and let us know if you can relate to any of them, or if you have any more to add.

1️⃣ Failure to properly document the Specifications or NOT documenting at all because “the code is its own documentation”

We previously talked about the things that developers love to hate and documentation is one of them. 

If you believe that you or someone else can deduce what an app can accomplish by reverse-engineering its functionality, go ahead and try it, but why make it so complicated? At the same time, some of your coworkers may struggle to understand what the app does.

The main takeaway is that you must write documentation for others to understand, not for yourself.

2️⃣ Using quick and dirty hacks

Throughout their careers, the majority of developers have utilized dirty hacks to resolve issues. The problem with rash remedies is that they exacerbate technical debt. Additionally, quick changes may be damaging to team morale.

However, in some cases, quick and dirty may be relevant. In some circumstances, this may be the wisest course of action, particularly when the code has a short lifespan. However, correcting things right away will cost you in the long run.

3️⃣ Knowing only one programming language

To be able to get into some really good jobs and have a competitive advantage over other candidates, a good developer must be fluent in multiple programming languages.

There’s nothing wrong with sticking with a company for a long period if you’re progressing professionally. The issue emerges when there is no more room for growth.

In your comfort zone, you may assume you are really good at what you do, right? That’s true, but it means you’re not learning new things, and technology moves at incredible speed.

After a few years of making this mistake, your skills will no longer be “employable,” forcing you to work very hard to catch up and learn all of the new technology available during non-working days, which is not fun at all.

4️⃣ Back-ups not for you?

This may seem like an obvious question, but have you ever accidentally deleted data? Junior developers, as well as some experienced ones, may have been in the position of making this type of hard stopping mistake, which could have serious consequences for the business.

A company can lose millions of dollars if its data is not backed up. Oh, and another thing: full access and control should never be granted to those who don’t know what they’re doing or who may have malicious intent.

5️⃣ Underestimating the tasks

Things were not as simple and the alternate solution was much more time-consuming than you had anticipated.

In order to avoid underestimating effort, it is important to include both development and testing time in your estimate.

6️⃣ Assuming that your code doesn’t require testing

Testing is a dreadful experience for most programmers and they refuse to do it because they think it’s pointless.

Thorough testing weeds out potentially dangerous flaws, allowing the code to perform as intended from the start.

7️⃣ “But it works on my machine”

You need to acknowledge that you’ve made a mistake failing to consider a specific use case. Seeing feedback as a personal attack, developers especially the junior ones are more likely to reject it. Good or negative, feedback isn’t about you. A flaw in the code does not define who we are as developers. Also, it is not important who caused it, as our mission is to fix it.

8️⃣ No confidence or too much confidence

Too little confidence and you’re unable to act; too much confidence, and you’re unable to hear.

John Maeda

Confidence issues are common among junior developers. Initiation anxiety and a sense of inadequacy can be overcome with time and practice.

But what about the overconfident developers? They’ve done that task over a hundred times and there’s nothing else to learn or do better? Don’t get us wrong: we’re not saying confidence is bad; we’re just pointing out that it can sometimes prevent us from seeing the big picture and accepting feedback from others. A developer who ignores the fact that they, too, can make mistakes is more likely to make a decision without consulting others. It may not be the best decision because it may be “blown into the air by one’s own bomb” by failing to choose the best approach or making others feel undervalued.

9️⃣ Trying too hard to prove yourself

Proving yourself is a dangerous trap

Richard Carlson

Listen up, especially junior developers: we know that in the beginning, it’s all about demonstrating everything and everything you can do in order to impress others. But why waste time writing flashy code when you could be writing something that actually works, serves a purpose, and has good intentions? Come on, this gives you extra time to work on something that will add more value to the customer, your company, and, as a bonus, your own growth.

🔟 Reinventing the wheel due to a knowledge gap

You don’t have to reinvent the wheel, just attach it to a new wagon.

Mark McCormack

A common error is when a developer doesn’t know what the framework already does. Due to this lack of experience, they come up with new methods that are almost the same as the ones that are already in the framework.

As a result, more time is spent writing code that is already there and the framework isn’t used to its full potential.

The conclusion is that making mistakes isn’t the end of the world, but rather an opportunity to start over and do something amazing.

Our best piece of advice? Allow yourself to make mistakes, don’t be afraid of them! Yes, it’s difficult and frightening, but it’s necessary for your personal development.

Share on facebook
Share on twitter
Share on pinterest
Share on linkedin

Related posts

You might also be interested in