The Senior Engineer’s Guide to Helping Others Make Decisions

Totally agree there, sometimes there is room for learning and mistakes but not everything must become a learning opportunity otherwise nothing will get done.

I'm currently raising a toddler and find great parallels there compared to coaching a junior. It's always good to explain why something is bad/wrong to my kids and allow them to learn. But if w're in the middle of crossing the road that's not the time and place.

There are so many events in life that shape us, looking back at myself at my earlier career I can't understand how I got where I am now with how stupid I was then and the opinions I held.

I think it has a great deal to do with being able to see things in a different way and having the experience to be open for certain ideas. But I currently still have a hard time at recognising this in myself or others. And allow to know when you can go for the next step.

The real way a senior engineer trains juniors is by selecting appropriate work. They thread the needle of a number of factors: it needs to be done, its within reach, will build their skills, will educate them on product/business/process, they will find rewarding, will give ownership, relevant staff can support them etc. These factors are so important that the senior engineer might need to negotiate with the product manager to bring appropriate work forward to avoid failure or killing the enthusiasm of the junior.

What can't really happen is for a junior to suggest work. The experience and context they lack is for the business, the user and the strategy. The junior's biases for what they think matters are usually much worse that the senior's for what works e.g. they want to improve cosmetic factors or add cool features. Its not that they are wrong, the product might be offensively ugly and the cool features might be game changers, but professional development is a parade of gut wrenching compromises because the constraint is time and resources not imagination and ambition.

That said, I agree with the thrust of the article - the risk of senior engineers "fighting the last war" and accruing a set of limiting beliefs is very real and the naive optimism of a junior challenging them is part of the value they bring.

> Being a senior engineer means realizing not everything should be done the way you want it to be.

A real corollary is, you really don't know as much as you think you do sometimes.

That’s a good observation. I’ve also worked at organizations where the policy pendulum swings.

For example, “Gotta release code quickly” to “quick is good, but all code must have unit tests and rigorous code reviews” to “gotta be quicker, can’t always be holding things up because of a rejected code review!”

I’ve also worked places where that didn’t happen because management, and the engineering culture, were strong.

This methodology is an effective way to leverage the developers in your team. It does rely on a certain discipline that juniours often don't have to drive and refine an exploratory solution into production code.

It requires curiosity, an openness to measuring and validating an idea and then driving it home. This sounds a lot like what I'd want from a team lead; but as someone pointed out some juniors aren't destined for leadership either.

I love the idea and have made it work, a lot less though than desirable.