About

I’m Nick Demming. I write about senior platform engineering, AWS, AI infrastructure, MLOps, data systems, and the uncomfortable but useful boundary between models, services, and production software.

The short version: I care about systems that remain explainable 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, including drafts, 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

My current professional focus is senior/staff/principal-scope engineering:

  • AWS platform architecture, cloud foundations, and production operating models;
  • Terraform, Kubernetes, CI/CD, observability, and platform governance;
  • AI platform engineering, MLOps, model deployment, evaluation gates, and feedback loops;
  • data engineering, data contracts, lineage, database boundaries, and operational data quality;
  • Java, Rust, C++, Python, and Go 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 write

I prefer long-form technical explanation over short-form certainty. When an abstraction is useful, I want to spell out why it is useful, what it hides, and where it fails. When a model is convenient, I want to know what it approximates. When a benchmark looks persuasive, I want to know what it does not measure.

That style can be demanding, but it is intentional. Many mistakes in software are not syntax errors; they are category errors, hidden assumptions, or underspecified boundaries. A good technical essay should make those boundaries visible.

The archive and the next phase

The immediate goal is to restore the historical demming.dev material faithfully and make it readable again. After that, I will separate the old archive from new writing, normalize seminars as publications, add consulting/contact surfaces, and gradually turn the stronger draft material into finished essays.

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.