I’m Nick Demming. I write about Platform Engineering Leadership, AI Platform Engineering, AWS, MLOps, SRE-grade platforms, data systems, and the boundary where models, services, infrastructure, and teams meet.
The short version: I care about systems that remain understandable after they become real. That usually means explicit models, strong interfaces, careful data representation, reproducible builds, observable runtime behavior, and enough skepticism about abstractions to use them well rather than ornamentally.
What this site is
demming.dev is a revived personal archive and a base for current professional writing. The first version of this site was built with Hakyll and centered on Haskell, type systems, numerical computing, testing, benchmarking, and database work. The current version preserves that corpus while moving the site onto a modern Astro-based publishing system.
The old posts are intentionally not rewritten into contemporary marketing prose. Some of them are rough, some are unfinished, and some reflect the priorities of their time. I am keeping that provenance visible, then polishing and extending the material where it still deserves a more precise treatment.
What I work on now
My current professional focus is Platform Engineering Leadership: full-lifecycle platform ownership across architecture, delivery, reliability, security and cost awareness, operational evidence, and practical AI use in software delivery.
- AI Platform Engineering, agentic engineering workflows, MLOps, evaluation gates, and feedback loops;
- AWS platform architecture, cloud foundations, Terraform, CI/CD, observability, and platform governance;
- SRE-grade production ownership: reliability, rollback paths, operational evidence, and systems that can be diagnosed under pressure;
- data engineering, data contracts, lineage, database boundaries, and operational data quality;
- Java, Rust, C++, Python, Go, TypeScript, and JVM systems where runtime behavior and interfaces matter;
- functional software design, type-driven architecture, testing, benchmarking, and the limits of empirical evidence in software.
The common thread is not a single cloud, language, or framework. It is the attempt to make software less accidental: to align implementation with specification, platform boundaries with team boundaries, data with semantics, and engineering decisions with the risks they actually introduce.
How I work with communication
Communication has to fit the audience and the decision. For leadership and business stakeholders, I lead with outcome, risk, cost, and the next decision. For engineers, I spell out the model, interfaces, invariants, failure modes, and validation path when those details matter. For product stakeholders, I separate what is known, what is assumed, and what still needs evidence.
The point is not to make everything long. It is to make the right thing clear at the right level: crisp when the decision needs crispness, detailed when the system demands detail, and explicit about uncertainty when the risk is real.
The archive and the next phase
The immediate goal is to keep the historical demming.dev material readable while publishing current work on AI platform engineering and platform leadership. The old archive remains labeled as archive material. Newer writing should be easier to scan for hiring managers and engineering leaders without turning into generic personal-brand copy.
The direction is still the same as before: mathematically informed engineering, written with enough detail to be checked, argued with enough care to be useful, and kept personal enough not to become generic documentation.