Hey!

Welcome back to another week of musings. We just got back from NYC, and it was hot. Really hot. We got hit with a big rain on the first day, which felt like a warning we ignored, but overall it was a great trip.

I'm still catching up on sleep and other chores, so bear with me if this issue reads a little jet-lagged.

I hope you had a great weekend and managed to rest!

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• How I Find Problems to Solve as a Staff Engineer by Lalit Maganti
• How Zalando Built an In-Process Client-Side Load Balancer for One Million Requests per Second on InfoQ

I was thinking lately about nitpicking, and how easy it is to dress it up as "high standards" when really it's just a lack of trust.

A while back I built a REST API for managing test environments. I didn't have the bandwidth to build a web UI or a CLI on top of it, so other engineers picked those up. They weren't the best solutions possible. Some rough edges, some decisions I would've made differently. But they let the rest of the team stop scripting random cURLs against the backend, and that mattered more than polish.

There was a moment when I caught myself wanting to say, "Stop, I'll do it eventually." I noticed it, and decided to let go instead of blocking them from moving forward.

That's the part that's hard to teach: knowing when your comments are calibration and when it's just control.

I generally calibrate based on trust and how well someone knows the technology or problem space. If someone's building a new skill, I'll keep a closer eye, more check-ins, more early feedback. If they're deepening a skill they already have, I step back sooner. "Good enough" looks different for different people, and that's always in tension. It's not a fixed bar, it moves depending on who's doing the work and what they're trying to grow into.

I'll admit nitpicking has backfired on me too, both giving and receiving it. I've seen people want a perfect solution before shipping anything, and the requirements keep growing to match. The goalposts move just enough that nothing ever ships. That's not quality control; that's avoidance dressed up as diligence.

If I had to give advice to someone earlier in their staff or senior track, I'd say: start letting go with engineers who are already trusted by their team, or by multiple teams. That's lower risk, and it builds your own muscle for stepping back. With more junior folks, it takes practice, and you'll get it wrong sometimes. But letting go doesn't mean abdicating responsibility. You still trust, but you verify, as they say.

Your turn

How do you calibrate when to hand-hold versus when to step back? Have you ever caught yourself nitpicking something that didn't actually need it?

Let me know your thoughts by replying to this email!

Happy coding!