Principles that will make you become a badass developer
There are some simple attitude principles that badass developers follow to gain the business people trust.
In my last post, I went over things we should avoid if we want to become badass developers. As I said though, this is far from enough. Once we’ve stoped losing trust from the business, it’s time to build some more ! This is the forth post in a series about how to get sponsorship for a large scale refactoring. If you haven’t, start reading from the beginning.
The badass developers gain the business’s trust by sneaking in as business partners. A good way to become one is to start acting like one ! Here are examples of principles for that.
Keeping the business best interests in mind
This is all about decision making. We should try to steer decisions according to the business. Whenever we talk with business people, we should stay away from technical topics. I still remember my younger self explaining threading details to a trader… Most of all, I remember the look on his face! We should avoid technical bla bla, but we should be clear about the business consequences.
Honesty and Candor
When we don’t agree with something, we should say so. When we don’t understand something, we should ask the question. We need to stick to facts and assume everyone has the business’s best interests in mind. Candor is a way to get our opinions and questions through, without sounding rude or pushy. There’s a whole chapter about candor in Creativity.inc, the book about Pixar.
With time, business people will think of us as a positive and pragmatic problem solvers. That is exactly the kind of people they want to work with !
💡 Candor is a way to get our opinions and questions through, without sounding rude or pushy.
Strong opinions, but weekly held
Jeff Atwood, already wrote about this. The idea is to fight for our opinions, but let them go without a fuss when we proved wrong. We know that we are all very often wrong. Only fools or self-centered people don’t admit this reality. Business people won’t trust us in either case. We need to show that we can go over our previous opinions. This grows our reputation of rational problem solver.
Acknowledging when we don’t know
The same logic goes with knowledge. None of us knows everything. We have to admit when we don’t know something and ask for help. This proves that we place the business’s speed over our personal ‘know-it-all’ reputation.
Here is a story that happened to me at my first job. I’m sure most developers go through it one day or another. I was assigned a new task involving technologies I did not know. I did not have the guts to state upfront that I would have to learn them. The result was that I sent 2 full weeks fiddling with this task to get something working. The more it went on, the more the product people were wondering why it was taking so long, and the more I got stressed !
Be bold and say No !
If we are sure something we should not do something, we need to say so. Badass developers are not afraid to say they won’t do it. Good software engineering requires merciless prioritization. If there are doubt about the value of doing something, it’s often a better idea to make sure before wasting time on it.
There are many ways to say ‘No’. Before giving a harsh ‘No’, we can try to challenge decisions. We can ask for clarifications and rationals through open questions. Very often, highlighting the risks makes people review their plans. As technical experts, we should also share as much of the consequences as possible.
In the end, badass developers are ready to leave a FUBARed situation. Great engineers don’t have troubles finding jobs these days … There’s no reason they should accept to be waisting their time.
💡 In the end, badass developers are ready to leave a FUBARed situation
What do to next ?
As we become badass developers, our reputation will grow. We’ll be in a better position to negotiate a large scale refactoring with the business. There’s a catch though : we’ll need to live up to our reputation ! Admitting that we are wrong 100% with candor will not make it !
When we manage to negotiate a large scale refactoring, the team will need to do a good job of it. This boils down to delivering it piece by piece, alongside features. This is exactly what my next post will be about.
This post was the forth post in a series about how to get sponsorship for a large scale refactoring.
Leave a comment