Hello. I am a software engineer looking for a team.

Most engineering resumes are a list of nouns. Mine has the same nouns as everyone else's, so instead of leading with those, here is the honest version of who I am, what I am actually good at, what I am not, and what I want next. It should take about five minutes, and if it saves either of us a screening call that was never going to work out, it has done its job.

I have a history degree, and it turned out to be useful

I studied history at the University of Washington. Nobody hires an engineer for that, and I am not going to pretend it was a secret master plan. But a history degree is four years of being handed a pile of partial, contradictory, badly-labelled primary sources and being told to produce a defensible account of what actually happened.

That is the job. That is debugging. That is reading a legacy codebase written by people who have all left the company. The technical skills I had to go get on my own, and I did. The part that took me four years of school is the part where you sit with something confusing and refuse to accept a story that does not fit all the evidence.

The best engineers I have worked with were not the fastest typists. They were the ones who would not let go of a discrepancy.

I have spent the last several years as the senior engineer on a small team, which is a very particular kind of education. There is nobody to escalate to. If the database is slow at 2am, that is yours. If the import pipeline silently dropped four thousand records, that is yours, and you also get to be the one who explains it. I would recommend it to anybody who wants to stop guessing about whether they are actually any good.

Three things I can do that are worth paying for

Here are the three I would stake a reference on, with the numbers attached, because numbers are the difference between a claim and a fact.

I make databases stop being the problem

The single most common reason a growing application feels bad is that a query that was fine at ten thousand rows is not fine at ten million, and nobody noticed the exact week it changed. I am good at this specific thing: finding it, proving it with a query plan rather than a hunch, and fixing it in a way that holds.

Concretely, on a 1TB-class production database that means N+1 remediation, compound and trigram indexes, denormalizing genuinely hot paths, moving heavy reads onto replicas, and cleaning out the stale data that quietly makes everything else slower. Also, unglamorously, migrations that do not lock the table and take the site down at the worst possible moment.

I find the money that is leaking out of the cloud bill

One of the results I am proudest of is boring: I redesigned how petabyte-scale media was stored, using S3 Intelligent-Tiering and Glacier Deep Archive with lifecycle rules matched to how the data was actually accessed rather than how we assumed it was. That took roughly $444,000 a year off the AWS bill.

No new product, no press release. But that is real money, recurring, and it came from reading access patterns carefully instead of accepting the bill as weather. I like that kind of work more than I probably should.

I write tools when the tool should exist and does not

This is where I have been spending my own time. Goroutine leaks in Go are a genuinely nasty class of bug: no stack trace, no panic, no failing test, just a process that slowly gets worse. So I built tether, a static analyzer that treats every go statement as a proof obligation and looks for a termination witness, reporting a concrete escape path when it cannot find one.

Then I did the part that actually matters: I pointed it at the entire Go 1.25 standard library. It produced 21 diagnostics, zero of them in non-test code, and it found a real WaitGroup hang in the database/sql tests.

The README documents the false-positive grind in the open, because that grind is the work: 91 diagnostics down to 21 across seven fixed classes of false positive, with no true positives lost. Anyone can write an analyzer that flags everything. The engineering is in the part where you make it trustworthy enough that a team will actually leave it turned on.

How I actually operate, including the annoying parts

I am test-first, but not religious about it. Tests are how I avoid being scared of my own codebase, and being unafraid to change things is the whole point. Where I am genuinely strict is that a background job should fail loudly. Silent failure is the bug that costs you a customer eighteen months later, and I will be tedious about it in code review.

I like code review and I like being reviewed. I have worked remotely for years and I write well, which matters more than people admit when the team is distributed: most of my colleagues experience my thinking as prose, not as conversation. I would rather leave a considered written comment than schedule a meeting.

I am also genuinely energized by what has happened to this job in the last two years. I use agentic coding tools heavily and daily, and I have opinions about where they help and where they quietly produce plausible garbage. Nearly everything in my playground exists because the cost of building a small strange thing collapsed, so I built a lot of small strange things. I host them myself on Cloudflare and on my own boxes with Docker and Kamal, because owning the deploy path teaches you things that reading about it does not.

The nouns, for anyone who does need them

What a good fit looks like from my side

A senior individual-contributor role, full-time W2, fully remote, on a team that ships to real users. I do best where the product has actual complexity in the data model, because that is the work I am good at and it is the work I find interesting. Fintech, healthcare, logistics, infrastructure, developer tools, anything where getting the details wrong has real consequences.

What I care about in a team, in order: that code review is taken seriously, that the on-call rotation is humane, that writing things down is normal, and that somebody in the room is willing to say a deadline is not real. I do not need a big company or a small one. I need one where an engineer can still say "wait, that number is wrong" and have it matter.

If you are hiring for something like that, I would rather have a conversation about your actual hardest current problem than walk through my resume line by line. Send me the thing that is keeping your team up at night and let us see if I am useful.