Maarten Balliauw

The through-line

Across everything there is one persistent preoccupation: the gap between a system as designed and a system as lived with. It shows up in the technical writing as an interest in the seams of .NET, the places where the framework makes something testable, explicit or hostable that previously was not [9][13][5], and it shows up just as sharply in the complaints about a car wash that now requires an account and an email confirmation before it will dispense virtual coins [4]. The same instinct runs through the argument that automated landing systems have limits and a pilot has to take over [12], through the observation that a document you cannot name is a document you cannot find [2], and through hard-won operational lessons from running a real service on Azure, including "learning moments from major downtime" [15].

The second constant is output. A steady rhythm of blog posts on .NET topics [3][5][9][13][14] sits alongside a novel that grew out of the same impulse: "Every developer has a side project. Mine became... writing a book" [11]. Whatever the medium, the pattern is the same, use the thing, learn where it breaks, then write it down.

On automation and where the human still has to steer

The clearest statement of position comes from a pilot overheard at an airport, who had flown three approaches through severe thunderstorms in a week and found "the automated landing systems weren’t cutting it in those conditions", so he took over manually [12]. The reading offered is immediate and professional: "Automation is great. But human intuition is irreplaceable" [12]. The software parallel is drawn explicitly, asking how often engineers "rely entirely on automated pipelines, rigid frameworks, or AI tools, only to realize a high-stakes 'edge case' requires us to step in and steer the ship manually" [12]. The question left open is deliberately provocative and not really open at all: "Is a professional who overrides the system a rebel, or the definition of a true expert?" [12].

The flip side is automation applied where nobody asked for it. The car wash that used to take a swipe card and coins now demands a QR scan, an app download, an account, an email confirmation, card details, two opt-outs, virtual coins, and a repositioning of the car, all summarised with flat sarcasm as "Automation is awesome!" [4]. The two posts are the same argument from opposite ends. Automation earns its place by removing work, and when the process is longer than what it replaced, or when conditions exceed what the system was built for, the human has to be in the loop.

On writing .NET down

The technical output is a running commentary on what the platform is doing now and what it changes for the person using it. Recent subjects include hosting the .NET Aspire Dashboard as a standalone container in Azure Web Apps [3], keyed services and named registrations in the .NET service provider [5], discriminated unions in C# and .NET 11, framed with the weary parenthetical "(for real this time)" [13], and an explainer on what IdentityServer is and, more to the point, "When Do You Need it?" [14]. The framing is consistent: not a feature announcement but a question about applicability, hosting it standalone, registering it by name, deciding whether you need it at all.

The strongest expression of the underlying value is the piece on TimeProvider, titled around "the End of Untestable DateTime.UtcNow" [9]. That is the whole preoccupation compressed into a headline. A static call to the clock is a hidden dependency, and the interesting part of a framework addition is that it hands control back to the developer writing the test. The same logic explains the attention to keyed registrations [5] and to discriminated unions [13], both of which make something previously implicit into something the compiler and the container can see.

On real-world architecture, not reference architecture

The Azure material is explicitly about what it is like in production rather than what the diagrams promise. MyGet, a NuGet package management service co-founded and run as a real business, gives developers private feeds for internal frameworks and packages, with user management, permissions, build services and symbol servers [15]. The architectural detail that matters is isolation, using multiple storage accounts per customer [15], and the account of the system includes architectural changes over time, experience with the Azure Access Control service, and "learning moments from major downtime" [15]. That last phrase sets the tone for everything else: the useful knowledge is the knowledge that came from something going wrong.

On infrastructure you cannot control

The frustration with dependencies extends past code. Business network stability has become the problem, mostly fine but with roughly three days a month of "onderhoud" carrying latency of several seconds, and the provider's own 4G backup ruled out because it does not support bridge mode [8]. The options considered are adding Starlink or arranging independent 4G/5G backup, with the leaning towards satellite described as "een trieste optie" for a region like Antwerp where communications were assumed to be well handled, and with fiber in Flanders described as gigantically behind and not an option locally [8]. There is also an honest correction attached: an earlier switch away from Orange turns out to have been misdirected, since the network was apparently the culprit [8]. The engineering conclusion is redundancy, and the willingness to name your own earlier misdiagnosis is part of the same habit.

On classification over filenames

A separate but related friction is the time lost "hunting for a document you know exists, but whose name completely escapes you", the file that ended up as Final_v2_updated(1).canvas or buried in a folder hierarchy "that made sense to someone three years ago" [2]. The proposed fix is structural rather than disciplinary: tag and classify internal files with standardized metadata and intuitive keywords, at which point "exact document titles no longer matter" [2]. The formulation is worth keeping: "Instead of relying on perfect memory, you rely on a system" [2], and searching broad logical tags returns the file in seconds regardless of what it is officially called [2]. It is the same move as making time injectable, replacing a fragile implicit dependency with an explicit, queryable one.

On the side project

The book is presented as a developer's side project that went somewhere unexpected: "Every developer has a side project. Mine became... writing a book" [11]. The Side Project is fiction, about a dev whose innocent youth football app gets hijacked by organized crime [10][11], and the announcement was followed by a longer written account of the writing process itself [7]. It is pitched without ceremony as holiday reading, beach, pool or mountains, available at digital stores [10]. The plot premise carries a familiar anxiety, a small well-meant piece of software acquiring consequences its author never designed for.

On being sold to

A dentist visit that opened with a ten-minute pitch for interdental brushes, delivered "like he had a monthly quota to hit", with no "how are you" and no "let’s check your gums", just "pure sales energy", prompted the question of "Since when do medical degrees require a minor in high-pressure sales?" and the flat refusal, "I don't want to sign up for those brushes as a subscription!" [6]. Read next to the car wash [4], it forms a consistent objection to the subscription-and-account model colonising transactions that used to be simple, and to professionals whose incentives have quietly been rewired away from the thing you came to them for.

Takeaways

• Automation deserves an override path: the argument is that automated systems fail in edge conditions and the expert is the one who takes manual control, "Automation is great. But human intuition is irreplaceable" [12].
• Judge automation by whether the process got shorter, not by whether it got digital. A car wash that once needed a swipe card and coins now needs an app, an account, an email confirmation and two opt-outs [4].
• Prefer explicit, injectable dependencies over implicit static ones, the case made through TimeProvider and "the End of Untestable DateTime.UtcNow" [9] and echoed by keyed service registrations [5] and discriminated unions in C# and .NET 11 [13].
• Ask whether you need the component before you learn it, the framing behind "What is IdentityServer and When Do You Need it?" [14].
• Isolate tenants at the storage level, the approach taken with multiple storage accounts per customer on MyGet, alongside build services, symbol servers and permissions [15].
• Treat major downtime as the source of your best architectural knowledge, described directly as "learning moments" [15].
• Classify and tag internal documents with standardized metadata so retrieval does not depend on recalling a filename: "Instead of relying on perfect memory, you rely on a system" [2].
• Build your own network redundancy rather than trusting a single provider, especially when their backup option will not do bridge mode [8].