.NET Development and Framework

Modern .NET is a platform on a release rhythm — not the static framework that some teams still imagine when they hear the name. Once you accept the LTS-and-STS cadence, almost every architectural conversation inside a .NET shop changes. Lifecycle planning becomes a quarterly topic. Major version migrations become routine rather than projects. And the question stops being “which version are we on” and becomes “what is our story for the next two.”

A recurring theme in this collection is evolution over time. The runtime, the BCL, and the SDK each move on their own track, and the interesting work happens at the seams. Dynamic PGO, tiered compilation, and the steady improvements to the JIT have changed what performance-sensitive code looks like — patterns that were defensible in .NET Framework era are now actively slower than the idiomatic version. Articles trace these shifts release by release rather than treating any single version as the canonical reference.

The BCL has been quietly transformed by additions like SearchValues<T>, FrozenDictionary, Span<T>, Memory<T>, and the surrounding ecosystem of ref struct types. These are not niche features — they are the new defaults for anyone writing hot-path code. Articles cover when reaching for them pays back, when the older API is still the right answer, and the surprising corners where they interact badly with closures, async, or older library boundaries.

SDK ergonomics deserve their own attention. Central Package Management, project-level PackageReference graphs, source generators, AOT, and the slow but real maturing of the workload model all shape what a maintainable solution looks like. Articles cover the project-system trade-offs that compound silently across a multi-year codebase.

The LTS/STS rhythm itself is treated as a planning concern. Articles cover how to schedule upgrades against a real release window, when to skip an STS release, and how to keep the upgrade muscle exercised so that the next migration is not the one that breaks things.

Kubernetes Is Not a Platform Strategy

Kubernetes Is Not a Platform Strategy

Kubernetes has become an assumed default in many organizations, positioned as a universal platform that absorbs governance, security, observability, and operational responsibility. This narrative is incomplete. Kubernetes is a powerful runtime orchestrator that solves one phase of the software lifecycle. Architectural risk, cost decisions, and operational failure occur elsewhere. A critical examination of where Kubernetes’s responsibility ends, and what remains the architect’s job.
Alphabet Soup: The Format Buffet Nobody Ordered

Format Buffet Nobody Ordered

Developers wanted one format. We got twenty. CSV mangles data, XML drowns in tags, JSON forbids comments, YAML punishes spaces. TOML tried fixing it. TAML went minimal. TOON optimized for AI. CCL brought category theory. Result? Five formats per project, three parsers, and debugging why NO became false. AI can’t save us either. Welcome to format hell.
Why Real Professionals Will Never Be Replaced by AI

Why Real Professionals Will Never Be Replaced by AI

The elephant everyone ignores: AI can generate code faster than you can type. GitHub Copilot autocompletes entire functions. ChatGPT builds APIs from prompts. Typing is dead. So why will real professionals never be replaced? Because “vibe coding”—describe what you want, ship what AI generates—is a productivity illusion that collapses spectacularly in production. When code generation becomes trivial, understanding what that code costs, where it fails, why it breaks under load becomes everything. AI generates syntax. Professionals understand execution, failure modes, operational cost, and production consequences. The differentiator isn’t typing speed—it’s mastering the feedback loop: write code, watch it fail, understand why, refine thinking. This discipline can’t be automated. Prompt engineers generate code. Real professionals ensure it survives contact with reality.
Most Software Teams Are Lying to Themselves—2026 Needs to Be Different

Most Software Teams Are Lying to Themselves—2026 Needs to Be Different

Happy New Year 2026! 🎉

Fix one piece of technical debt this week—not next quarter. .NET 10, analyzers, and tests are ready; discipline is the only missing part.

2025 in Review: The Year .NET Stopped Lying to Itself

2025 in Review: The Year .NET Stopped Lying to Itself

Forget the hype—2025 was when .NET tooling finally stopped pretending complexity doesn’t exist Three tools won by being honest: Aspire exposed topology, TUnit killed flaky tests, Testcontainers made infrastructure real