Why you do the code?
What is your reason for doing maintenance, tests, CI/CD, refactor?
This post was originally written on my personal blog, mirekstanek.online.
If you watch TED Talks it’s pretty likely that you have seen one of the most viewed presentations: “How great leaders inspire action” by Simon Sinek.
The model proposed by Simon explains where the leadership success comes from. Apple, Wright brothers, Martin Luther King — they all have one thing in common. Something that makes people follow them — their dreams, their vision, their plans.
It is the well-explained reason why.
People fell in love with Apple not for the innovation but for challenging the status quo. Apple’s vision is to inspire people to “think different”. And this was the reason to build beautiful and simple to use products — Mac computers, iPods, iPhones.
They didn’t build very first mp3 player but still, iPod was recognized as a music innovation. Why? Because it challenged the status quo of the music industry — how the music is distributed and how we consume it.
They didn’t build a 5GB mp3 player. They put 1000 songs into our pockets.
Now, Simon Sinek’s talk is usually recommended to managers, CEOs — any kind of leaders. Because their role is to inspire. “To create an environment in which great ideas can happen”. But also to challenge them to check if their vision is sharp and they know how to share it with the others.
Now let’s assume that this is not your dream to lead people. You prefer to build robust solutions, be the master craftsman or the innovator who knows how to make the impossible possible. You do data science, software or hardware engineering or quality assurance. You make the leaders visions happen.
Does it mean that you shouldn’t know your reason why you do what you do?
Absolutely not.
There are a couple cases in which your reason why can be really important.
The vision is clear, but you have your personal goals
You work for the company with the clear vision for its product. You can believe it or not. You want to make the world a better place because who doesn’t.
But you also want to be a really good software engineer because you simply love what you do, because you were hired to be the one. It doesn’t really matter to you if the company makes the revolution in healthcare, finance or automotive markets, you do your best in your field to help it succeed.
In this situation, the company makes sure that you have the picture of the world where your product is there and serves people. You have long-term plans, well-defined tasks list, deadlines.
Why then should you care about being able to explain your reason why?
Because crystal clear vision is really tempting for the leaders. And sometimes it can be really hard to interrupt and “delay” the vision’s delivery with terribly sounding tasks like:
- maintenance and code refactor,
- writing unit tests,
- building CI/CD environment,
- QA
Do you know how to explain it clearly that you need a day, or a week to do one of these?
How would you say that you need 3 additional days of work for better code structure, refactoring and adding some unit tests?
Would it be:
Hey, I finished my work on feature x. Now, like we agreed, I need 3 additional days to clean up the mess in the code so it can be more readable by other devs, well structured and extendable in the future.
Or:
Hey, I finished my work on feature x. I think I identified some weaknesses in the code which will prevent us from fast iterations in the future. If I spend additional 3 days on this we’ll be able to deliver new value to users faster than now.
Or how would you explain that you need to build CI/CD environment with additional end-to-end tests for your product?
Would it be:
Hey, our product is so complex that I need to build an environment for automatic builds and product testing. Without it, I need to wait up to 10 minutes each time when I build the code. It also takes up to one hour to push it to production. With the new CI/CD environment, the machine will do it for me so I can spend more time on coding.
Or maybe:
Hey, our product is so complex that building and testing process makes us able to release it no often than once per month. With the new CI/CD environment, we’ll be able to release once a week and our automated tests will guarantee that core features will always work according to the assumptions.
It’s very easy to forget that our job is to build the product that works. Our goal is not to make our job easier. It is to make it more effective at any stage that helps the company a build better product.
The vision is clear and you really care about it
This is probably the most comfortable situation. Company’s vision is clear and it’s very much in line with your beliefs. That’s great!
But in this case, there will be no one who protects us from the temptation of going live quicker than the product is ready for it. Your CEO won’t ask you if your code structure keeps standards.
In that case, it can be even harder because you need to find the reason why and convince yourself with it. Especially when it’s easy to satisfy your boss “just” with working functionality dressed in beautiful UI and intuitive UX. For sure you will get the approval and the applause 👏, no matter what’s behind the mask.
But are you ready for taking the long-term responsibility for it?
How would you explain yourself the need for having well-structured dependency injection graph or unit tests? If it’s just about keeping the standards and good practices, we are really good at breaking those rules.
Without a good reason for why we need them (e.g. “I want to enable fast delivery so I do unit tests to cover cases in a matter of milliseconds instead of minutes of manual testing”), we’ll find countless reasons to not have them (“I’ll come back to it later”, “It’s too simple product to cover it with tests”, “Without writing tests I’ll reach production one day earlier”).
Just challenge yourself. Very often only you understand when your job is done well.
The vision isn’t clear
The last case, probably the hardest for everyone - leaders and their teams. Sometimes it happens that the vision isn’t clear. There are too many directions or there is no direction at all. Or leaders cannot easily explain it, or they are still looking for it.
The situation isn’t very comfortable, but actually, it’s similar to the case where vision exists, but it’s not in line with your goals. You probably still will need to convince your leader, not yourself, why the maintenance, or CI/CD, or the testing stuff needs to be done. The only difference is that there is no temptation to deliver too fast, but the pressure to succeed.
So what would be your reason why in this case? The “stable, clean, well-tested code which I’m proud of, no matter of what’s the vision behind it”? Or maybe the “environment for fast product iterations, smart failures and easy recovery”?
You want to be a partner or you simply don’t care? You want to complain and wait for better times or you want to make better times happen?
What is your reason for why you do your code? Can you explain it to someone?
Can you explain it to yourself?
