Is There an ROI on Learning C#?

Dev Leader Weekly 132

Dev Leader

Mar 23, 2026

TL; DR:

Foundations beat language-specific trivia every time
AI lets you build without knowing a language -- until you get stuck
Yes, learn C# -- but learn the why, not just the how
Sorry, no live stream! I will be busy on-call this week for work.

The ROI on Learning C# (It’s Not What You Think)

I had a great question come in on one of my Code Commute videos: do I think there’s an ROI on learning C#?

The short answer is yes. But the reason might surprise you -- because honestly, the reason has almost nothing to do with C#.

You can check out my full thoughts on this in the video below:

My Obvious Bias (and Why I’m Acknowledging It)

Full transparency: I’m a C# developer. I’ve been working with C# for as long as I can remember -- since my first year of university. The vast majority of my technical content is C# and .NET. So yes, I have an obvious bias here.

But I want to be really clear about something. I’m not a zealot. I don’t think C# is the best language ever created. I like using it because it works really well for me in basically every situation I’ve found myself in. That doesn’t mean it’s objectively superior to anything else. I don’t think “best language” is even a meaningful concept.

So when I say yes, learn C# -- I’m not saying it because I think you should worship at the altar of C#. I’m saying it for a different reason entirely.

The Real Reason: Foundational Knowledge Transfers Everywhere

Here’s my actual argument: the reason learning C# has ROI has nothing to do with C# specifically.

What I mean is this: If you invest your mental energy into deeply understanding things at a foundational level...

how garbage collection works as a concept
what it means for a language to be managed
what design patterns exist and why
how different types of systems handle memory and concurrency

... that knowledge transfers everywhere. It helps you make better decisions regardless of what language or framework you’re working in.

The trap I see people fall into is treating programming languages like trivia. Like, how well do you know the very specific edge cases of this very specific API in this very specific runtime? I’ve seen “C# interview questions” that I genuinely had to look up answers to, despite having written C# for most of my career. And that tells you something. That trivia-level knowledge has always had diminishing returns.

Compare it to cars. I don’t need to know the exact inner workings of every component in the specific model I drive. But it’s genuinely useful for me to understand what a turbocharged engine means in practice, why different oil viscosities exist, what the difference between a V4 and a V8 actually translates to in real-world performance. That conceptual understanding helps me make decisions. The hyper-specific trivia about a particular vehicle? Much lower ROI.

Software engineering is the same. Understanding patterns like the Singleton pattern or the Strategy pattern isn’t about C# syntax. It’s about learning a vocabulary and a set of solutions to recurring problems -- one that applies no matter what language you’re writing in next year.

Where AI Changes the Equation

With how much AI is reshaping how we build software, I think deep language-specific knowledge is becoming less relatively valuable -- and foundational knowledge is becoming more valuable.

Here’s a concrete example from my own experience. I wanted to build a small MCP server -- literally just a convenience wrapper around an existing API. My goal was that if anyone else wanted to use it, they could download it without any setup friction. No runtime to install, no build steps to fumble through.

I was chatting with GitHub Copilot about it, and it suggested I could build it in Go and ship it as a self-contained binary. It also offered the option of a self-contained .NET executable. So I said: do both.

The result was an MCP server implemented in both Go and C# that parallel each other in features. And I have never in my life read a line of Go code. Not a flex -- it’s a demonstration. I did not need to know Go to ship a working Go program. The AI handled the implementation details. I handled the intent, the architecture decisions, the debugging when things weren’t right.

If you want to explore building your own AI-powered tooling, I’ve been writing a lot about the GitHub Copilot SDK on the blog lately, including building an AI CLI developer tool that’s a great starting point.

But Foundations Are Why I Didn’t Get Stuck

Here’s the nuance though. I could build in Go without knowing Go -- because I have a solid software engineering foundation.

When I hit a question like “do I need compile-time dependencies or runtime dependencies for this?” I could ask that question in a meaningful way. I understood what compile time means, what a runtime is, what the difference implies. Those aren’t Go-specific concepts. They’re foundational. And having them let me ask Copilot the right questions to unblock myself quickly.

Without that foundation, you could still make progress. You could paste errors into an LLM and say “it’s not working” over and over. You would eventually get somewhere. But the effectiveness -- the ROI, since that’s what we’re talking about -- drops significantly.

Actionable Tip: When you’re learning a new language or framework, actively ask yourself: “What is the general principle behind this? Where else have I seen this pattern?” That habit compounds over time more than any amount of syntax memorization.

There Are Still Cases Where Deep Knowledge Matters

I don’t want to wave away deep expertise entirely. There are absolutely situations where it matters enormously.

One of my teams is working on a hyperscale caching system. The performance requirements are extreme. And in that context, not having deep knowledge of how C# and the .NET runtime work at a granular level means you can’t get to the optimizations needed. The stakes are high enough that the hyper-specific knowledge becomes genuinely worth the investment.

But the engineer working on this didn’t arrive with 40 years of deep .NET internals knowledge. They’re a strong engineer with solid fundamentals who is going deep because the situation demands it. The foundations got them there. The depth came as needed.

That’s the model I think works best: strong foundations that let you go deep when you need to, rather than going deep on specifics and hoping they transfer.

The Bigger Picture: AI is Opening Doors

One thing I genuinely love about the current moment in software development is that it’s lowering the barrier of entry. I’ve talked with product managers on my team who, when presented with the question “could you build a small web service using AI tools?”, would say yes -- even though they’d never considered themselves programmers.

That’s amazing. There’s no magic behind the curtain. Getting into software development is hard, and AI is making it more accessible without eliminating the hard parts that actually matter.

My only hope for people entering this way is that they stay curious. That as they start seeing things come together, they don’t just accept “it works” as the end of the inquiry. The developers who get really effective over time are the ones who keep asking why. What does this actually do? Why did the AI make this choice? What would happen if I changed this?

That curiosity is what turns AI-assisted output into actual expertise.

So -- Is There an ROI on Learning C#?

Yes. Absolutely.

But the ROI isn’t really in memorizing C#-specific trivia. It’s in building a mental model of software engineering through the lens of a real, production-grade language with real patterns and real tradeoffs. C# gives you garbage collection, async/await, strong typing, rich framework support, and a world-class ecosystem. Learning those things conceptually -- understanding what they mean and why they exist -- is where the value lives.

The specific syntax? The edge cases? Those you can look up. The understanding of why -- that’s what AI can’t fully replace yet, and what makes every other language and framework easier to pick up.

Learn C#. Learn it deeply enough to understand the fundamentals. Then take those fundamentals everywhere.

Dev Leader Weekly

Discussion about this post

Ready for more?