loganwick

I grew up curious about how things worked. Programming clicked somewhere in college — the realization that you could describe a process precisely enough for a machine to follow it, and then watch it actually work, felt like a superpower. I started the way most people do: tutorials, small projects, building things I needed.

My first real work was freelance. Client websites, small automation scripts, the kind of work where you wear every hat. It was messy and educational in ways structured learning isn't. You learn what "done" means when someone is paying for it. You learn that software that works once is different from software that keeps working.

My first engineering role put me inside a payments company. The domain forced me to care about correctness in ways I hadn't before — financial transactions don't tolerate ambiguity. I learned about idempotency, distributed consistency, and what it means to build systems where the failure modes matter. Fraud detection came next: real-time screening, velocity analysis, rule engines, the challenge of making millisecond decisions on whether to trust a transaction.

Working on payments also introduced me to the data that surrounds financial systems. Every transaction leaves a trace. The problem of making that data usable — clean, fast, reliable, observable — pulled me toward data engineering. I started building pipelines, then frameworks for validating them, then infrastructure for running them at scale.

Platform engineering followed naturally. As pipelines multiply, the underlying infrastructure becomes the constraint. I moved into Kubernetes — not because it's fashionable, but because it's the right tool for running heterogeneous workloads reliably. Scheduling ingestion jobs, managing autoscaling with KEDA, building operator patterns for tenant isolation. The infrastructure layer stopped being someone else's problem.

How I think about engineering

I try to understand systems before I build them. Reading papers, not just documentation. Understanding why a database makes the tradeoffs it makes, not just how to use it. The distributed systems literature — Dynamo, Raft, Spanner, the Dataflow model — isn't academic to me; it's a map of the territory.

I'm skeptical of complexity that isn't earned. Most systems fail not because they lacked sophistication, but because they accumulated complexity faster than the team could understand it. I'd rather build something simple that works and evolve it, than start with an architecture that requires six whiteboards to explain.

I care about observability. A system you can't understand in production is a system you can't operate. Good logs, meaningful metrics, structured events — these aren't luxuries. They're the difference between debugging by reasoning and debugging by guessing.

Currently

I'm working at the intersection of data engineering and platform engineering — building the infrastructure that makes data pipelines reliable and observable. On the side, I'm interested in AI infrastructure: how do you serve LLMs efficiently, how do you build evaluation frameworks, what does the deployment stack look like at different scales.

I write about what I'm learning in my engineering notes — shorter pieces on specific problems I've worked through. I track papers and books in my reading list. The best way to see what I've built is the projects page.

Outside of work

I read a lot — technical papers, systems books, and occasionally things that have nothing to do with computers. I'm interested in how complex systems behave, which turns out to apply equally well to codebases, organizations, and cities.

If you want to talk about systems, data infrastructure, AI, or anything else, reach out on the contact page.