Show Me the Article You're Most Proud Of And I'll Read Every Single One of Them

I think I remember this one, let me check again 👀

I gotta tell you, if I'd had something like this when I first joined the community, I'd have been a lot more active from day one. Great work @francistrdev !

Definitely a must-read for anyone new! @plaidscientist This 1 is good to read and get a feel of things!

What a great post, seriously! And you know what? I'm a .NET developer. C# has been my primary language for 10 years now.

Would I pick a different language or framework if I could go back 10 years?

Absolutely NOT!

.NET is so beautifully crafted, and I feel sorry for people who still think C# is an ugly Java rip-off that only runs on Windows. Come on, guys, what year is this? .NET is fully cross-platform and packed with so many great features that even I get overwhelmed sometimes.

Sure, it has its downsides, especially for people coming from other language backgrounds, but so does every language.

As for popularity, it's still doing well. Check the Stack Overflow Developer Surveys, and you'll see C# consistently among the top languages. Honestly, though, even if it weren't popular, it wouldn't change much for me. As long as there are enough jobs out there, you only need one.

And with .NET, you can build pretty much anything:

Web apps? - Suit yourself.
Desktop apps? - Absolutely.
Games? - Hell yeah.
Mobile apps? - No problemo.
Back-end services? - For sure.

Learn one language, and you can build almost anything. Tell me that's not cool!

I'm actually planning to write a separate article on this topic, but a few others are already waiting in the queue, so it'll have to wait its turn.

Thanks for sharing this amazing write-up!

You can embed your Dev.to articles in Dev.to using

{%embed dev.to %}

It gives a better visual appeal.

This is an amazing read.

I feel I do not belong there, but it is too late, with some fierce courage I had sent my request to talk months ago and to my surprise it was accepted. Now I am there, just minutes before the talk, thrilled...

See? That's the key quote in this article. You don't know what's behind the door until you step inside. I admire anyone who has courage to stick around where they "don't belong" only to find out they don't just belong there, even more - it's their natural habitat.

I hope you'll achieve the rest of your goals soon. 🔥

Oh my goodness, and I thought I was someone who loved writing huge articles. I’m gonna need to take a full day-off just to read this😂

Just kidding, the weekend is coming up soon and I’ll have time to go through this monstrosity.😄

You might not believe me, but I just finished reading. A promise is a promise, I need to live up to it. 😄

Coming at this from a back-end background, my accessibility strategy up to now has mostly been trusting that whoever writes the frontend knows what they're doing. Turns out that's not a strategy, it's a prayer.

What I appreciate most is that this isn't written as a compliance checklist. Every point explains who it actually helps and why.

Great read, and structured exactly right for the length, I'll be coming back from time to time to it a section, rather than trying to absorb it in one go.

Thanks for putting the hours in!

I've never seen an article with a read time of over an hour 😄
And to be honest, it took me well past 68 minutes. Closer to 100 by my calculations.

Coming at this from the .NET side, and it's interesting how differently the same principle gets taught depending on the ecosystem. When someone says "inversion of control" to a C# developer, nine times out of ten they mean constructor injection and a container. Something else decides which implementation gets handed in. What you're describing inverts something bigger: who decides what happens next. Same principle, much wider scope.

The open/closed section is where it clicked for me. Translated into my world, a plug is basically registering another handler into a collection the dispatcher already iterates over, and "intercept at a higher priority" is a decorator wrapping the existing implementation and choosing whether to call inner at all. I've written both plenty of times without ever thinking of them as the same idea wearing different clothes.

One difference I keep coming back to: your plugs become active because a module was imported, so the wiring is implicit. In .NET the composition root is explicit, open Program.cs and the whole graph is right there. Better traceability, but slightly worse on the "code written years later plugs in with no changes" promise, because someone still has to add the registration. Assembly scanning gets most of the way there and brings back the same "where did this come from?" question.

I also appreciated that you didn't force Liskov. Most SOLID articles try to make all five fit perfectly, so admitting one is a stretch because IoC favours composition actually made me trust the rest more.

The per-client customisation point is the practical part I'm taking away: whether a feature exists comes down to whether the module is loaded, instead of a flag threaded through the component that has to know about every variation. That's a much cleaner answer than what I usually end up with.

Great read! Nice game BTW! 🎮️🕹️

This piece of writing is seriously impressive both in terms of storytelling and technical explanation.

Right from the start of the article, I was so intrigued to know what was the actual problem causing that stubborn, red text that wouldn't go away.

That really reminded me one of those all nighters of mine. I'd spent the whole evening, night, and morning debugging one silly problem. I can't express the level of happiness I had when I finally found it.

Our job is tough, but it's also so rewarding!

Great job! 👏

Such a great read, especially for someone like me, a .NET engineer. Interfaces are a huge deal in .NET, maybe even bigger than in Java.

The multiple inheritance argument never really applies to interfaces, because a class doesn't inherit from an interface, it implements the interface, and the difference between inheriting and implementing is absolutely gigantic. That's the key distinction, and it's no wonder it confused you back then.

I had a similar moment myself. At university we were taught mostly C++, which doesn't really have the interface notion, sure, you can use abstract classes, but an interface is still a completely different thing. So when I started as a junior engineer I had to learn C# pretty much from scratch. Three or four months in, I still didn't understand why we needed interfaces at all. Everything can be done with plain classes, right?! Like give me any task and I'll get it done without a single interface. But I was just following the patterns that were already in the projects at work. And to be fair, even the video tutorials never really showed why those damn interfaces mattered. They'd say "you should use interfaces because loose coupling is good." Sure, I believe you, but WHY IS THAT GOOD? I was so frustrated.

With enough practice it eventually clicked. Funnily enough, I'd even noted down a similar article to write myself, just to make other people's lives easier, but I'm glad you got there first, so anyone who's stuck can get unstuck without waiting on me to finally find the time.

Worth adding: multiple inheritance isn't allowed in .NET either, though it is in C++. I used to write code at university with inheritance so tangled that I had to draw diagrams to follow it. Back then I thought I was a genius. Little did I know I was just a clueless kid who hadn't learned that simple code and simple structure are what actually make you a senior engineer.

Inheritance itself isn't the best concept. It can really mess with future you if it's not done right, and the more complex your hierarchies get, the more chances there are to mess things up.

By the way, the "Badass Prince" badge cracked me up. 😄 But in all seriousness, that description is SO GOOD, I can't even believe it.

Absolutely fantastic read, thanks!👏

@unitbuilds A bare-metal, self-healing OS is a really creative goal. I love it, especially as a teenager I always wanted to build my own operating system, started learning low-level languages, and then reality hit. 😄 Maybe I'll come back to it one day.

The part about Kimi optimizing for correctness against the spec is the most interesting thing here. It's a good illustration of how much the unstated context matters with these models and how specific you have to be about the environment the code is actually going to run in.

The scanner idea is pretty neat, it reminds me of NoteRunway, another hackathon winning app that I created. One of the features of it was detecting sensitive data that people had written into notes "temporarily". But my approach was kinda the reverse of what's written here. Regex ran first as the deterministic pass, and then, optionally, an AI scan on top to catch what patterns couldn't.

One thing worth flagging: in edge cases that self-correction loop could get expensive. The mechanics of this really resembles to agentic loops that keep cycling until it verifies it hit the goal, which is notoriously costly. Different use case and a much smaller scale here, but the mechanics rhyme.

@pascal_cescato_692b7a8a20 great project from what I've read so far. I'm glad there are still people who do such low-level work, with proper AI usage. 👏👏👏

Oh wow, this one looks really deep and complex, I'm gonna take my time to read and analyze this. I'll get back to you in about a day or two 😄

Totally agree! Likes only tell part of the story, since so much depends on timing, the audience and sometimes luck. My most-liked article definitely isn't my favorite. The ones I treasure most are the ones tied to special memories. When a piece carries a moment like that, it becomes special in its own way, no matter the numbers.

By the way, I'd love to read your favorite. Would you share it?

Oh, I remember this one, I even commented on this post.

I like how you picked an article titled "The Most Painful Career Lesson My Best Job Taught Me" as your favorite.

That just shows me that you not trying to forget bad experiences, you embrace them. Trust me, not everyone can do that. I used to be pretty bad at that.

But as you gain more experience, you realize there's no such thing as a "bad experience" in a career. Bad experiences teach you far more valuable lessons than good ones do.