I wrote my first line of .NET code in 2003. It was version 1.1, back when the framework still had that new-car smell and IntelliSense felt like magic. I was working at a custom software shop straight out of college, and after dabbling in J2EE and PHP, .NET just clicked. Web Forms, in particular, felt familiar and intuitive to me as someone who’d cut their teeth on WinForms. It let me think in terms of controls, events, and state – concepts I already understood. I was hooked.

Back then, the world of .NET was cohesive, even cozy. You picked a language (I went with VB.NET, which still has a warm place in my heart), built an ASP.NET Web Forms site, compiled, and deployed. Repeat. It was the era of postbacks, ViewState, and code-behind files. Honestly, UpdatePanels were still two years away. Some claimed otherwise, but in truth, if you understood it, it worked.

But time has a funny way of sneaking up on you.

A few years and two jobs later, I landed at another consultancy. The vibe there was different. The priority was stability, not innovation. You didn’t chase the new hotness. You shipped the code, and as long as the app kept running, you left it alone. I understand the intent: predictability matters when clients just want the system to work. But looking back, that mindset had a cost.

By the time I blinked, a bit over a decade had passed. My two kids were older, a mortgage and two cars ensured I kept a stable job, and there I was with a head full of VB.NET Web Forms.

But the world had moved on.

MVC had risen. Razor was replacing it. WebForms was all but deprecated. Blazor was just on the horizon. Even VB.NET itself was under the axe. And there I was, still writing event-driven forms in 2015 like it was 2006.

It’s a terrifying realization: to wake up and not recognize the landscape you’ve been standing in all along.

This is the risk in our line of work. Tech doesn’t stay still, and neither can we. Development isn’t a career of long-term success stories anymore. Everything has an expiration date, from frameworks to libraries to programming languages themselves. Technology rots faster now. Security standards evolve, browser support changes, and deployment strategies that worked last year may be liabilities today.

And if we, as developers or consultants, don’t keep up? We become the liability.

I still love VB.NET and Web Forms. If I’m in a crunch and need to get a line-of-business app out the door by tomorrow, I’ll reach for them. They’re fast, familiar, and capable. But I no longer pretend they’re the future. They’re a survival tool, not a growth strategy.

These days, I know the stacks. I know what belongs where. I understand how .NET Core changed the game, how dependency injection became table stakes, how Razor Pages offered a leaner alternative, and how Blazor now lets us write C# from front to back. The same applies to PHP and Laravel. To Vue, to Next.js, to Supabase. Each with thier quirks, but each part ofa braoder fluency I’ve worked to rebuild. I may not be a specialist in every layer the way that I used to be in WebForms, but I know enough to architect, to mentor, and to spot the pitfalls before they happen.

If I could go back, I wouldn’t tell younger me to abandon stability. But I would tell him to carve out time for learning. To play with the new stack after hours. To build throwaway projects in MVC, then in Core, then in Razor. Because the gap between “I’ll learn it later” and “I’m completely out of date” is frighteningly short.

In the end, change in this industry isn’t optional. It’s the job. The tools shift. The patterns evolve. And if you don’t evolve with them, the world will move on without you.

I nearly missed the turn. I’m grateful I didn’t.

.NET Core isn’t just another shiny thing. It’s a reminder that the ecosystem is still growing. That software development isn’t done evolving. That we aren’t done evolving. A sign that we still have places to go.

And that it’s never too late to start learning again.