2025 year in review

Looking back at 2025: Technical and Personal reflections.

JJ for my workflow

Jujutsu (JJ) for my workflow

This is how I use JJ.

There’s a lot one can do with source control tools; this is what I do. Terms are a bit loose, especially commits versus changes and branches versus bookmarks.

2024 year in review

Looking back at 2024: Technical and Personal reflections.

How to split code changes

How to split code changes We’ve all been there: when writing code, we fall victim to “while I’m here, I might as well…” and end up with a collection of code changes instead of a focused set of deltas. One term for this is shipwrights disease. It’s so easy to fix this typo, update this comment, change this dependency, etc… There are ways out and methods to logically group changes made, depending on what’s most important.

Closed loop development

Closed loop development Brace yourself for car analogies. Vehicles: open/closed loops Modern cars have two modes of operation: open loop and closed loop. Open loop: get engine inputs such as engine speed, air temperature and how much air is going into the engine. Apply a set of rules to determine how much fuel to put in. Closed loop: using the above data combined with information from the exhaust, adjust how much fuel goes into the engine.

Tiny guide to Rails

The tiny guide to Rails (that I wish I had) I’ve found Rails to rely on more convention over configuration than I’m comfortable with - so much so it seemed impenetrable at times. This is the tiny guide to Rails I wish I had to understand where code lives and how the application works. Know where to find things Go to definition or go to implementation doesn’t work well with Rails projects and most IDEs I’ve tried.

2020 technical review

As the challenging year of 2020 wraps up, here’s what happened in the past twelve months with a focus on my experience in technology. Rust I’ve been writing Rust since mid 2015. That’s over five years of working with the language. At the start of 2020 I stepped back from my work on Rusoto, an AWS SDK for Rust. Looking back: every line of Rust I’ve written has been unpaid, volunteer work.

Rusty von Humboldt

Rusty von Humboldt is a GitHub Archive data explorer and Extract, Transform and Load (ETL) tool. Or: seeing how far the tools you know can take you.

Surviving the upcoming winter

This is my perspective of the current state of Rusoto as a semi-retired maintainer and Amazon outsider. The post borrows the term winter from AI Winter: a time period of decreased interest and funding. Amazon is hiring engineers for an AWS Rust SDK Amazon has two public job openings for Senior Software Development Engineers - AWS Rust SDK. There’s now enough customer demand for Amazon to make an official SDK for Rust.

Red/green bugfix

Red/green bugfixes are the best technique for communicating understanding of a bug and its solution, especially for asynchronous code reviews. A bug Say a new bug has been discovered in a backend service. If it’s found in production, the first instinct is to solve it as quickly as possible. While laudable, this kneejerk reaction can actually make the fix slower and harder for others to understand. Usual fixing procedure Reproduce the bug Using logs and/or reading the code, find where the issue is Fix the bug, make a pull request, let coworkers review it While this procedure is straightforward and can get a bug fix out quickly, there are downsides to this process: