We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events.
In this post, I’ll explain what secondary domain events are, and how they impact the design.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In the final part, we examine how LLMs affect testing and conclude the series.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this part, we look at how to make manual testing easier and why it matters.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this post, we look at what we can do to recover well even if a defect finds its way into production.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this part: What would you do if you weren’t allowed to write automated tests? Take a moment and think about what you would do to still deliver quality software if you weren’t allowed to write automated tests. I...
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
When I open my social media feeds, it is obvious: the age of writing code with our fingers is ending. LLMs and agents can write code much faster.
But was it ever about the speed of source code creation? Was writing code only translating requirements into something the computer can understand?
I think not.
While I generate code with LLMs and agents, creating a piece of code by hand has its benefits. So, this is an ode to “slowly” handcrafted code.
One of the great features of .NET is that you can mix its programming languages (C#, F#, VB.NET) in a single solution and that assemblies written in one language can call assemblies written in other languages. This is great, especially when starting with F#. A team does not need to switch everything at once, but can keep using the existing C# code and use Interop to call C# from F# or vice versa.In this article, we take a look at the Interop story in 2026. Spoilers: it works great.
In our product, I sometimes encounter the problem of dynamic IN-lists in SQL. First, they appear harmless, but soon they lead to an unnecessary amount of query plans. In this blog post I share how to circumvent those issues with TVP. A clean, performant and reusable way to solve this problem!
Not having to annotate types for every argument and return value in F# is a big relief. In this blog post, I share some tips and tricks to reduce the need for type annotations.