DEV Community

Cover image for Stop Expecting Your Best Engineer to Be a Good Mentor
Simon Wang
Simon Wang

Posted on • Originally published at levelup.gitconnected.com

Stop Expecting Your Best Engineer to Be a Good Mentor

My son didn't understand how to convert a fraction to a decimal.

I explained it. He nodded. I could tell from the nod that he hadn't got it.

I explained it again, differently. He nodded again. Same nod.

By the third time, something in my voice had changed. I wasn't shouting. But I wasn't not-shouting either. My face was doing something I couldn't control. He could see it. He's eight and he's very good at reading my face.

So he stopped trying to understand and started trying to guess. If he got the right answer, the face would stop.

Is it 0.7?

No.

0.3?

No. We're not — that's not — look, you divide the top number by the bottom number. One divided by four. What's one divided by four?

He didn't know. He was too busy watching my face.

I know how to convert fractions to decimals. I've known for so many years yet I have no idea how to easily explain it so he gets it.

I learnt there's a concept in education called the curse of knowledge: once you know something well enough, you lose reliable access to what it was like not to know it. The knowledge changes form, and it becomes automatic, compiled, and below conscious thought. You can still do it perfectly, but you just can't remember learning it. Same as riding a bicycle or driving a car, knowing how to do it doesn't mean you can teach it.

I know fractions. Teachers know how people learn fractions. These are not the same knowledge, yes we often assume they are.

That's the root of our mentorship concept for software engineers, and then there's everything else follows from it made it worse.


Often it goes:

The calendar invite says "1-on-1" The first five minutes are catching up chit-chat. The next half hour are project status. How's that feature going? Any blockers? What does the timeline look like?

It's not that the senior mentor doesn't care. It's that they've arrived at the meeting without a plan, and "how's the project going" is always available. It fills time and it feels like support. The junior leaves thinking they've been mentored and the senior leaves thinking they've done their job.

Only once in a blue moon the randomness hit a jackpot, and it depends on if there's finally a lightbulb moment from some repeated things they discussed that barely scratched some itchy surface, and then they got it, thanks to their mentor! Both side think that's all there is about this relationship.

Mentoring is a skill, and most senior engineers were never taught it. They were promoted because they wrote good code. Then they were handed a junior and expected to know what to do with them, and it's called mentorship. We put the junior near the senior and hoped something would move through the air.

Sometimes it does. More often it doesn't.

It could get worse though.

When a senior genuinely tries, sits down, prepares, comes to the 1-on-1 with intention, they need to figure out what the junior needed the most, so they want to listen and answer the questions asked.

Then the questions asked are always technical.

How do I approach this algorithm? Should I use a queue or a stack here? Why is this query slow?

Good questions. The senior answers them well. The junior learns something. This looks like mentoring and in a narrow sense it is.

But the junior's actual growth blockers are rarely technical, because not necessarily there need a mentor to answer any of those, they can simply ask around and get the answer, in old days it was stackoverflow, now it could be a message shoot to AI, why do they need you?

They say yes to every request and are quietly drowning, think all there is to tackle problem faster with the most efficient way there is and one day they will become senior. But they might have never seen how a senior actually thinks through ambiguity, only the output: the confident answer, never the twenty minutes of uncertainty that came before it.

They might not ask about any of this because they don't know they exist! You can't ask for help with a blind spot. Manager said this should be done on Friday and I give my promise, so I will just get this done, if I couldn't it means I'm not good at estimation or I'm just too slow so I should use AI more to boost my productivity. How often do you think they would ask: "How do I manage people's expectation here?"

The senior answers those questions. Oh estimation is hard, you do T-Shirt sizing, you pack it with a confidence level, you use that online tool with multiple people voting a number etc etc. But the core problem might be all the words used by the juniors projecting over-confidence because they believe in "you fake it till you make it" so deeply but they might never bring that up!

Both leave satisfied. The invisible curriculum stays invisible.


Another thing is, the mentor who actually works not necessarily are the one with the most knowledge or skill, or who delivered the project fastest.

It's the ones who can see what the junior can't see, it not only takes skills, it means watching not just what the junior does but what they don't notice they're doing. It also demands the time to observe closely, give feedback as they go, and tailor what you say to where they actually are.
Let's not forget all that also have to based on having enough distance from your own expertise to remember what confusion felt like, and somewhere in there, the patience to make the invisible visible, without being asked.

That's really rare. Most senior engineers don't have it, not because they're bad at their jobs, but because nobody ever asked them to develop it, and rarely any of them got taught about that either. People just struggle with their years of experiences until they get it.

There is a long-running saying that doesn't help: "Those who can, do; those who can't, teach." I got heavily influenced by this kind of thinking until I became a self-aware frustrated parent. I bet it shaped how the industry thinks about this whole mentorship thing too. Teaching is what you do when you can't perform anymore, it doesn't need additional skill, you can just do it, and if you are our best developer surely I will push you to mentor the hell of the rest to replicate you, it came for free easily isn't it? But is it though?

You've been the kid watching the frustrated face, trying to guess the right answer to make it stop.

You've probably been the frustrated face too.

The system didn't give either of you much to work with.

What do you think? How could this be better?

Top comments (0)