“The worst enemy you can meet will always be yourself.” Friedrich Nietzsche

One of the most important lessons every developer must learn is they can be their own worst enemy and in their career cause themselves problems?

It’s the punch you don’t see coming that knocks you out and sometimes developers can punch themselves in the face.

In between creating awesome software, developers can often be found tripping themselves up and getting in their own way.

Assumptions — Talking instead of listening

Creating software is a dance between the customer and the developer. The customer should lead the development team and the developers gracefully follow their lead.

Developers listen long enough to get a rough idea of the requirements before they drift away into the lovely world of designing the technical solution.

There is usually plenty of gaps in the requirements that need to be clarified. Instead of understanding the business and clarifying the requirements, the developer will assume how the system should work.

The developer builds software on top of these assumptions. When users get to use the software, bugs appear where the assumptions are wrong.

Assumptions are bugs created by developers thinking they know how the software should work. Not only do you bug for the assumption, but you also get bugs for functionality dependent on the assumptions.

Technical first attitude

When Developers and software projects focus on the technical solution, they lose sight the goal of creating software. The goal of the software is to be a tool for users to do their jobs and to help the business.

We should always create software with the business taking center stage and leading the project. The software should align with the business processes, people and problems.

When you develop using technology first, you create software that is hard to use

Golden hammer

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail — Abraham Maslow

To a developer with a keyboard, everyone's requirement looks like code.

Some requirements don’t need code, they need a manual step or a change in the process. Developers are good at writing code and they can create code for any requirement.

Just because a developer can write code, it doesn’t mean they should. Code is a liability and every line that is created has to be supported. The less code there is, the easier it to support.

“One of my most productive days was throwing away 1000 lines of code.” Ken Thompson

Copy and paste development

The internet makes it easy to find solutions to our problems but Copy-and-Paste Developers Suffer From Fragile Knowledge. Copying the solution misses out the learning, it’s a shortcut to fix a problem quickly.

Like a kid learning maths, you don’t want just the answer; you need to work out answer different sums.

This creates a long-term problem if we need to change the solution or create a similar solution. We can’t because we don’t understand the solution.

Infinity gauntlet

Like Thanos armed with the infinity gauntlet, developers give themselves admin roles in too many environments and services.

This creates the possibility of deleting, changing, and breaking things they should be able to. Developers believe they would never be so stupid, but they are because they are human and they make mistakes.

There is nothing as more chilling than the moment you realise you have deleted something in the wrong environment.

In most cases, developers can recreate the environment with devops but sometimes there is no easy fix.

If you can, never have access to a production environment, it’s for your own safety.

Bugs and testing

Developers love creating software but hate testing software and are rubbish at testing software. It’s a cruel twist of fate, developers create the task they hate the most.

There is no excuse not to have tested your own code, and it makes developers look like cowboys when a user tries to do the most basic test and it breaks the first time.

Some bugs are part of the process but some bugs are because developers are being lazy. Software development is a loser’s game. You win by reducing the mistakes you make.

If you don’t ask, you don’t get

Developers are good at complaining but are terrible about asking for what they want. They hope other people realize what they want and give it to them, an approach that rarely works.

The list below is on average, not specific individuals

• Wages → Developers are not good at negotiating wages or asking for higher wages.
• Promotions → developers often forget to say they want to be promoted and then forget to provide evidence why they should be promoted.
• Training → Developers complain they don’t get training but fail to ask for any training.

Knowledge sharing

Writing a document is boring and much less fun than writing code. Unfortunately, leaving the knowledge only in the heads of developers means it disappears when the developers leave the company or project.

This leaves development teams trying to work out by trial and error or reading the code.

Underestimating

The golden rule in software development is the lowest number you estimate will be the one the customer remembers.

NEVER GIVE A QUICK ESTIMATE YOU ARENT SURE ABOUT

You gain nothing by saying something will be easy without thinking about it. Everything in software development seems easy at a high level. It gets more complex and harder the more you think about it.

Developers give a quick estimate to be helpful, but it doesn’t help themselves.

The other way developers hurt themselves is by assuming the happy path and assuming they will get distracted. If things can go wrong on a project, then at some point they will.

Automatically add a margin of safety to your estimates. This is what senior developers do because they knew (by learning the hard way) that creating software is never straightforward.

What the developer creates with one hand, he deletes with the other