How Adopting an Upgrader’s Mindset Made Me a Better Developer Today
To keep improving your software, nurture a positive and productive thinking
To keep improving your software, nurture a positive and productive thinking
My work as a data engineer at Kanda has shifted from being focused on projects to products as we scale up our platforms. This has caused me to reflect on my early days of coding, and my experience getting familiar with the products I have worked on in different organizations.
To be honest, I’ve wasted too much energy feeling frustrated. It would bother me when I had to work on a system where I didn’t agree with the design or when I inherited code that didn’t have great docs. Just a few examples.
It took me a while to accept that software development is always a work-in-progress.
Despite everyone’s best intentions, it won’t ever be perfect. In that way, code is like art (except you keep refining it even after it's released). Because of this, I now try to approach software engineering with an “upgrader mindset” — Focusing my energy on improving what’s there and figuring out what’s next.
There’s Always Scope To Improve
You’re excited.
It’s your first commercial software project, and you’re ready to work on a clean, well-architected codebase for a big project. Hitting it big time! You quickly realize that the codebase is not perfect. There might be documentation missing or you might find some questionable designs and awkward workarounds. “What would Uncle Bob say?”, you wonder.
It works, but…
If you voice the issues you’ve found, your senior colleagues will likely agree with you. The product works, but there are definitely a few kinks in the codebase that they’d like to iron out. Also, there are some manual processes that they’d love to automate. Also, that system component could really use a rewrite. Ah right, and they forgot to tell you about this helpful tool that you’ll need for debugging.
This is normal.
We’ll explore why that is. But realizing that production software can always be improved will start you off on the right foot. Reality is messy, so expect to find a bit of mess. This is where CI/CD practices come in handy, enabling the team to accelerate the delivery of those crucial improvements to the customer.
Sometimes Decisions Get Made With Incomplete Knowledge
Nobody wants to make a bad decision. I like to think that, as a team, we want to always do our best work and make great decisions. Here’s the thing: When we make a software decision, we need to balance many factors. Accounting for uncertainty is just one of those factors.
Optimal technical decisions always seem more clear in hindsight. However, in the moment when a decision is made, the future is unknowable. We can lean into that uncertainty by favoring dynamic, extendable designs. On the other hand, if we put too much focus on uncertainty, we won’t get our stuff done on time. Worse yet, we might waste months building something very dynamic that doesn’t solve our customer’s most pressing problems.
Software teams balance many factors when making a decision, such as:
What’s our budget?
How fast does this need to be delivered?
Are other teams affected by this decision?
How likely is it that the requirements for this will change in the future?
Are there any limitations in our dependencies that could impact this?
For these reasons, I try to avoid questioning the intent behind a software decision. Always assume the best intentions and try to focus on the content of the decision and how it could be tweaked to work for the new circumstances.
Adopting An Upgrader Mindset
Accepting that a decision made sense at the time, does that mean we should just leave it alone if it’s not a critical issue right now?
No, of course not! A “leave-it-be” attitude is going to pile up technical debt which can ultimately sink your software project.
Let’s try an upgrader mindset instead.
Start on the assumption that we all want to create a great product. If you find a problem, the team has an upgrade opportunity (and that’s great).
Identifying a problem isn’t enough. To make an impact as an upgrader, you need to find a path to improve the situation. Sometimes you can just go ahead and fix it yourself. You know, leave the campsite cleaner than you found it. Larger problems aren’t usually solved with quick fixes, so in those situations, you’ll probably need some teammates to put their heads together.
When you are working on a software product as a new developer and you encounter something questionable, here are five points to consider:
Be respectful. Assume that the person who worked on this before made the best decision they could, given the circumstances.
Don’t hesitate to (politely) ask: “Is this intentional?”. Your teammates might be able to provide additional context.
If you understand the context and feel that the problem is fixable, go ahead and fix it.
If the problem is larger or structural in nature, raise it to the team. Think of a solution ahead of time, but be open-minded to ideas from the team.
Don’t feel bad if the team isn’t ready to fix a large issue right away. Some improvements are not time-critical and prioritizations must be made.
Sometimes you need to champion an improvement for a while. A respectful tone goes a long way to get the technical team on board. For example:
“I had an issue implementing Feature X in System Y. I got some context from Person Z and I think we can avoid this issue in the future by reworking System Y. Here’s an idea for how we could do it, but what do you think?”
If management needs convincing, keep it short and focus on the impact to budgets and time spent by the team. For example:
“Every week, our team is losing 5 hours while working on Feature X because of a technical issue. The team agrees that, by reworking System Y, we can save that time going forward. We estimate it will take 20 hours to do. Can we plan this in?”
Conclusion
I believe that an upgrader mindset is a highly productive way of approaching old code, and it’ll make you feel less frustrated too. I may not always succeed at being this kind of coder, but it’s the kind of coder I strive to be. After all, there’s always something to improve.
So, let’s get to work.