On Monday our QA manager reported a performance regression in an upcoming release. A feature flag that was supposed to improve query performance was actually making things worse. The feature controlled automatic date filtering - ensuring that queries always included a 90-day window at most, which meant the database could use its date-based partitions instead of scanning entire tables.
I wrote a while back about learning to say no - pushing back on requests that don't fit the system, setting boundaries when you're stretched thin, getting comfortable with the discomfort of telling someone "this isn't the right call." That post was about building the skill.
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.
Everyone lies. That's not a controversial statement and I don't mean it as a judgment - it's just an observable fact about how people operate. But not all lies serve the same purpose, and I think most people don't spend much time asking themselves who a given lie is actually for.
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.