# After A Decade of Experience

I've had a lot of conversations with developers over the years. Mentoring sessions, Podcast sessions, late-night messages when someone's stuck on a bug, conversations after meetups that go longer than the meetup itself. A few things keep coming up, often enough that I think they're worth writing down properly instead of just repeating in passing.

The developers who grow fastest aren't usually the most naturally talented ones. They're the ones who ask why something works, not just how to make it work, and who have someone around willing to answer honestly instead of just fixing it for them. I learned this the hard way as a mentor too. Early on, when someone brought me a bug, I'd just look at the code and tell them the fix. It felt helpful in the moment. It taught them almost nothing. Now I ask what they've already tried and what they expected to happen instead. More often than not, they find the bug themselves halfway through explaining it to me, and they walk away having actually practiced debugging instead of watching me do it for them. If you're mentoring someone, that shift alone is worth making. If you're the one being mentored, ask for that kind of space instead of just the answer.

AI has changed how I work, and how almost every developer I talk to works. I'm not going to pretend otherwise. Writing a first version of something, generating tests, working through a rough draft of an implementation, all of that moves faster than it did a few years ago. But the developers who are actually thriving with these tools aren't the ones who've handed over their thinking. They're the ones who've gotten sharper at the parts AI still can't do for them. Knowing which approach actually fits the problem in front of you. Catching when a generated solution looks right but will quietly break under real load or edge cases. Being able to explain a tradeoff clearly to someone who isn't technical. AI has made it faster to produce code. It hasn't made it faster to develop judgment, and judgment is still what separates someone who ships working software from someone who ships software that survives contact with real users. If you're early in your career, that's the skill worth building deliberately, because it's the one that doesn't get replaced by a better model next year.

I get asked a lot whether .NET is still worth learning, usually by developers weighing it against something newer. I always give the same answer. The platforms that last aren't the ones that chase trends, they're the ones that keep solving real problems as those problems change. .NET has done that for two decades now, and it's still doing it. Minimal APIs made it easier to get started without giving up the maturity the platform is known for. Performance work has made it genuinely competitive in places it wasn't before. The newer tooling around cloud-native development is aimed at the unglamorous, everyday friction of running services locally and in production, which is exactly the kind of problem that actually matters once you're past the tutorial stage. A platform that keeps solving real problems tends to keep the developers who build on it.

If there's one thing I would want a developer earlier in their career to take from all of this, it's this: the mechanical part of writing code is getting easier and faster for everyone, so it stops being what makes you valuable. What doesn't get automated is knowing why you're building something a certain way, being able to teach that reasoning to someone else, and being honest about tradeoffs instead of hiding behind a tool's output. Build that, and you'll be fine no matter what changes next.