About
Hi 👋, I’m Eugene, a Build 🛠️ & Developer Experience Engineer with 20+ years in software engineering — the last 5 spent in the glorious trenches of build systems, developer tooling, and convincing monorepos to behave themselves. My main obsession is Bazel. Not in a “I read the docs once” way — in a “I’ve stared at Starlark stack traces at 11pm and lived to tell the tale” way. I design and maintain scalable, hermetic build systems for polyglot monorepos, author custom rules and toolchains, and have led migrations to Bazel modules (bzlmod) — which is basically convincing an entire codebase to change how it thinks about dependencies. It’s as fun as it sounds.
If your CI pipeline takes 45 minutes, I will take that personally. If your builds are flaky, non-reproducible, or just vibes-based, I will find out why. I care deeply about the feedback loop between writing code and seeing it run — because every minute a developer spends waiting for a build is a minute they’re not building things. Or they’re on Slack. Which is worse.
I used to write a lot of Golang code — services, CLIs, code generators, parsers, gRPC and REST APIs, things deployed to Kubernetes, enough auto-generated YAML to last several lifetimes. I also technically reviewed a book on Protocol Buffers, so I have opinions about field numbers and reserved keywords that nobody asked for. These days I mostly write Starlark, which is Python’s minimalist cousin that was designed to be simple and somehow still manages to surprise you.
I do all of this in NeoVim. Yes, by choice. No, I don’t want to talk about it. I’ve made my peace with suffering — just a little bit — in exchange for never having to touch a mouse mid-thought. It builds character. So does Bazel, apparently.
Speaking of which — I’m not a Google fanboy. I want to be clear about that. And yet: Bazel is a Google project, Protobuf is a Google project, gRPC is a Google project, and Kubernetes came out of Google. Make of that what you will. I’ve simply made pragmatic choices that happen to keep ending up in Mountain View. The tools are good. I use them. We don’t need to make it weird.
Before going all-in on build infrastructure, I spent years as a backend engineer. And before that, a decade as a Microsoft SQL Server developer and DBA — which means I have a deep, personal relationship with query plans, index fragmentation, and the particular suffering of debugging a stored procedure written in 2008 by someone who has long since left the company.
I’ve worked everywhere from scrappy early-stage startups (move fast, question everything, why do we not have CI) to large enterprises (move carefully, justify everything, why does CI take 3 hours). That range has given me a pretty good radar for what actually matters vs. what’s just accidental complexity someone forgot to clean up.
Got a monorepo that’s slowly eating your engineering team alive, a CI pipeline
that’s become a running joke, or just a build problem that’s keeping you up at
night? Let’s talk. Drop me a message at hello@ekhabarov.com — I’m always up
for a good build system horror story 👻, and I respond faster than a cold
Bazel cache. First build audit is free. Opinions on your WORKSPACE file
are not.
Companies I worked for
plus a dozen of others.
My projects
| Project | Stars | Descripton |
|---|---|---|
| Envoy as an API Gateway |  | Demo project: build gRPC micoservices with Bazel and deploy them to Kubernetes. |
| eBay/rules_ytt |  | Bazel rules for YAML templating tool (ytt). |
| protoc-gen-struct-transformer |  | Protobuf plugin which generates structures transformation functions. |
| sts |  | Structure-to-structure transformer generator, same idea as the previous, but transformations are based on Go types. |