5 Mistakes Badass Developers Never Do

Here is a one sentence summary of my previous post.

Badass developers negotiate large scale refactorings with the business better.

Unfortunately, not all of us are sitting next to a true badass developer … Hopefully, we can all become one ! Depending on our track record, it’s going to be more or less difficult, but with time and the good attitude, we can all do it. Becoming a badass developer is all about trustworthiness.

This post is the third in a series about how to get sponsorship for a large scale refactoring. If you haven’t, I recommend you to start from the beginning.

The first thing to become trustworthy is to avoid things that kill trust. Sounds obvious, but it’s very easy to forget. Here are 5 examples of trust killers you should never do if you want to become a badass developer.

Drawing of a hurt finger after someone made a mistake with a hammer. Badass developer don't do this kind of mistakes !

Resume Driven Development

We should pick the best tools for the job. The best tools are often a bit old, precisely because they’ve been battle tested in production for a while ! That’s exactly the kind of technologies you want your business to rely on.

To keep his skills up to date, a badass developer will not add a funky new tech in the production code. He would rather negotiate slack time with the business. He might also openly take his Friday afternoons to experiment the latest techs ! He would simply explain that it’s to avoid polluting the production system.

💡 A badass developer will not add a funky new tech in the production code.

Over-engineering

Gold plating or over-engineering are similar anti-patterns. A badass developer always keeps the business’s interest in mind. This means he knows how to balance long term design and short term features. A good rule of thumb is to keep a vision in sight, but to get there in baby steps.

Build features with no agreed upon value

Product managers are here to select what should and what should not be in the product. As product experts, they are the ones who know how much a feature is worth. Except (maybe) when we are building tools for others developers, they know better than us. Adding something of dubious value in the product is bad in two ways. 

  • First, it takes some time to build, time that we could use to build valuable features instead. Remember : Real developers ship !
  • Second, it creates unnecessary code to maintain. In the worst case, it can constraint the architecture. Which might eventually prevent us from adding other more valuable features afterwards.

Hide in a tunnel

We should always be careful of the tunnel effect. Seeing their money vanishing with no visible output makes business people, understandably, creepy. As soon as things become too complicated, a badass developer will raise the alarm. The fact is that he has been in this kind of situation before, and knows how to recognize it. At that point, it’s still possible to discuss the problem with everyone, and adjust the plan.

As an interesting side note, I was at the Paris DDD Meetup last Thursday. We had the chance to welcome Eric Evans as a surprise guest ! When asked what were his worst mistakes, he said something along this line :

💡 Some of my biggest mistakes were not backtracking soon enough a few times as I was drifting in quagmire. Eric Evans

Eric Evans, the father of DDD, a true badass developer, answering questions at the Paris DDD meetup


Let the team down

It’s not only about getting the business’s trust. We must also build trust from our fellow developers. Whenever we break the build and leave, or worse, deploy and leave, that trust is gone for a long while… We should not do that !

There’s more to a badass developer

I’m done with this list of things badass developers don’t do. Avoiding these is only the first step to become a badass developer. In next post, I’ll write about what we need to do if we want to build strong trust with the business.

This post is the third post in a series about how to get sponsorship for a large scale refactoring.

Comments