Currently Building01
SysRift and fault-oriented systems tooling
Making hidden runtime behavior observable and reproducible.
Identity / Operating ManualOpen to systems conversations
Personal operating manual
I build systems to understand them.
I am a backend and systems engineer interested in what happens beneath reliable software: coordination, failure, observability, performance, and the tradeoffs abstractions conceal.
This page is a working model, not a fixed biography. It changes as the questions change.
Now
Current state of the system
A compact snapshot of where my attention is going right now.
Currently Reading02
Designing Data-Intensive Applications
Revisiting replication, storage engines, and consistency models.
Currently Exploring03
eBPF, kernel observability, and syscall boundaries
Looking for safer ways to inspect systems without distorting them.
Currently Learning04
Failure semantics in distributed infrastructure
Studying how partial failure changes otherwise reasonable designs.
Engineering Principles
Rules I use when the answer is not obvious
These are defaults, not commandments. Good engineering still requires context.
Build Before Consuming
Implement a smaller version before adopting the abstraction. Construction reveals the constraints documentation tends to compress.
Tradeoffs Over Technologies
Tools are decisions with consequences. I care more about what a choice optimizes and sacrifices than whether it is fashionable.
Optimize For Depth
A narrow problem understood deeply compounds better than a broad collection of surface-level familiarity.
Failure Is Information
Incidents, broken assumptions, and uncomfortable edge cases are observations about the real system, not interruptions to the work.
Make State Visible
Systems become easier to reason about when ownership, transitions, and failure states can be inspected directly.
Design For The Operator
The person debugging the system under pressure is also a user. Logs, controls, and recovery paths are part of the product.
History
How the questions became more fundamental
A selected timeline of shifts in engineering attention rather than a résumé chronology.
01
Started building Discord bots
A broken tutorial turned JavaScript, asynchronous work, deployment, and public failure into practical concerns.
02
Built the first public projects
Users introduced persistence, permissions, reliability, and the difference between code that runs and software that survives.
03
Moved toward backend engineering
Databases, APIs, queues, and operational constraints became more interesting than interface work.
04
Started thinking in distributed systems
Coordination, concurrency, partial failure, and consistency changed how I reasoned about every service boundary.
05
Went deeper into Rust and infrastructure
Memory models, process boundaries, networking, and kernel interfaces became the next layer of inquiry.
06
Building tools that expose hidden behavior
The current focus is observability, adversarial systems, and infrastructure that makes failure easier to understand.
Exploration Areas
Domains where the questions keep multiplying
These are active areas of curiosity, not claims of final authority.
Systems
Operating SystemsRustLinuxRuntime Internals
Coordination
Distributed SystemsConsensusReplicationQueues
Infrastructure
DatabasesNetworkingObservabilityPerformance
Adversarial
SecurityHoneypotsProtocol DesignFailure Analysis
Mental Models
Ways I compress complicated systems
Small models I return to when a system behaves differently from its diagram.
local → global01
Emergence
Simple local rules can create surprising global behavior. Understanding each component is not the same as understanding the system.
measure → move02
Bottlenecks Move
Optimization rarely removes constraint; it relocates it. Every improvement should trigger a new measurement.
failure → evidence03
Failure Is Information
A failure reveals the boundary between the model and reality. Treat it as evidence before treating it as embarrassment.
buffer → debt04
Queues Hide Time
A queue converts immediate pressure into delayed pressure. Latency often accumulates where work appears safely buffered.
state → coupling05
State Creates Gravity
The more state a component owns, the harder it becomes to move, replicate, recover, and reason about.
choice → system06
Local Decisions Compound
Reasonable decisions made independently can produce unstable global outcomes when feedback loops are ignored.
Shelf
Books shaping the current model
A small working shelf rather than a record of everything I have read.
Currently Building
Active engineering work
Projects are treated as instruments for learning, not finished display objects.
Currently BuildingFocusStatus
SmartQueueAdaptive distributed scheduling and workload predictionIteratingEchoTrapAdversarial TCP behavior, telemetry, and safe isolationHardeningSysRiftSyscall replay, process inspection, and failure reproductionResearchingPortfolioTurning project history into useful engineering documentationPublishingOutside Engineering
A little distance improves the model
Outside engineering, I value quiet observation, long-form reading, music, and conversations that change how I frame a problem. The useful part is not escape from technical work; it is returning with a wider vocabulary for attention.
Writing Philosophy
I do not learn through roadmaps. I learn through things that seem interesting enough to build.
Writing is how I inspect what the work actually taught me: the assumptions that failed, the tradeoffs that remained, and the questions worth carrying forward.