title: Stop Expecting Your Best Engineer to Be a Good Mentor
author: u/Fantastic-Cress-165
contenttype: redditpost
publication: r/programming
published: 2026-02-27T04:21:13+00:00
sourceurl: https://www.reddit.com/r/programming/comments/1rfwpwp/stopexpectingyourbestengineertobea_good/
word_count: 361
[removed]
Link: https://levelup.gitconnected.com/stop-expecting-your-best-engineer-to-be-a-good-mentor-05eba3ff6c98?sk=d91cdc30a50aa785038f159d0c337370
Score: 818 | Comments: 164 | Subreddit: r/programming
Top Comments
u/BusEquivalent9605 (207 pts):
First gig, I had an insanely good mentor. Knew everything. Super encouraging. Was always happy to explain things and the deeper reasoning behind decisions. Explicitly said how cool it was to watch me learn stuff and contribute. Shout out, Brian
Since then…. the best dev has tended to be a prick who is annoyed by my presence until they realize my shit is good. Have yet to find another one I would call a “mentor.” But that’s the dream!
I would be happy to mentor! But I have 6 yoe and everyone else on my team has like 12-30+ so… they wouldn’t be into that
u/robkinyon (261 pts):
The converse is also true - stop expecting your best mentor to be a great engineer. Or your best engineer to be a great manager. Or your best manager to be a great engineer.
u/Rich-Engineer2670 (580 pts):
Yes and no....
Our best engineers are happy to mentor IF:
- You don't expect TWO 55 hour/week jobs from them -- one working and one mentoring. Make a choice.
- You don't give them absolute beginners who just took one class in Python -- they're not ready yet.
- You don't try to make this an unpaid management job in disguise.
Too often, it's one of the three and you still expect the crazy development schedules. If you just want 15% of our time mentoring OK -- but that's not what we're getting.
What we DO like:
- Self-starters who do their own work and just come when they're stuck -- just like we do to our own colleagues when we cross mentor each other)
- Someone who comes prepared with more than "I'm stuck! I don't know where to start!" It's great to see "I'm stuck, here's what I tried, here's what I got...:"
- Someone who has ideas of their own -- after all, none of us knows everything, and often, I'm the one who's clueless.
u/evilkalla (15 pts):
One of the most brilliant and effective programmers I ever worked with was a massively autistic, tactless asshole that wouldn't accept your code in his project (he'd just re-write it) or even consider talking to you about programming unless he felt like you were "good enough". Not the kind of person you want mentoring ANYONE, or NEAR anyone, really.
u/LessonStudio (14 pts):
Usually good mentors are selective as to who they mentor. People they think have potential, and they get along with them.
On more than one occasion, I was asked to help people who I felt bad because they had so little potential to become even marginally good programmers. I put zero effort into this.
Other people required tiny bits of guidance every now and then, and often taught me cool new things along the way.
All my best mentors would give me very basic guidance as to why they were going to do a thing, and made sure I would see them do that thing. I could then appreciate what they were doing so much better.
I learned from one guy the differences between management and leadership. He told me that managing client expectations was my primary job along with protecting my team from the executive.
He showed me that you mostly manage processes at factories. But people need to be lead. They need a vision to follow. This included the clients and the executive. They have to buy into the vision. You don't badger them into accepting the vision, but they all have to internalize it.
Then, people largely can self manage as they are able to filter their own decisions through that vision. As a leader, you just monitor to see that people aren't modifying or straying from the vision.
Developing the vision is a team effort, and modifying as makes sense is as well.
Micromanagers complain about "herding cats."; a sure sign they are a terrible terrible manager. Leaders have the cats follow them.
But, this is where my best mentor pointed out. If you have cats which won't follow you, is it because they are so smart they know a better place to go. Or, are they just aholes? If the latter fire them, if the former, reexamine your vision.
I learned this very well. When you have that one guy who just won't row in the same direction, regardless of apparent talent, fire them, fire them hard, fire them fast. This is not to strike terror into the team. They will usually high five each other on ahole's departure.
u/tinbuddychrist (108 pts):
I'm very unsympathetic to this perspective. Being able to explain things is part of the job. Being able to help other people grow is part of the job. Just being good at heads-down coding is not enough to be "the best engineer" at anything larger than a very early-stage startup because almost nothing of real value can be produced by a solo dev. You need communication skills and you need to be able to work with people who have a different level of understanding than you.
If you can't ask questions of a junior engineer and identify gaps in their skills or practices, how could I reasonably trust you to ask questions of your stakeholders instead of just blindly building them the bad solution they've come up with on their own?
u/PeladoCollado (27 pts):
Mentoring is a skill, and most senior engineers were never taught it. They were promoted because they wrote good code
They see the problem here, right? Right?
Good engineers write good code. Leaders make good engineers. If you haven’t figured this out, don’t try to lead an engineering organization. And stop wondering why you haven’t been promoted to Principal Engineer yet
u/KallistiTMP (8 pts):
I enjoy mentoring, as long as management makes space for it.
That has been the biggest challenge in my experience. Management repeatedly pushing for laughably impossible outcomes. "I want you to help upskill the rest of the team. Also everyone you're training will remain at 100% full time utilization, they can just attend whenever things are slow with their clients for 15 minutes at a time sporadically every 1-18 weeks. You will actually be at 120% utilization, because we don't have anyone that can handle the accounts you're juggling. Now make everyone experts with a PowerPoint presentation and a multiple choice quiz, like all the other hundreds of ineffective trainings they've already been forced to sleep through and learned nothing from."
After a few years of this I finally built up the confidence to just tell management to fuck off. I told them the training program I'd be willing to run, and that if they didn't like it then they could find someone else's time to waste. I got one cohort, it was by most people's accounts the most useful training in the subject they had ever received. After that, management tightened up again and went back to insisting on more ineffective slop approaches, so I went back to telling them to fuck right off.
It helped that the department was such a mismanaged dumpster fire by that point that I knew they couldn't afford to fire me.
Did enjoy mentoring on core work though. I was lead on a few engagements, and that did actually give me enough time to sneak some mentoring in behind the scenes for the juniors on the engagement with me.
u/yesusuckk (18 pts):
A lot of people use “good coder” and “good engineer” interchangeably, but they’re not the same thing. An important aspect of a good engineer is to become a good mentor.
A good coder is someone who can write correct, efficient, and often elegant code. They understand syntax, algorithms, data structures, and can translate requirements into working software. That skill is valuable and non-trivial.
A good software engineer goes further.
Software is rarely built in isolation. Most of the time you’re working on shared codebases, reviewing PRs, aligning on architecture, negotiating trade-offs, and maintaining systems that will outlive your current context. In that environment, raw coding ability isn’t enough.
A strong engineer writes solid code, designs systems with long-term maintainability in mind, communicates trade-offs clearly, documents decisions, reviews others’ work constructively, shares knowledge so the team becomes stronger, not dependent.
The ability to explain complex ideas in simple terms is not a “soft extra.” It directly impacts team velocity, onboarding, incident response, and architectural clarity. If only one person understands a system, that’s a liability, not excellence.
In short: a good coder can produce great code alone. A good software engineer helps a team consistently produce great software together.
The second one is rarer, and far more important.
u/Bartfeels24 (16 pts):
Never had one, and mentoring burned me out because I kept getting asked the same questions about basic stuff I'd already written docs for. Turns out being good at coding and being patient with repetition are just different skills.
u/jl2352 (7 pts):
Mentoring is a skill, and most senior engineers were never taught it. They were promoted because they wrote good code.
This is probably going to be unpopular; barring some exceptional outliers, senior engineers shouldn’t be promoted because they wrote good code.
Best seniors I’ve ever worked were decent at programming, and decent at non-programming. I’ve met plenty of senior and staff engineers who had the first but not the latter and they were all poor or shit at their job. Everyone hated working with them.
If your best engineer can’t do non-programming tasks, then they’re not an engineer. They’re a programmer.
u/dudebomb (6 pts):
All of my "mentors" were not awesome to be around. I learned from them, but I wouldn't want to work with them again. Quick to make me feel small, impatient, and essentially taught me how not to mentor.
I took those "learnings" to heart and I can happily report that I keep finding myself working with my mentees at multiple companies. They like working with me, and I like working with them.
If I was to point at any one thing to be a good mentor is to make the learning feel mutual. I like to say that my mentees got as much out of our relationship as they did from me. Even if it was simply some good laughs.
u/NoShftShck16 (6 pts):
I had a tremendous series of mentors...that were my managers when I was a dev. As I became a manager I wanted my best engineers to stop being the primary contributors to all of our projects and to start building the rest of the team up to their level. 9 times out of the 10 the best engineer has the most knowledge pool, the most code written in any given repo, and the largest understanding. It also means they are most likely to be called upon and most likely to get burnt out.
My job was to run blocker for them, help them work on their skills with people (if needed) and focus their technical efforts on larger architecture goals. Their job, in turn, was to pick one or two people to take under their wing to build up their skills and knowledge around our application so 1 go-to could turn into 3 go-tos.
But at the end of the day if you have no interest being a people person, or collaborating with your colleagues, and you just want to sling code, that usually isn't ideal for the health of the overall team either.
u/umlcat (19 pts):
Knowing things and knowing how to teach the things we know is a very different thing ...
u/gelfin (5 pts):
Speaking as someone who has authored and piloted a formalized mentorship program in the past, I don’t think that thing I did is in any way ideal. Not everybody needs help in a prescribed way or for a prescribed period of time. I’m told I am good in a teaching/mentoring role when it happens organically, but we are talking about taking something that works best informally and fitting it into an assumption that only structured work counts.
So why did I do that thing? I did it because I was helping people anyway, but in order to be “fair” raises and promotions are contingent on stuff that’s documented and measurable. And that’s not an entirely unreasonable thing. An evaluation process without defined standards tends to become a biased process, whether that’s actual discrimination or just the sort of popularity contest that takes more notice of some people’s accomplishments than others. Also, as some people have already noted, if mentorship is not recorded as work, then you’ve got to pull a full load of recorded work on top of the mentorship, which just punishes your mentors.
So I understand the reasons for formalizing processes, particularly when not doing so entails some legal risk, but that unavoidably ends in a one-size process by which there is only one officially approved way to excel at your job, and one which trades inadvertently ignoring some contributions for explicitly ignoring contributions that do not tick a box somebody previously thought to include on a list while also requiring things that might not make sense for every individual. Not everybody on your staff needs to be a blogger or a maintainer of an open source repository, for instance.
If you squint at these formal processes you can tell yourself that the right person will automatically tick all those boxes and that those requirements represent values you wish to promote. In practice it reminds me of that story where the Air Force designed a cockpit around the mathematical average of every pilot in the service and ended up with an airplane that fit nobody.
On one hand you’ve got to fairly and consistently recognize people for what they do, which does not happen by good will and wishing alone. On the other hand, a one-size standard just does not reflect the nature of people, and people who are working to check a box are less effective at that than doing whatever comes naturally to them. I am not remotely claiming to have a solution to this dilemma, but constantly reminding ourselves it is a dilemma is more humane than installing some technocratic ass-covering regime and calling it a day.
u/Boognish28 (25 pts):
Hard disagree. Note - I don’t have brain to read the full article and I’m reacting purely to the title here.
Teaching a concept well takes the ability to understand a subject so well that you can distill it and communicate it to a variety of different learning styles. It’s a combination of depth of technical understanding and communication skills. You have to communicate to your audience while also knowing the subject matter enough to perform that translation on the fly.
At the same time, software engineering at its basic level is taking a concept and communicating that to a computer using a specific and specialized language. Passable engineers can do this in a single language. Better engineers can do this in multiple languages. The best can do this in programming languages and human languages.
u/baneeishaquek (6 pts):
I am mentoring a team two developers on React. Both almost equally experienced according to their resumes. But, one is previously worked on a system from A-Z. So, he can patch up things from root cause even though he is a little lazy about coding guidelines and security practises. The other one is previously worked on surface level on a fully developed system, she can do things in structured & standardised way. But, she is not good at debugging & analysis - and sometimes she can't even find the cause of bugs. But, she is a quick learner and learning things fast. So, I am happy with the team.
I also mentoring another team of 4 developers on NestJS - React - Flutter. The developers are working in intern positions & paid very low. SO, their commitments are horrible. But, the flutter developer is good - and she is a fast learner. Also, the senior MERN developer is good - he is the most paid guy - and he is faster. But, there are other two MERN guys - they can't catch up things. There are other 6 testers - 3 of them are seniors - one of them is paid. Their testing is in an average level. Other 3 of them are interns - Their work also ok. On the above of all - There is a project coordinator - she also good - and she works as client support too. Even though mentoring that team (3 MERN developers, 1 Flutter Developer, 6 Testers, 1 Project Coordinator) is a pain - I took that a challenge.
So, as of my experience, "Are you good mentor question & are you enjoying it question" are highly tied to the behaviour of the team you are mentoring. It also varies time to time (according to the progress of the team). In a painful environment - all we can do is try our best.
Another thing to mention here is: The management of first company is really cool. They understand well & supports well. But, the second one is horrible. they things like coding is a cheap skill, any one can do with a bunch of AI tools. And the developers are very cheap - they don't have to paid at all. So, I also thinks like: This is the best they can get.
u/JustCallMeBen (9 pts):
If someone can't effectively share knowledge they're not your best engineer: they're nothing but a liability. If you can't transfer knowledge effectively, you can't get other people to understand what you're saying in arefniment, you can't convince people during estimation sessions of why something is actually more or less complex than they think, and you can't make sure they effectively review your code. What this means is that you won't be working in a team, you'll be working as a demagogue in a team you expect to follow whatever you say "because you're the best engineer", without bothering you to make them understand why.
I utterly hate this "rockstar developer" mentality of people that can only work solo, and scoff at the idea of having to work closely with less experienced engineers.
The article doesn't talk like that, but the attitude "well I'm a great engineer and I simply don't have the skills to help other people so don't expect me to do so" is basically the same but in a more lazy way.
Sorry but I don't buy that. Anyone can learn, to a decent degree, how to mentor colleagues. If you say you can't, you are saying you don't want to become a senior engineer. Which is fine. But don't kid yourself and pretend like you can then be considered "the best engineer".