Software Engineering Principles and Practices

Software engineering is the practice that turns code into systems people can rely on. The distinction matters because typing code has never been easier — AI assistants produce syntactically valid output in seconds — yet the rate at which production systems fail, leak data, or quietly accumulate maintenance debt has not improved. The discipline lives in the gap between code that compiles and code that survives contact with reality.

The articles in this collection treat software engineering as a profession, not a productivity exercise. The recurring theme is the feedback loop: write code, watch it fail, understand why, refine thinking. That loop cannot be automated because closing it requires learning from production failures and applying that knowledge to prevent the next one. Prompt engineering optimizes for speed; engineering optimizes for survival under conditions the original author did not anticipate.

Topics range from defensive programming with ArgumentNullException.ThrowIfNull and guard-clause patterns, through structured logging that does not lie about what happened, to multi-framework targeting decisions that look harmless and quietly break the build on the third project that consumes the library. Clean Code is treated as a starting point rather than a creed — most teams that quote SOLID rarely apply it consistently, and the articles examine what actually works in production versus what looks defensible in code review.

A second cluster of articles addresses the economic reality. Technical debt compounds like financial debt, and small shortcuts become the dominant cost driver three years in. Retiring legacy projects, illuminating debt with analyzers, and recognizing when a refactor is cheaper than another feature release are covered with the trade-offs named explicitly.

The voice across these articles is opinionated and grounded in specific failures. Generic advice rarely changes behavior. Specific failure modes, named clearly, do.

Structured Logging Patterns That Actually Survive Production

Structured Logging That Survives

Every pattern here addresses a failure mode I have either shipped or inherited. Source generators on hot paths, scope opt-in per provider, end-to-end correlation ID propagation, log levels as an ops contract, sink selection as an architecture decision, and OpenTelemetry Logs for greenfield services: six concrete changes that make structured logging trustworthy in production.
Standardize or Drift: One Defaults Package for All Your Solutions

Standardize or Drift: One Defaults Package for All Your Solutions

Directory.Build.props drift is the quiet tax every multi-repo .NET org pays. NetEvolve.Defaults ships MSBuild properties, .editorconfig, NuGet Audit, and ten Roslyn diagnostics as a private-asset NuGet package. Bump the version once, every repo gets the upgrade.
The Codebase Doesn't Know You Quit

The Codebase Doesn't Know You Quit

The first four parts of this series treated legacy as something between me and myself: Past Self leaving code for Future Self, with an AI in the middle. That framing is incomplete. Code outlives employment, not just memory. The companies I worked for have forgotten most of what I did there. The repositories haven’t. This is the fifth part of the Code as Legacy series, about the legacy you leave when you’re not around to defend it.
The Machine Writes. The Legacy Is Still Mine.

The Machine Writes. The Legacy Is Still Mine.

Part three ended with me promising to stop adding to Past Self’s pile. I was already wrong. I’m not the only author anymore: Copilot and Claude finish methods before I’ve finished thinking, shipping code under my name with my git config as the committer. This is part four of the Code as Legacy series, about what changes when the author is partly a machine.
You're Shipping Bugs Faster, and Your Tests Are Helping

You're Shipping Bugs Faster, and Your Tests Are Helping

AI coding agents make you faster. They also make your bugs faster: they generate plausible-looking code, you review quickly, the tests pass, and production breaks two weeks later. I keep falling into this pattern myself, always on the happy path, telling myself the edge cases come later. They don’t. Here’s the pattern, why most test frameworks make it worse, and how TUnit fights it.