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. 👏👏👏

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.

Alright, congratulations sir, that thing just broke my mind 😄 In a good way though. I've never ever seen anything like that.🤔

Nice writeup, the Actix example is easy to follow end to end, and I like that the HTML stays plain HTML.

One thing I'd be curious about: the place criteria are passed as strings ("<td>*?t>:19\\<td>*?t<:20"), so a typo still compiles and only shows up at runtime. Is a more typed builder API on the roadmap for the Rust crate, or is the string form intentional to keep parity with the other language implementations?

Would also love to see an example where the server is doing something it uniquely can, validation or permission-based UI, since that's where this model seems strongest.

Well-structured post. Letting each problem motivate the next piece, volatility, then write ordering, then record framing, then partial writes, then corruption, then fsync makes the design feel inevitable rather than arbitrary. That's hard to pull off in a storage-engine writeup.

Two things it got me thinking about:

The write-order section is the cache-aside ordering rule almost word for word, and the reasoning transfers cleanly: durable store first, cache second, because a stale cache is recoverable while an acknowledged write that doesn't exist isn't. Nice to see the same argument show up a layer down.

On the duplication, I assume Part 2 handles it through LSM compaction, but my first instinct was a periodic garbage collector over the log. The catch is that it can't delete in place, since punching holes in the file puts you straight back into random I/O. So you'd roll the log into segments, rewrite frozen ones into fresh files keeping only the latest value per key, then swap and drop the originals, with tombstones so deletes survive the rewrite. Curious which way SaarDB goes.

Looking forward to Part 2.

U.S. Business Partnership Opportunity

We’re a Japan-based software development team looking to build a long-term partnership with a reliable U.S.-based professional.

Our team handles the technical side—from development and testing to project delivery. We’re looking for a U.S. partner who can help with client communication, business coordination, and developing new opportunities in the U.S. market.

This is a revenue-sharing partnership, not a traditional employment position. Partners can receive 30–35% of the agreed revenue/profit share, depending on the project and responsibilities.

If you’re interested in technology, freelancing, or building a side business and would like to learn more, send me a DM. I can provide the details, expectations, and example project structure.

ThomasWilson881992 @ 0utl00k dot com

I loved this article from the first few sentences. Why? You mentioned rainy, cold days, those are my favourite. That's when I feel most alive. Not many people understand that about me, but there it is.

I've never been to France, though.

I went to Germany recently for the second time, and I've had my share of the work-to-travel switch. Here's my story:

I had a flight in a few hours, so I decided to spend one of those precious hours recording a new video about a bug I found in my game and how I fixed it, alongside the article I had written.

I really, really, REALLY wanted to get it done before taking off.

So I recorded 20 minutes of video and started packing up to make sure that was done:

"Perfect. I'll edit and upload this once I'm done packing."

Oh boy... Little did I know...
I finished packing, sat back down at my PC, opened the recording...
No sound.

Turned the volume all the way up.
Still watching myself blab away without hearing a single word of my blabbing.

"Oh no, no, no!"

For some reason, my audio settings had changed and OBS Studio had decided that my microphone was no longer invited to the party.

Twenty (20) minutes of beautifully recorded content.
Absolutely.
⬇️ 
Completely.
⬇️ 
Utterly.
⬇️ 
Totally.
⬇️ 
Entirely.
⬇️ 
Useless.

That's a lot of work to go to waste.

"Giorgi you idiot!"
I was fuming.

Welp, that was my next challenge to fix that.
At that point, I had two options:
1. Accept defeat
2. Record the entire thing again

The odds of option 2 were pretty low, but it still worth a shot.

Now I was seriously short on time. The airport wasn't going to wait for me to finish uploading a video.

Somehow, I still managed to record everything again, edit it, upload it, and get ready in time.

Now what was the hardest part?
Pretending everything was totally fine, while talking in the video.

Meanwhile, internally:
"WHY TF DID I NOT CHECK THE AUDIO?!"
"WHAT TIME IS IT?!"
"HOLY S..., I'M DEFINITELY GONNA MISS THAT PLANE!"

But hey, that's life. Not every day is a perfectly executed 10/10 productivity story. Sometimes you just forget to check your microphone.

I agree completely about thinking differently once you're out of your routine. You start thinking about things that give you that small joy of discovering something inside your own head. It's like leaving your usual noisy route and taking the backroads, where everything is quieter and better. Especially for people like us, who are more or less always working.

By the way, I didn't know that book you were reading. Noting it down.

I also walk like a maniac. On my last trip I averaged well over 150,000 steps in total, I just love walking that much.

And sorry about your loss. Coming home to a meow-free house must be hard.

You're right that the building never stops. Our brains are remarkable at figuring things out on their own and adapting to whatever they're dropped into. San Francisco to Paris would be a bigger jump than my trip was I'm in Europe anyways, so Germany is a three or four hour flight, barely a change of scenery by comparison.

California to France is different in weather, culture, food, everything. I lived in California for a few months, so I know how wide that gap is, and I think it's wider in your direction than mine. In Europe, American culture is already everywhere and everyone speaks English, so arriving there from Europe isn't much of a shock, also (I would say that California and the US in general has much better vibes than Europe). Going the other way is definitely a huge jump, and that's exactly the kind of jolt that makes you see things differently, that's why it was so inpiring to you.

This is one of the best articles I've read in a while!👏

The three-layer split is the useful part here, and it generalizes well past routing, the rule nobody wrote down is the same failure mode in any rules-driven system.

The case I'd focus on is the third one: a primitive exists but the mapping isn't obvious, so the developer builds a workaround outside the model. That one reads as a documentation problem rather than an expressivity problem. A cookbook mapping named business rules to primitive compositions would close more of the gap than more primitives would, and it's a lot cheaper to ship.

Solid tutorial. The pacing works well, you build the program up piece by piece instead of dropping a finished file on the reader, and the short asides explaining macros and error codes fit naturally without derailing the flow. The UUID section I think is the highlight.

The one thing I'd add is a bit on what happens after the phone disconnects, since that's usually where a first BLE project stops behaving as expected.

This absolutely deserves much more views and reactions.

Really enjoyed this write-up. The metaphor does real work instead of just sitting in the title, and "retries are only cheap on the invoice" is the part that'll stick with me. Everyone argues price per generation and nobody counts the human judgment stacked on top, which is the one thing you can't parallelize.

One thing to clarify

You say early on that better prompts improve your odds. But if prompting moves the odds, the pulls aren't really independent and that's the part the title rests on. Feels like there's a soft pity system in there after all.

Thanks for sharing!👏

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

{%embed dev.to %}

It gives a better visual appeal.

Solid approach, sending a link instead of an attachment and writing the file row by row is the right way to handle this.

One thing worth mentioning: on MySQL, PDO buffers the whole result set by default, so you'll want to turn that off or the memory savings don't materialize.

Really interesting read, and deep enough that I had to go and research a few concepts to follow it properly. I came in knowing roughly what WebRTC was for and not much beyond that, so trio, SCTP framing and the whole certhash mechanism were all new territory for me. Worth the detour, it's rare to find a write-up that assumes you'll do that work and rewards it.

Also appreciated the honesty about scope. Keeping #546 open and saying plainly that this advances the issue without satisfying it is rarer than it should be.

Great write-up, preserving the trade-offs as they actually came up in review, instead of the tidy past-tense version, is what makes it worth the reading effort. 🫡

I’m definitely gonna read all of them, no matter how much time it takes.

It’s a slow process, but it’s really fun at the same time.😄

I’ll get to your post as soon as I can🙏

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

{%embed dev.to %}

It gives a better visual appeal.

Extremely interesting read, especially for someone who's going to need neat designs for a few upcoming projects. My background is in back-end engineering, which doesn't help much when it comes to judging which design fits which project, that's one skill I really need to get good at.

I've built plenty of side projects, but I still don't have a portfolio website. Part of the reason is that I want it to be really, really good, so I never manage to start at all. I think I need to change that, just start somewhere and figure the rest out later.

The title also made me think the clients had figured out the work was done with AI help and disliked it for that reason. Glad it turned out to be the other way around.

And this quote, "Fast generation is useful. Blind acceptance isn't, is an absolute gem.

Great read, and really useful for future me. I'll pull this article back up when I get to the "decide what tool to use" step. I'm sure it'll make the decision faster.

Thanks a lot for sharing! 🙏

Nice concept, I really like the idea. Well done!👏

This is a really interesting and seemingly fun project. Keep it maintained!
By the way, congrats on already 77 stars!⭐️

This is so important to keep in mind. I've been there too and it's painful to see the preview of your project doing funny things in different websites/apps.

Thanks for the practical guide.🙏

Fun read, and a good use of the algorithm as a vehicle for explaining Haskell syntax rather than the other way round.

Coming from C#, the same shape falls out of LINQ almost unchanged:

static IEnumerable<T> Qs<T>(IReadOnlyList<T> xs) where T : IComparable<T> =>
    xs.Count == 0
        ? Enumerable.Empty<T>()
        : Qs(xs.Skip(1).Where(a => a.CompareTo(xs[0]) <= 0).ToList())
            .Append(xs[0])
            .Concat(Qs(xs.Skip(1).Where(a => a.CompareTo(xs[0]) > 0).ToList()));