I am a senior software engineer specializing in backend development using Python and AWS. I'm most interested in working on projects that make a meaningful impact on their users, and created by teams that are empowered to do their best work.

These are the values that define my approach to building software and collaborating with teams.

Just about everything in software engineering involves trade-offs. Even when the solution feels obvious, there is almost always some downside. Part of my job is to make those trade-offs visible so the team can decide together on the best way forward.

For the most part I am wary of hard and fast design principles when it comes to software design. To paraphrase Dan North I prefer to focus on design properties, or characteristics that well-built software tends to contain rather than dogmatic rules about what software must contain. And on that same note I think North’s CUPID framework is a pretty great set of properties to strive for.

I love working with legacy code! In my experience, a well-maintained, stable codebase can deliver value far more efficiently than a rebuild using the latest popular framework. Similarly, I love iterating on under-maintained, under-tested, under-documented codebases and bringing them into a healthy state.

But with all of that said, sometimes a full rewrite is the right choice. It depends on the trade-offs!

Python is my preferred language, but I don’t believe any popular language is “bad”. It all comes down to trade-offs, not the least of which is what developers are most used to! In earlier points in my career I might have told you Ruby or Typescript was my preferred language, simply because it was the language I was most steeped in at the time. Furthermore, depending on the problem to solve, the team working on it, or countless other factors, Rust, C++, Go, or any other modern language might conceivably be the right choice.

I love writing and thinking about tests. I’m a practitioner of test-driven development and I almost always write my tests first as a way to guide implementation. But with that said, I’m not dogmatic about TDD. Other great engineers prefer a different approach and that can be valid too.

I love refactoring code to improve readability and maintainability, but I also know when a refactor isn’t worth the effort. It’s all about trade-offs!