Table of Contents
- Previously in the Series
- Rockstar Developer 🎸
- Popstar Developer 🪩
- What Goes Into Understanding a New Technology
- Same Applies to LLMs and Their Versions
- When Does It Actually Make Sense to Go All In on New Tech?
- Be Extra Cautious When Your Decision Might Affect Others
- Make Sure You Pick Tech for Long-Term Use
- You Don't Have to Pick Sides, Don't Label Yourself
- Conclusion
Previously in the Series
Last time, we dove into what it really means to stay old school in this chaotic, AI-powered era and the pros and cons that come with it. Catch up on the full article here:
We discovered that being too cool for school and proudly shouting "I'm old-school!" doesn't really do wonders for productivity, it's simply not pragmatic. And we, as software engineers, are supposed to be the most pragmatic people out there.
To stay relevant, we've got to stay open-minded, ready to explore new ideas, frameworks, and languages. That's how we keep up with the rapid pace of innovation and avoid missing out on opportunities that could completely change our careers (and maybe even our lives).
However, there's another extreme: the developers who chase every new shiny thing and just can't seem to focus on one thing for long. This post is about them, the Popstar Developers.
Rockstar Developer
As you might've guessed, the term that I've created "Popstar Developer" was inspired by the famous "Rockstar Developer."
A rockstar developer is basically a software engineer who stands out for exceptional skill, speed, and creativity, basically someone who can tackle tough problems, deliver high-quality code, and often drive major progress within a team. It's like a 10x developer, but with more personality.
Pretty cool, isn't it?
Popstar Developer
YOU KNOW AT LEAST ONE
Ever met a developer who gets way too excited about some shiny new piece of tech that hasn't even been properly released yet, let alone time-tested?
Or someone who's following way too many "industry influencers" (with no technical knowledge) on different platforms and sharing their ideas and takes almost blindly without even asking questions? That's who I call a Popstar Developer.
For the record, “vibe coders” don't fall into this category, because vibe coders simply aren't developers or engineers.
Change my mind!
Another classic example: developers who instantly jump on social media or record a video the moment a new framework drops, claiming it's "10x faster", "10x more efficient", and "the future of everything..." or, sometimes, dramatically declaring the opposite. And I'm always like: "How did you even have time to research or use it in practice so deeply to be so confident about that?”
What Goes Into Understanding a New Technology
A lot actually and no matter how much you test-drive it, real validation only comes with time.
Let's say some new "X" has just been released. This X can be anything, including but not limited to:
- A new programming language
- A new framework
- A new LLM model
- A new library
...or even a new version of any of the above.
Before jumping to conclusions (or straight onto the hype train 🚂), try asking yourself a few essential “WH” questions first:
- When was it released?
- What new features does this X bring?
- Who developed it? (Can be a company or an individual)
- What about potential security vulnerabilities?
- What dependencies does it introduce?
- How does it actually perform in real-world metrics?
- What problem is it trying to solve in general?
- What problem can it solve for me specifically?
- What alternatives exist, and how do they compare?
- Why is this tool supposedly better than what I'm using now?
- How can I simulate a realistic, production-level use case?
- Is it backwards-compatible to my current version?
There are plenty more questions you could ask, but this is a solid starting point, enough to separate genuine innovation from temporary hype.
As a professional, your goal is to deliver products that are high-quality, fast, and reliable, not to constantly jump between languages, frameworks, or even versions. In the real world, stability matters.
Same Applies to LLMs and Their Versions
The other day, I had to quickly build a visual component for one of my personal projects. I'm a backend engineer, so whenever I need to create complex markup, I sometimes have to rely on a bit of AI assistance (otherwise, it could take me days, if not weeks).
I won't name the specific LLM I was using, because it's not really about the model itself, it just happened to struggle in this one scenario. There were two different versions available, one newer and supposedly better, at least on paper. I decided to go with the older one.
Then I ran into a tricky styling issue: making a component responsive and mobile-friendly across different screen sizes. Sounds simple, right? Nope. It turned into a complete nightmare, even for the LLM.
I went several rounds with this LLM trying to make it work, but nothing clicked. Then it hit me, there was that other, supposedly better version I could've used. So I switched over and fed it all the context I had.
Sadly, still nothing. The results were no better than before. In the end, I did manage to get a working solution, but only after what felt like an endless back-and-forth with the model.
The point I want to make is simple: a new version or a new product doesn't inherently mean it's better. In fact, its newness can often be the main reason it comes with hidden drawbacks. Whenever I try anything new, I approach it cautiously — checking security, resource usage, correctness, and everything else that could impact my product negatively.
When Does It Actually Make Sense to Go All In on New Tech?
Sometimes, you don't even have a choice, a change is necessary. There are several scenarios where adopting new technology or upgrading a version makes sense:
Your company's tech stack is phasing out the old technology or version.
You need to upgrade because the previous version is no longer supported or is approaching its end-of-support deadline.
You've thoroughly researched the new tech or version and are confident it will improve your application's performance.
The new version enhances the security of your products.
You plan to add features that aren't supported by the old version.
...and plenty of other valid reasons.
Be Extra Cautious When Your Decision Might Affect Others
When you're a one-person team, the impact of a decision mostly affects only you. But if you're a technical manager, architect, principal engineer, engineering manager, or anyone responsible for a team (or multiple teams), you need to be extra thorough when evaluating any new shiny technology you want to introduce.
In enterprises or even mid-sized companies there's usually a process for adopting new tech, don't take it at face value. Review that process carefully, understand how it works, and look for ways to improve it. That way, you can make informed decisions that benefit your team and other teams, while minimizing risk.
Make Sure You Pick Tech for Long-Term Use
We've already covered several important criteria for deciding whether a new technology or version is worth adopting. But here's one more that often gets overlooked, especially by Popstar Engineers.
At some point, things should become boring and routine. Sounds counterintuitive, right? But it's true. Constantly switching frameworks, libraries, versions, or dependencies means you're not focusing on the product itself, or on selecting the right components for your project in the first place.
Even updating a minor version of a library or framework can trigger a cascade of changes in your code. And even if you implement everything correctly, you could still end up with 50+ bugs in production. Fun times, right?
You Don't Have to Pick Sides, Don't Label Yourself
This was also covered in the previous article when we discussed why being entirely old-school can be limiting, and it wouldn't feel right to leave it out here.
For some strange reason, people are obsessed with the idea that they should pick sides in literally everything, which is really strange. It's like they want to label themselves for no reason. I think that's because they want to build a personality they think is cool, one that might be based on someone they know or an imaginary person they're obsessed with becoming. And it's not only in tech. Let me give you a few examples:
- Rock music vs. Pop music - you might be a huge rock fan (just like I am) but you can't convince me that you haven't lip-synced and chair danced to a pop song while being alone, nobody watching (I have). It really depends on a particular song, not the genre.
- Ford vs. Chevy - while I'm a massive Ford fan (and owner), I appreciate quite a few Chevy cars that are out there. They're fun, cool, and do the job. It really depends on a particular model, not the brand.
Now a few examples from tech:
- Backend vs. Frontend - why not both, depending on preferences, what you need currently, what you want to build and tons of other factors?
- Microservices vs. Monolith - how about you tell me what you're building first and then we discuss. Though some people consider a monolith as an anti-pattern. Guess what? Microservices can be an anti-pattern in equally many cases (if not more).
See? The same principle applies here. Which brings us to the final and logical conclusion.
Conclusion
You don't become a good software engineer by typing fast, drinking too much coffee, having a flashy editor or terminal theme, driving an electric vehicle, or sharing memes. Those are all just gimmicks.
Similarly, you don't become a "rockstar" or a "10X" engineer by constantly chasing every new shiny thing that comes out, you simply can't keep up with it all, whether it's a new LLM model, a JavaScript framework, or the latest VS Code release notes. What really matters is creating products, living them, diving deep into technical nuances, and finishing them. You can always update your tech stack or dependencies, but can you actually finish the project? That's the real question.
What makes a good software engineer is flexibility and adaptability. Religiously following just one approach will only take you so far. To make meaningful progress in a project, or in your career, you need to be adaptive. Not by switching technologies every other day, but by developing situational awareness: knowing when it's better to stick with the tried-and-true, and when it's the right moment to embrace something new.
Top comments (0)