Nur.
Systems-oriented
software engineer.
Building distributed systems, communication workflows, and experimental software. I like understanding how things actually work — from message brokers to packet flows to the small details that hold systems together.
An engineer who likes to take systems apart and put them back together.
I gravitate toward the parts of software where coordination, communication, and constraints actually matter — protocols, brokers, schedulers, the quiet machinery underneath products.
Read the source
I prefer reading internals over reading abstractions. Half my notes are annotated codebases of tools I use every day.
Small, deliberate experiments
Tiny prototypes — a clone, a simulator, a custom protocol — are how I really understand a concept. Most never ship. They all teach something.
Look at the seams
Behavior lives between components: queues, retries, partial failures, timing. That's where I spend most of my engineering attention.
Engineering notebook — what I'm currently digging into.
An informal log of experiments, reading lists, and half-built prototypes. Nothing here pretends to be production-ready. That's the point.
Things I've built to understand something deeper.
Each project started as a question. The architecture is the answer I converged on after enough iterations.
How I think about building software.
Tools I reach for.
Chosen because they're boring in the best way: well-documented, observable, and well-understood failure modes.
Open a connection.
If you're working on distributed systems, realtime infrastructure, or something genuinely curious — I'd like to hear about it.