Having recently read the article “Why are Event Driven Systems Hard?”, and having worked on several event driven systems myself, I began to wonder why people so often frame these systems as inherently difficult. It’s true that event driven and distributed systems can be hard to work with… especially if approached without the right mindset or tooling, but that doesn’t mean they are hard by default.
In fact, many of the “hard parts” that architects and developers worry about such as eventual consistency, debugging asynchronous flows and ensuring reliability, are well understood and largely solved with modern practices. With the dotnet ecosystem (or any other mature ecosystem), frameworks, and observability platforms, implementing event driven systems has become far more approachable than it was even a few years ago. The gap between theory and practice has narrowed significantly, making these architectures not only manageable but often the most straightforward option for scaling, decoupling, and evolving complex applications.
If your computer doesn’t meet Microsoft’s system requirements for Windows 11, you may have seen the dreaded message: “This PC can’t run Windows 11.” The usual culprits are missing TPM 2.0, no Secure Boot, or an older CPU.
But here’s the good news: you can still upgrade Windows 10 to Windows 11 on unsupported hardware using a free tool called Rufus. This method avoids complicated registry edits and gives you a cleaner installation experience.
In this guide, I’ll show you step by step how to install Windows 11 on unsupported PCs using Rufus.
One of the first schema decisions you face when designing a database table is:
Should I use an INT or a UUID as the primary key?
Most developers default to an auto-incrementing integer. It’s simple, compact, and familiar. But UUIDs (a.k.a. GUIDs) are increasingly popular — and many of the old performance objections don’t hold up with modern hardware.
Let’s break this down like developers, not DB theorists.
Let’s get one thing straight. If you’ve been listening to the so-called “tech futurists” and clueless CEOs, you’ve probably been fed the same line: AI is going to replace every entry-level developer.
It’s a hot take for a podcast, a great headline for a tech bro’s newsletter, and an even better way to get a company’s stock price to jump. But it’s also a complete, unadulterated lie. And it’s time to call it out for what it is.
AI is not a replacement for junior developers. It’s not a silver bullet that eliminates the need for human talent. It’s a tool. It’s an assistant. Anyone who tells you otherwise either doesn’t understand software development or is trying to sell you something.
C#’s Garbage Collector is a powerful tool for automatic memory management, but it doesn’t solve every resource management problem. While it efficiently cleans up unreferenced managed objects, there are specific resources that require a more deterministic approach to ensure they are released promptly. This is where the using statement comes in.
Building APIs that handle large datasets can be a challenge. A common approach is to collect all the data into a list, convert it to JSON, and then send it all at once. But what happens when that dataset is massive? Your API might freeze up while it’s building the response, and you could end up with a huge memory footprint. Fortunately, ASP.NET Core provides a great solution for this problem: IAsyncEnumerable<T>.
Yes, I’m saying it, most unit tests feel like a waste of time.
You write loads of them. They break when you refactor. They rarely catch real bugs. When you change implementations, you delete the tests. And when your build fails, it’s usually because a mocked method didn’t behave as expected — not because your code actually broke.
So why do we keep writing them?
Because while most unit tests are a waste of time, some aren’t — and knowing the difference is what separates a codebase held together by guesswork from one that’s confidently shippable.
Ubuntu’s Snap packaging system was introduced with the promise of universal Linux applications, easy updates, and robust security through confinement. While these goals are admirable, the reality of Snap for many desktop users has been a source of frustration, leading to a growing sentiment that “Ubuntu Snap sucks.” This isn’t just a matter of preference; it’s rooted in several fundamental design choices that hobble user experience, resource efficiency, and even security.
Everybody has heard of the leetcode style interview tests, and given their prominence in the tech news recently, you won’t be surprised to find out that this is another story highlighting their inherent flaws.
Recently, after a remote interview on teams, I was given a set of 3 different leetcode style interview test questions. I was told to take “no more than 3 hours total” and to “write it using typescrypt”.
39 minutes later, I had completed and submitted all 3 tests, and all 3 tests pass all test cases. So now you ask, what’s the problem?
The headlines have been stark: tech giant after tech giant announcing significant layoffs. While the immediate impact on those made redundant is undeniable and deeply upsetting, the fallout from these decisions extends far beyond those who receive the dreaded news. The industry wide repercussions are creating a climate of increased pressure, stifled career movement, and potentially lower earning potential for a vast number of tech professionals.
Let’s unpack the less visible, yet equally significant, ways tech redundancies are impacting everyone else.