Hello there! I'm Jedai Saboteur.
I’m a software engineer, which means I spend a lot of time thinking about systems that are supposed to work, systems that almost work, and systems that work until one small, well-meaning change causes something deeply confusing to break three layers away. I’ve learned to enjoy that process more than I probably should.
This page exists because résumés are useful, but incomplete. They tell you where I’ve been and what I’ve touched. They don’t really tell you how I think, what I’m curious about, or what it’s like to work alongside me when a problem doesn’t have an obvious solution yet. This is an attempt to fill in those gaps.
I came to software engineering because I like building things. I stayed because I like understanding them.
Over time, I’ve found myself drawn less to flashy features and more to the underlying structure: how a system is shaped, how decisions compound, and how small design choices affect the people who have to live with them later. I enjoy refactoring not because it’s glamorous, but because it’s honest work. It’s where you confront tradeoffs you postponed and assumptions you didn’t know you were making.
I’m comfortable working across the stack, but what matters more to me than the layer I’m in is whether the system makes sense—to users, to teammates, and to whoever inherits it next.
Outside of work, my interests look different on the surface, but they’re surprisingly aligned under the hood.
I write fiction and short essays. I think a lot about the games I play, as well as the ones I don't. I listen to music obsessively and spend time producing my own. I have a habit of pulling things apart—not to ruin the magic, but to understand why the magic works in the first place.
Those hobbies aren’t an escape from engineering. They exercise the same muscles: pattern recognition, empathy, pacing, and respect for constraints. Writing a story and designing a system both require you to anticipate how someone else will move through something you’ve made. Both reward clarity. Both punish unnecessary cleverness.
There’s a recurring question that follows me around, whether I’m coding or writing:
How do systems shape behavior, and where do people push back?
That question shows up everywhere. In software architecture. In user interfaces. In game mechanics. In stories about power, agency, and unintended consequences. In our everyday lives. It’s also shaped how I work on teams. I pay attention to incentives, feedback loops, and the quiet friction points that don’t show up on sprint boards but absolutely affect outcomes.
If we work together, you’ll probably notice a few things.
I ask a lot of questions early, not to slow things down, but to make sure we’re solving the right problem. I care about code being readable by people who didn’t write it. I’m comfortable sitting with ambiguity while things are still forming, and I’m happy to be decisive once the shape of the problem is clear.
I don’t believe complexity is a virtue, but I don’t fear it either. I’d rather deal with complexity directly than hide it behind abstractions that only work until they don’t.
I also have a few strong opinions that I hold lightly:
Clarity beats cleverness. Tools are never neutral. Learning is iterative and occasionally uncomfortable. Depth matters more than speed. Constraints are not the enemy of creativity—they’re usually the source of it.
These aren’t rules so much as tendencies. If they resonate with you, we're probably pretty close in alignment.
This page isn’t meant to replace a résumé. It’s meant to sit beside one.
If you’re a potential teammate or manager, this is the version of me that shows up before the meetings, the code reviews, and the long conversations about edge cases and tradeoffs. The rest—the titles, timelines, and technologies—can live elsewhere.
This is the part that stays consistent.
Thanks for reading.
If you'd like to check out my actual resume, you can click here to view it on Google Drive.
If you're more of a LinkedIn person, click here to check out my profile.