Best Practices in Architecture and .NET Development
“Best practice” is one of the most abused terms in software engineering. It usually means “what looks defensible in a slide deck” rather than “what actually works in production”. The articles in this collection treat the label with skepticism — every practice is a trade-off, and the only honest question is which trade-off applies to the situation in front of you.
The framing across these articles is consistent: a practice is worth adopting when the failure mode it prevents matters more than the overhead it adds. SOLID principles are a starting point, not a creed. Clean Code passages get quoted in code reviews far more often than the code in the repository reflects them. The articles examine where the gap between stated practice and actual behavior comes from and what changes that gap in real teams.
Specific topics span the .NET stack and the systems built on top of it. Defensive programming with throw helpers, multi-targeting build hygiene, central package management, structured logging that does not lie about what happened, mutation testing that exposes the blind spots line coverage hides, and TimeProvider adoption two years after it shipped — each is treated as a concrete intervention with measurable cost and benefit rather than a virtue to be signaled.
A separate cluster addresses the practices that hold up under pressure: incident response procedures rehearsed before the incident, audit logging that survives the audit, access control that fails closed, and feedback loops that catch regressions before customers do. The recurring observation is that practices fail not because they are wrong but because they are applied as rituals rather than as decisions with named consequences.
The collection also documents the practices the author has changed his mind about. Calling a pattern a best practice today and a mistake five years later is normal — the discipline is naming why the context shifted, not pretending the original advice was always correct.
How to Use Copilot Without Becoming Its Puppet
In a previous article, we laid it out – unfiltered: Copilot turns junior devs into syntax secretaries.
Not because it’s evil. But because it removes friction before understanding.
It gives you working code before you know what working even means. It creates the illusion of progress, while slowly eroding the very skills that define a software engineer: reasoning, decision-making, and technical ownership.
Copilot Turns Junior Devs Into Syntax Secretaries
The hype around GitHub Copilot (or any other AI code assistant) is deafening. AI-assisted coding. Effortless automation. 10x productivity.
But here’s the harsh truth: Copilot isn’t empowering junior developers – it’s deskilling them.
Vibe Coding in .NET: Creative Catalyst or Maintenance Risk?
In the world of software development, there’s a recurring tension between discipline and improvisation. Somewhere along that spectrum lies a phenomenon increasingly referred to as Vibe Coding. The term evokes a style of development where engineers follow intuition and momentum rather than formal plans, processes, or design patterns.
It’s fast, fluid, and occasionally brilliant. But is it sustainable in a .NET-based enterprise context?
Managing Errors, Warnings, and Configurations in C# and .NET
When we activated static code analysis for the first time in one of my last projects, the overwhelming number of warnings exceeded expectations and highlighted gaps in the code. Without making any changes, the project already had a significant number of warnings. After activating additional analyzers and updating some configurations, this number temporarily increased dramatically.
The high number of warnings was initially daunting, but we saw it as an opportunity to significantly improve our code quality. At first glance, it seemed easier to suppress or ignore these warnings. But as I often remind my team, “The code you create is a valuable legacy, so it’s important to build it carefully.” Ignoring warnings today creates obstacles for future developers—and that could very well include you six months down the line.
This experience reinforced the importance of managing warnings and errors systematically. Let me share some of the lessons we learned, the strategies we used to tame those 60,000 warnings, and how you can apply these techniques to your own projects.
A Tale of Forgotten Pennies and Lost Dollars
In software development, there’s a silent debt that accrues interest over time, often hidden beneath layers of code and decisions made in haste or ignorance. This debt is aptly termed technical debt. Much like the german proverb, “Wer den Pfennig nicht ehrt, ist den Taler nicht wert”, (or the english equivalent, “A penny saved is a penny earned”) technical debt reminds us that small oversights or compromises in the present can snowball into significant challenges down the road. This article critically examines the parallels between financial principles and technical debt, emphasizing the importance of addressing both direct and indirect debt while understanding its distinction from external risks such as hacking or abuse.