I’m a systems engineer with 13+ years in .NET, specializing in low-level performance, production debugging, and building systems that actually work when it matters.
For seven years, I was on the core team at Hibernating Rhinos working on RavenDB—a distributed NoSQL database where production failures aren’t theoretical. I contributed to the Voron B-Tree storage engine: transaction management, memory-mapped I/O, page allocation, and storage-layer optimizations. That meant debugging real customer crashes, optimizing under production load, and understanding exactly how things break at scale.
Since then, I’ve spent the last 6+ years applying those same skills at three other companies—Gigya/SAP, Snyk, and a stealth startup—debugging production hangs, memory leaks, performance cliffs, and the chaos that only shows up when millions of requests hit real hardware.
Why “Gray Matter Developer”? Because it’s about understanding how things actually work. Not tutorials. Not best practices regurgitated from blog posts. The real stuff: memory subsystems, crash dumps, why your code runs fast on your machine but crawls in production, what happens when the garbage collector stalls your finalizer thread. That’s gray matter—deep systems knowledge.
The Builder Mindset
I’ve been self-taught since around age 12. Back then, I didn’t want to play computer games—I wanted to build them. That builder mindset never left. My 12th-grade final project was a paint app in C++ written directly to VGA memory—no libraries, just the RBIL and a lot of time.
That fascination with building evolved. Games led to graphics, graphics led to performance, performance led to systems, systems led to distributed databases. Same principle the whole way: understand how things work, then make them better.
From Quiet to Visible
You might know that I used to be one of those “dark matter developers”—quietly shipping code that nobody saw. One chilly day at the office, I showed up in just a T-shirt. My boss asked, “You’ll be cold in Siberia?” I said I’d never been. He replied, “Congratulations, you’re going to speak at a tech conference there.” That’s how this whole blogging-and-speaking thing started.
What Drives This
This blog isn’t about climbing the ladder or collecting followers. It’s about sharing what I’ve learned so you can build more robust systems, debug production problems faster, and understand your code at a deeper level. Every post here comes from real work—real bugs, real customer problems, real production pressure.
If you’ve got ideas, feedback, or you just want to talk systems engineering, debugging, or why your allocator is hot—reach out. I love this stuff.
Check out my GitHub and my CV if you want to see what I’ve worked on.
Comment
