limited·by·sleep
$ cd ~/published

I know how the conversation will end before they've finished explaining it

A junior engineer wants to try something I've already watched fail, and I know how the conversation will end before they've finished explaining it. I'm usually right. That has become part of the problem.

I've been doing this long enough that most of the ideas brought to me aren't new to me. The framework that will fix everything, the rewrite that will only take a few weeks, the library we could build ourselves. I've had those ideas too, and I've paid for some of them.

So I jump to the conclusion. I say don't, I lay out the reasons, and I'm often right about the outcome. Where I get it wrong is the moment itself. The understanding of why they wanted it, what they were reaching for and what it meant to them, usually arrives later, when I'm replaying the conversation and it's too late to have it the way I should have.

I do go back. Sometimes we find a middle, they take on the part they're ready for, and we discover together that the rest is a much bigger job than it looked. That works, slowly.

What I haven't resolved is the other half. Some days the long way round feels like teaching the same year group again, and I want to spend more of my time on problems I haven't solved before. Both of those are true at once, and I haven't found a way to make either one go away.

I suspect plenty of people a few years into senior roles feel this and keep quiet, because it sounds like impatience with the people you're meant to be developing. For me it's closer to the cost of having been around long enough to recognise the wall, and I'm still working out what to do with that.

follow via rss