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.
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 their skills up to date, badass developers will not add a funky new tech in the production code. They would rather negotiate slack time with the business. They might also openly take their Friday afternoons to experiment the latest techs! They would simply explain that it’s to avoid polluting the production system.
💡 Badass developers will not add a funky new tech in the production code.
Over-engineering
Gold plating or over-engineering are similar anti-patterns. Badass developers always keep the business’s interest in mind. This means they know 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.
Badass Developers only build features with clear value.
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, badass developera will raise the alarm. The fact is that they have been in this kind of situation before, and know 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
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.
Leave a comment