Write .NET code that scales.
20 years of C#/.NET in production — world-class healthcare companies, national-scale real estate platforms, AI-assisted engineering workflows. The patterns here are the ones that actually held up. No toy examples. Just what works at scale.
1// ❌ The wrong way — you wrote your own dependency. 2public class OrderController : ControllerBase 3{ 4 private readonly OrderService _service = new OrderService(); 5} 6 7// ✓ The clean way — ask for what you need. 8public class OrderController(IOrderService service) : ControllerBase 9{ 10 private readonly IOrderService _service = service; 11 12 [HttpPost] 13 public IActionResult Create(OrderDto dto) => 14 Ok(_service.Create(dto)); 15} 16 17// Program.cs — register once, inject everywhere. 18builder.Services.AddScoped<IOrderService, OrderService>();
Unit Testing with NSubstitute — Tests That Survive Refactoring
You learned testing from a tutorial. The tutorial showed you how to mock, so you mock everything. Then you refactor a helper method and 47 tests explode. The code works — the tests can't tell the difference.
// ❌ A stunt double for the coffee cup. var claim = Substitute.For<Claim>(); var dto = Substitute.For<ClaimDto>(); // ✓ Mock the boundary. Data is just data. var repo = Substitute.For<IClaimRepository>(); var claim = new Claim { Id = "CLM-123", Amount = 150.00m };
When the CRUD Hits the Fan — Building Resilient WebAPI Controllers
Your controller passed every code review. Then Black Friday hit, the payment API went down, and it took the entire site with it. Resilience isn't a feature — it's the difference between degraded and dead.
// ❌ No timeout — a dead dependency drains the pool. builder.Services .AddHttpClient<IPaymentClient, PaymentClient>(); // ✓ Timeout, retry with backoff, circuit breaker — // they only work as a set. builder.Services .AddHttpClient<IPaymentClient, PaymentClient>() .AddStandardResilienceHandler();
Exception Handling That Survives Production
At 1,500 fake "errors" an hour, your error log is 97% noise — and the one
SqlException that matters is buried under exceptions that aren't
exceptional. Expected failures are results, not throws.
// ❌ Exceptions as control flow — your log becomes noise. throw new ClaimNotFoundException(claimId); // ✓ Expected outcomes are results, not exceptions. public async Task<Result<Claim>> GetClaimAsync(string id) { var claim = await _repo.FindAsync(id); return claim is null ? Result<Claim>.Failure($"Claim {id} not found") : Result<Claim>.Success(claim); }
Be the Architect, Not the Typist
Letting AI write your code one method at a time is a step sideways. Direct it at the system, hand it the constraints, and review the design — that's how twenty years of experience compounds with the tools.
// Don't type code. Direct the architect. // // Instead of: // "Write a method that adds two numbers" // // Try: // "Add an idempotent reconcile step to the // payment pipeline that handles partial refunds // without double-crediting the customer." public sealed class PaymentReconciler { public async Task<ReconcileResult> ReconcileAsync( PaymentBatch batch, CancellationToken ct) { // implementation guided by your specification } }