Update your software as often as you can
We all have been there: “Look, there’s a new gem to try instead of the old one. “ “Look, there’s a new Rails version out. Let’s update today. “
Yes, I’m guilty of this too.
The difference, though, between the version of me from today and the developer I was ten years ago is that I know when to listen to this voice in my head begging me to try something new.
I worked for a startup a while back. Our young CTO loved new, shiny things. We also had a few developers who were always desperate to try new tools/gems.
One day, I was working on a piece of functionality, and as you do, when I was happy with my work, I created a pull request (PR). That’s when my troubles started.
As the excellent practice dictates, we did code reviews for all PRs. One of the young and keen developers reviewed my code.
All the functionality was fine. He suggested one minor change. Why don’t I use this new approach to organise my code? I thought about it and agreed to the change.
It would make things easier and more readable.
A few hours later, I raised a new PR or, rather, asked for a new review. This young developer made another suggestion of reorganising the code another way, again.
At this point, I replied something like this: “Sure, this would be another way to organise this. But I just rewrote the code so we can follow the first suggestion.”
At this point, the CTO got involved and told me to rewrite the code again.
To be clear. The code was well organised in the first place. The suggested changes were essentially something like “Hey, let’s use decorators instead of this” and later “Hey, let’s extract this into a library file instead.” There was no functionality gain, no readability gain, just different approaches to a solution.
So, I spend another day begrudgingly rewriting the code again. The PR was finally merged.
In the following months, the situation repeated similarly.
“Hey, I just saw this great new gem. Let’s use it.” and CTO, “ Yes, that looks cool. Let’s switch, “ and so on.
I left a couple of months later.
“Resist the temptation to chase the latest technology trends. Instead, focus on understanding fundamental principles that withstand the test of time.” — Martin Fowler
This experience taught me one vital lesson. Be aware of the shiny object syndrome.
There is a place and time to try new things, and I love to do so. When new Rails is released, I plan for the switch in advance. But I don’t rush it. I take time so I can sort out more important things first.
Suppose you take away just one thing from my story. I hope it’s going to be this little voice in your head telling you, “Let’s not replace this gem yet; let’s think about this.”
Hey there, I’m Petr. Are you a developer who needs more time for skill enhancement and learning? I’ve been there and I can help you, Book a free discovery call with me.
