Engineering, leadership, productivity, and the craft of shipping software.
On a lot of teams, code that a pair of devs wrote usually gets a lighter code review. Nobody wrote that rule down and nobody voted on it, but pairing earned it. Here's what the research actually says about that discount, why it's never one flat size, and what happens when dev + agent starts getting filed under the same category.
A one-line warning in my deploy log took my site down for thirty minutes. It didn't stop anything, the command exited zero, and it looked like every other line scrolling past. Software risk stays invisible until traffic hits it, and that invisibility is why the work that prevents incidents is the first thing a deadline cuts.
Nothing logs a 1:1. No ticket closes when it's over, and its best outcome is a prevented problem, which no system can count. Here's the 30 minutes a week I protect for each person, the short document that runs it, and what protecting it actually costs me.
Tech debt you can see, point at, and put on a ticket. Culture debt gives you none of that...it compounds quietly in the norms and the trust until it shows up in the product. Here's how one small team went into it, why the reward quietly beat the values everyone said they held, and why the trust took over a year to rebuild.
When making something gets cheap but judging it stays expensive, the cost slides downstream...social media did it to your feed, AI code generation does it to your repo. The difference is a bad post washes away by morning, and a bad merge sits there for years.
The risky PR is rarely the big one...it's the one carrying money code, a migration, or a red build, regardless of size. Here's what I look for when one lands, and the product I'm building so senior attention goes where the risk actually is.
Deleting a year-dead feature flag turned a forgotten feature back on and broke production...here's why flag cleanup is a runtime change, not tidying, and how the context you need decays while the flag sits there looking harmless.
Big PRs don't come from lazy engineers. They come from a skill almost nobody gets taught: how to cut a piece of work down into small, reviewable chunks. Here's why that's still the highest-leverage habit in engineering... and why AI just made it matter more, not less.
Most merge standards are wiki decoration. What makes a team actually follow them isn't the list...it's enforcement, consistency, and the why.
The three targets I set for my engineering team — PR size, open-to-merge time, and change failure rate — and why these are the three that matter.
Most code-review checklists ask "does this work?" The harder question is "what happens when it doesn't?" Five things I check on every PR that the standard checklists miss... plus the comment grammar that makes reviews actually move.
Building software is like traveling between destinations. In our case, it’s traveling from Problem...
Hello, hello! So last week we learned about using your own inbox to capture all your to-dos into a...
"If you can't explain something to a first-year student, then you haven't really understood."...
Ever feel like you're juggling too many tasks, and letting too many things fall through the cracks?...
Let's face it: in software engineering, change is as inevitable as bugs in a first release. Yet, for...
Once again, I'd like to start this week's post off with a question. After last week's post we know...
Continuous learning. Ask any accomplished person in the world today and they'll tell you this is one...
Hello hello 👋 I'd again like to start this week's post off with a question. You have your todo list...
Let's face it: the world of software development is massive, and it's only getting bigger. With new...