Don't Overload Your Juniors
I was on a team that put junior developers into the on-call rotation earlier than we should have. The reasoning made sense on paper - they needed to learn the system, and the senior engineers were stretched thin.
I was on a team that put junior developers into the on-call rotation earlier than we should have. The reasoning made sense on paper - they needed to learn the system, and the senior engineers were stretched thin.
I wrote a while back about framing problems with proposed solutions - the idea that "this is broken and here's what I think we could try" lands better than "this is broken" on its own. I still think that's mostly right.
Nobody enjoys being on the receiving end of bad news. That part is obvious. What's less obvious is how much worse bad news gets when the person delivering it optimizes for their own comfort instead of yours.
I've sat through dozens of Five Whys sessions over the years. The technique is simple: something goes wrong, you ask "why" five times, and you arrive at the root cause. It's taught in onboarding decks and engineering retrospectives like it's a fundamental law of incident response.
A feature request came through on my team while I was pulled into another project. The ask was simple - expand notifications so everyone on a team got them, not just people who had directly interacted with the item.
A friend of mine told me a story recently that's been stuck in my head. His company made an acquisition, and along with it they inherited the acquired company's infrastructure. Most of it was fine. But one system stood out: a desktop NAS with a couple of drives striped in RAID 0, running the acquired company's financial system.
I watched a video recently about the hidden costs of microservices, and it put words to something I've been thinking about for a while. The video walks through the usual pitch - break the monolith apart, give each function its own service, deploy independently.