I am not good at drawing; I wish I were, but I am not. I got a lot of practice when my kids were younger. We spent a lot of time drawing with chalk on our driveway and sidewalks. We often drew things my kids were into at the time: cars, families, and trains.

For some time, my son was interested in rocket ships. So we drew many rocket ships. I still remember realizing my rocket ships did not look like rocket ships. They resembled…something else. And I had drawn a lot of them on our driveway.

That was a pretty embarrassing mistake. I was really looking forward to the rain fixing it. But ultimately, a common mistake is that mistake of self-awareness. I was completely unaware of what I was drawing.

This lack of awareness got me thinking about the types of mistakes we all make as software developers and engineers. The above example is just one type of mistake we in our industry may make (although they probably don’t involve potentially offensive chalk drawings).

Let’s look at some common mistakes we all make and what we can do to avoid them.

Too Trusting

Another mistake we make a lot in software is being too trusting. What if your software suddenly stopped working one day because of a code change not made by your development team? Well, that happened earlier this year. The author maliciously modified several npm (Node Package Manager) packages. When that happened, many projects were affected.

Now the npm world is a soup of unknown packages; it is a little surprising that this hasn’t happened more often. We are all way too trusting of software. I put all of us in this bucket. How many of us were affected by the Heartbleed bug?

Missing Requirements

Another basic mistake is not having everything we need to complete a task. How often do we head to the amusement park but forget to pack out sunglasses? Now, these minor inconveniences happen all the time. But when on a big complex project missing to factor in software license costs can have a tangible impact on the project. These sorts of logistics mistakes are common in daily life and in software.


If you are one of the lucky ones to have some success in software, success can often make you confident. And with more success, you can quickly become over-confident. Overconfidence leads to a lack of planning. People create a big goal and move forward but forget to think through any logistics of how to get there. I can’t help but think of Napoleon’s invasion of Russia with no thought of how to feed his army. It didn’t work out well for him or his army.

Another type of overconfidence is the kind that occurs when people with low ability overestimate their ability in a specific area. This can result in new developers feeling that something will be easier than they expect. How often do those new developers create wildly over-aggressive estimates?

Too Rigid

Sometimes in life, we can be pretty tied to a plan; we have to follow a plan. A great example was in WWII when Admiral Nagumo refused to break protocol and send planes out. Instead, he insisted they followed protocol and were rearmed with torpedoes before they were launched. In software, we make this mistake in subtle ways. We assume there is a database that stores all our data.

Ironically, this extreme rigidity almost always causes other problems. The irony is that we want constraints to make our life better, not worse. If you find yourself constantly bumping up against an artificial constraint question, ask if the constraint is providing value. Questioning the constraint every time you bump into it could be a sign that it probably isn’t the right option. Keep a lookout for that kind of pattern. If we had different constraints, would we have made different decisions?

No Consistency

The opposite of following the rules even when they don’t make sense is what happens more often in organizations. There is no standard, or everyone or every team has its own standard, making operating very difficult. Moving developers between teams in a world such as that is very painful.

Consistency is valuable. Clear standards must be set, understood, and followed by everyone. It is important to get everyone on board with the selected standards.






Looking For More?

Sign up to receive useful software development tips and news from the Don't Panic Labs team.

You have successfully subscribed!

Share This