.png)
3 months ago
4
Should you do it ?
Press enter or click to view image in full size
As a software engineer, a significant part of your work involves interacting with legacy systems. And with legacy systems, software modernization is inevitable 🙂.
Software modernization refers to the conversion, rewriting, or porting of a legacy system to modern computer programming languages, architectures (e.g., microservices), software libraries, protocols, or hardware platforms — Wikipedia
When I’m faced with a modernization project, I often ask myself three questions:
- What can I learn from this?
- What is the business value?
- Should I actually do it?
These questions matter because software modernization projects are uniquely challenging. You’re dealing with years of accumulated complexity, unknown unknowns, and undocumented dependencies.
In this post, I want to share some reflections on migration projects and the lessons I’ve learned along the way.
Throughout my career, I’ve worked on complex dependency upgrades, adopted new CI/CD pipelines, and led cloud-to-cloud migrations — each project offering unique challenges that taught me valuable lessons in software engineering.
Complex dependency upgrades taught me that technical details matter — especially when you’re not familiar with the dependency. I read the dependency documentation thoroughly multiple times, drew dependency diagrams, searched for solutions, validated assumptions, and shared the solution design with the team. Eventually, I became the go-to person for this area.
Cloud-to-cloud migrations taught me the importance of seeking feedback early and often. However, getting feedback is only half the battle, developing better communication skills to truly understand their feedback, and then thinking critically about whether it makes sense. Through this process, you often discover better solutions that are simpler and more effective than your initial approach.
New CI/CD pipeline adoption taught me that getting adoption is more important than building the perfect system.If there’s no adoption after a long time, something is fundamentally wrong with your solution.
So just do it. You’ll gain broad, invaluable experience simply by doing it — and this broad experience is crucial for career advancement. But why is broad experience so valuable?
I was just six months into my first full-time job after college when I went on my first business trip with my manager. He was a seasoned tech veteran — someone who had worked at big companies and even served as a startup CTO. There’s one thing he said on that trip that I still think about today.
“Breadth or depth — which is more important?” I asked.
“Breadth, of course. No doubt,” he replied.
Press enter or click to view image in full size
That idea stayed with me, and I later came across a blog that explains it well: breadth gives us perspective, and thus wisdom¹.
Wisdom grows from leading diverse technical projects and facing varied challenges — it helps you understand the true complexity of what you’re building. With that foundation, you can make better estimations, manage deadline pressures more effectively, and anticipate problems others might miss.
Wisdom isn’t just about mastering technical challenges — it also involves understanding human nature and recognizing different personalities. Working on varied technical projects means collaborating with different people — from product managers to infrastructure teams to external vendors.
And often, the hardest part isn’t the code — it’s persuading others. This exposure sharpens your communication, strengthens your ability to influence, and helps you build consensus around your ideas.
So should you take on that modernization project ?
If you’re early in your career, the answer is almost always yes — the experience is invaluable. But as you gain more experience, the answer shifts to: it depends. In the next post, I’ll share a few reasons why you might want to think twice before taking one on.
Part two is here
