Don’t fall into the same traps as most developers

Sep 11 · 5 min read
Photo by Valentin Lacoste on Unsplash

Experience is the name we give to our mistakes, according to Oscar Wilde. So, as you can imagine, developers with little experience haven’t yet hit the most common pitfalls. In this article I will show you some of these most common pitfalls, so you don’t have to fall into the same traps.

Most developers have probably fallen into at least one of these traps. Look at this article as a piece of advice, written from my experience, which you can benefit from — especially when you’re a relatively inexperienced developer.

Reimplementing Code That’s Already Available in the API

Most developers use some sort of framework to make their life easier. For an inexperienced developer new to the framework, it can be hard to know everything that is available in the API of the framework.

This often results in some kind of reimplementation of code that is already available in the API. Inexperienced developers are more likely to do this for two reasons.

Due to a lack of experience, the inexperienced developer doesn’t know everything that is available out of the box in the API. This leads to time being wasted on producing code that already exists in the framework. Their lack of experience also leads to them not using the framework’s full potential.

The second reason inexperienced developers often reimplement code is that they do not know where to look for in the documentation. Or even worse, they don’t look at the documentation at all.

This is a pitfall for inexperienced developers because it seems so tempting to just recreate the same function. Some functions only take a few lines of code to recreate. Plus it doesn’t take much time to write those few lines of code. But rewriting the same code has downsides. Double (untested) code is being introduced in the codebase. And the code gets more complex since a new function got introduced. Other developers are unfamiliar with that function and won’t understand why that function is introduced. Overall the complexity increases, which is something that you don’t want to do without good reason.

Don’t Make Things Unnecessarily Complex

Sometimes developers get in over their heads. The problem with this is that only experienced developers know when to admit it. Where experienced developers try to keep things as simple as possible, inexperienced developers tend to overdo things.

One of the reasons for this is that inexperienced developers will try to prove themselves to the rest of the team. They do this with all kinds of fancy stuff like quirky one-liners and overly complex abstractions. Technical debt is being added unnecessarily.

This pitfall will make the code more complex. Try to keep things as simple as possible. Experienced developers follow the KISS principle: Keep it simple, stupid. By adding technical debt code gets less readable and gets harder to maintain.

Silently Swallowing Errors

Silently swallowing errors is a mistake I’ve seen plenty of times from inexperienced developers.

A relatively inexperienced developer was working on a fix for a bug: a query that got executed wasn’t valid. The query was expecting a numeric value to check if a product was still in stock.

SELECT * FROM Products WHERE amountInStock > [numeric value]

The bug occurred because a numeric value wasn’t passed to the query. Instead, it got passed a null value. So the query looked like this:

SELECT * FROM Products WHERE amountInStock >

This triggered an error, of course. The inexperienced developer “fixed” the bug by typecasting the variable that got passed to the query to an integer. This made the syntax of the query valid but didn’t solve the problem.

Instead of tracking down the source of the problem, the inexperienced developer chose to “fix” the bug at the deepest level that was possible — entirely without bad intentions.

The correct way to fix this bug was by tracking down why a null value got passed to the query and fix that. One cause for the problem could be that the API that gives information about the stock was not available. If that’s the case the query probably shouldn’t be executed. The actual problem could be something completely different than a query not working properly.

By silently swallowing the error the real cause of this bug would have never been found. The “bugfix” that was implemented by the inexperienced developer was fine from a syntax perspective but would have swallowed the real error.


Ask an overconfident inexperienced developer how long a task or user story will take and he’ll tell you the shortest time possible. If you ask the overconfident developer if he’s written some tests, he will tell you that there is no need to. The code is bug-free and it is impossible that it will break.

If you think you know it all when working on your first job as a developer, you’re wrong. If you don’t know what you don’t know, you don’t know how much you’re missing. This is where most inexperienced developers struggle.

Be humble and open to constructive criticism. Take advice from the more experienced developers. This will help you grow as a developer. Having confidence is good, but overconfidence will work against you.

Only Testing the Happy Path Scenario

Inexperienced developers often focus on just delivering the functionality or user story. This is what is known as following the happy path. The delivery of the functionality or user story should come with tests. This another place we see a difference between inexperienced and experienced developers: inexperienced developers only test what users are supposed to do; more experienced developers will also write tests for edge cases.

Only testing the happy path scenario is naive. Users are unpredictable — you need to test more than just the happy path scenario.

Switching Tools

Having the right tools and knowing how to use them can save you a lot of time on a daily basis. You should really take some time to find the right tools. When you are looking for tools, you should pick tools that do what they promise.

If you have the right tools, you should stick with them. Don’t switch tools every week. It takes time to get to know the tools and master them.

You should also invest in a good IDE since this is where you will spend most of your time. Learn the keyboard shortcuts and learn how to use code snippets. Create your own code snippets to speed up routine tasks.

Furthermore, you should learn how to debug. Pick an IDE that has some sort of debugger so that you can see the values of all the variables that are being used. This will give you a much better grasp of what is going on and will save you a lot of time debugging.

Focussed on the Tech and Not the Business

Inexperienced developers have not mastered their tech stack yet. And most of these developers tend to be so focused on learning the tech stack that the business gets out of sight. On the journey to becoming a master of your tech stack, it’s important to keep the business in mind. Why are you building this?

Some developers are only interested in the technical aspects of their job. They don’t care about the business or the economic factors that justify their job’s existence.

Is what you’re working on creating value for the business or are you spending too much time on something that doesn’t really matter? It’s an important question to ask yourself.

Better Programming

Advice for programmers.


Written by


Backend developer from The Netherlands. Crypto enthusiast.

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade