How to mentor software engineers
xdg.me
xdg.me
^ This is one of the first lines in the article. If I had to guess I'd say most people here spend a relatively small amount of time learning about how to do their job vs actually doing it.
For me this is a good reminder that actively/intentionally investing a couple hours per week in learning about how to do things - technical or not - and evaluating myself will probably have a higher ROI than spending those hours doing the thing
This reminds me of some of the ideas discussed in this post [0] from a few days ago.
It’s a great motto and easily taken too far. Often the best way to learn is to get started. Tacit knowledge is best learned by doing.
I've sometimes been that person.
all that said, i completely agree with you that this is not a good motto for a novice at work -- if you are capable at handling an axe, having it razor sharp is going to markedly improve your results, but if it's your first go at swinging an axe, i really hope you don't spend 80% of your time fiddling with a sharpening stone…
It has some parallels to most skills, as most times you will only discover your deficiencies by doing it. But it doesn't mean you shouldn't train, it only means that training without ever practicing won't lead you anywhere.
And sharpening a dull axe can take an hour to half a day. [2]
1. http://rockymountainbushcraft.blogspot.com/2012/08/how-sharp... 2. https://www.fhwa.dot.gov/environment/recreational_trails/pub...
If you haven’t seen it, how do you do it?
You're not there to set hurdles. You're there to recognize when someone is fighting the upstream flow or have embanked themselves in temporary enlightenment.
This is really good! Thank you =)
I've had some really bad mentors!
Maybe the author definition is from sports, but outside it here is how I see (and how many of people that I encountered so far see) the difference between coach and mentor:
In a coaching relationship the coache sets the agenda not the coach. The coach is more backseat than a mentor. The coach is there to walk along the coachee on the coachee path while providing guidance when asked, usually in the form of guiding questions or helping navigate various points of views or helping go through decision frameworks.
In a mentor relationship the mentor sets the agenda together with the mentee. A mentor has a more active role in the agenda providing active guidance and feedforward. The mentor and the mentee walk together on a path they both agreed on.
As an example:
If I would go to a coach and say ask about should I learn Elixir or not taking into consideration my Ruby background, then the coach will not answer yes or not. But should help me discover for myself the answer. It will usually help me look at this question from various points of view or can provide a decision framework, but the answers (or the content of my answers) will always be mine or my own discovery. So they will not state "Elixir is like Ruby" or "Elixir is not like Ruby" but they might ask "How can you assess if Elixir is like Ruby?" or "What is the smallest project that you can create to see if you like Elixir".
If I would go to a mentor and ask about should I learn Elixir I expect them to tell me pro and cons of Elixir and also have an opinion about if Elixir is really similar with Ruby or not and even express their preference for this programming language or the other.
So I choose to go to a mentor or coach depending on what outcome I want to have and what experience they have.
PS: Please take the Elixir and Ruby just as an example of a technical matter to be discussed with a coach or mentor.
Given that people hire coaches, but usually not mentors, the distinction for me is that a coach is engaged towards a goal and therefore is more directive of what you need to do to get there.
I don't think your example question is a great one for exploring the distinction because it's a single, binary question. But even in your example, despite the coach responding with questions, you describe the coach as pushing you to go do some work: figure out the differences yourself, or come up with a project to explore the question.
In that sense, I see the coach as "setting the agenda" whereas the mentor is having a more open-ended conversation about it.
Let me try to rephrase it in a way:
I think the main difference for me is that I go to the coach to support me to solve problems/matters by myself and they are there supporting my process but I expect them to have less influence on the actual content/solution itself. To summarize the coach does not give advices nor they should impose best practices.
While I go to the mentor expecting them to offer me advice and guidance/best practices.
In this I choose (very rarely) a coach to explore problems that I think don't have a universal solution or the solution is subjective like “Should I move to management or continue on the technical path” or “What is best for me: freelancer or employee?”
And I go to mentor to get concrete advice/guidance on specific matters like “How to increase my income as freelancer” or “How to start a new career in X”.
As I write this it seems that for me I see coach as a person that can help me discover the why and the mentor is someone that can help me discover the how.
That's not how I see it, but you expressed that really clearly. If that distinction works for you, then that's great!
So in that sense a coach would not set the agenda at all, nor be directive of what you need to do to get there, quite the opposite in fact. They keep asking questions and pushing you to figure out what you need to do to get there, which means that a coach can theoritically help you even if not in the same field as you.
You said: "they keep asking questions and pushing" -- that's what I mean by setting the agenda. As I mentor, I don't see my role as "pushing". Questioning, sure. Providing perspective, sharing my stores, yes. Actionable feedback on skills is the closest I'd come to "pushing" and even then, they can take it or leave it.
When I see people talking about coaching, I often see -- directly or indirectly -- some aspect of the role of the coach to be to "bring out their best". I rarely see words like that used to describe mentoring relationships.
As the coach is mostly hired and the mentor internal it might be that the coach has more incentive to push someone to bring their best while the mentor - having as main focus another job and doing mentorship as a side task - will offer advice/guidance but will not have the same incentive to follow through.
Anyhow I agree there is not a standard definition of what a coach or mentor is and what they should do.
coach: one who instructs or trains [2]
When there's some doubt about meaning, I find it useful to wonder how other people might interpret the words I say, and I have found that a dictionary is a good way for communities and societies to agree on what those words mean. I do not say this to be snarky. I used to be surprised to learn that some words I thought I knew had a different, if related, meaning. Now, if say I was presented with an article that I wanted to comment on its use of words, I will look up those words first to see if perhaps I am the one that is out of touch with my peers.
I am a mentor, a mentee, and have had life coaches and sports coaches. While I have paid life coaches, i.e I am setting goals, that's very different than a coach within a corporation: perhaps the distinction for coach is "Who is paying the coach?" A mentor, however, is very much a counselor / guide, even though they are paid by the company. Another distinction is that coaches are, to some extent, accountable. They are paid to achieve a result. Mentors just don't have the responsibility.
I get it in your other comment that it helps you set your expectations—but it’s not like these two words are technical jargon with clear meanings in some field of science, so you can’t just take them without nuance.
I never was or had any formal mentor or coach, so there is that.
For me the name is important mostly related to setting my expectations about what can I get from working with one or the other.
Most 1:1s have been driven by me, at the explicit behest of the manager. "I'm here for you" and "this is your time" are/were common phrases. I found this particularly annoying as a new grad when I really didn't know what I didn't know and just wasn't getting a lot of mileage out of those conversations.
The reason is because even if there truly is a simpler way, it isn't always simpler for someone in their current position based on their current biases/experience/knowledge/etc. But what you WANT to do is a really powerful motivator and the most important thing is that you keep trying things and get better eventually.
Yeah this is what I don't agree with. As a leader, you act as a shield to the people that report to you. You may be privy to information or have a better view of the overall big picture. Sometimes there are burdens you don't want to put on the people that report to you. We can only be so transparent a lot of times.
Theres going to be times where you'll need to have them align with overall company goals etc.
What you're describing is just a manager.
If this sort of mentor needs something from a mentee, that's a conflict of interest. (People use "mentor" to describe different relationships though!)
In my personal experience a good mentor will never patronize but will still manage to convey their, usually higher, expectations for kind and quality of your work.
The best mentors I've had were also extremely good at receiving and processing feedback themselves because they honestly loved learning and wanted to be better as much as I did.
I'd had number of mentors, and myself almost a decade of experience teaching technical classes and 1:1 private lessons before I got into mentoring other SDEs at work and was amazed by how much I learned even just from first few relationships.
Coaching and mentoring really are so different.
I have definitely seen organizations where either the culture or the "climate" all but prevented effective mentor / mentee relationships no matter the effort. Really don't miss working at those places, probably the most burned out I had ever been in my career.
L5 mentors L4 who mentors L3 and so on.
Related, more cynical take - being a mentor is often a factor in promotion & hiring, and being viewed as a mentor will make you more likely to be promoted or hired.
In software development it is even more egregious because, due to exponential growth of number of developers, most developers haven't had a chance to work with a real, good, expert developer.
You need probably at least 10-15 years and more realistically about 20 years to grow to be expert at your field. And even then only small percentage grow to be truly experts, the rest become stuck somewhere along the way.
How do you asses whether you are mentor material if you've never seen a real deal?
You don't hear people who decided they are not mentor material yet -- you only hear from people who did.
So this is the false positive problem -- given even small chance of false positive on deciding you are mentor material, given huge population of developers and very small population of actual good mentors, you are bound to have a lot of false positives.
You don't need to be an expert mathematician to be a great Math teacher; you don't need to be a happy well-rounded person to be a good therapist.
- have the knowledge (duh!)
- have the experience to have had enough time to observe things in reality (vs theory) and have had the time to internalise and digest all of this
- be mature
While it is easy to get the knowledge, the rest usually cannot be skipped so easily.
As to math, that is not a good example. Math is almost pure knowledge and intelligence and so a bright kid can acquire that knowledge and quickly pass to his peers assuming they are intelligent enough.
Unless you really mean Mathematics. Like how to advance the field. Then it is not as easily transferable knowledge. I know, I studied theoretical mathematics.
Software development is only in small part driven by knowledge. If you think software development is knowing programming languages and frameworks and AWS and certifications you are waaaay off the target.
I don't think I would've been able to right my career had I not had a dev with about ten years experience mentor me for a year. Granted, he might be an edge case since he learned teaching before becoming a programmer, but nonetheless his empathy and encouragement on top of some lived experiences was invaluable to me.
I have this model where you can get regular help with what you want and mentor help with what you need.
Mentor will be mature and experienced enough to be able to recognise your particular needs and be able to adjust to you. Mentor will be able to understand their own limitations and adjust for it, too.
On the other hand, experience is mostly orthogonal to technical and pedagogical skills. After decades of experience I've seen mentorship come in many forms, and I would never put some kind of litmus test on who is qualified to be a mentor. Ultimately it's about individual strengths, weaknesses and chemistry.
Of course, maybe I'm rationalizing and it's just that candidates who aren't fresh out of college need to claim some leadership credentials, and they don't want to lie and say they've formally led or managed anybody, so they just make vague statements about mentoring in the hopes that you check the right box on the hiring rubric.
Re-reading: code review is coaching I think. Because you're asking for directed feedback, not general life advice.
But if an engineer approaches me and says "in my last performance review, I was told my code isn't very well structured; can you help me?" and I walk through their code with them, then I'm mentoring. It's skill mentoring, in this case, which, as I said, has the most overlap with coaching. Same activity, but different context.
But as someone else said, this distinction isn't really the important part of what I wrote. So if people disagree on the terminology, that's just fine.
The way I think about it is that it’s coaching if you are making decisions for them about the path they should take. It works here because writing code is a fairly general skillset.
With mentoring, the crux of the problem is that you’re trying to help them navigate their specific situation. And in my experience both as a mentor and a mentee, “where are they trying to go and what do they really want?” is actually the hardest part, and it’s not something you can consistently answer because it’s their experience and you’ll never fully understand the nuances of it. You can’t lay out the path for them, you can only (try to) help them see further down the path they’re already on.
If the developer is young/new and you are reviewing their code expecting various mistakes that you can then "coach" them about, it could be part of coaching. However at other times, code review is just what you do as a second pair of eyes, you are not expecting to give coaching as a result of something you might spot, just feedback.
I wouldn't worry too much about specifying things too specifically though!
> Code review is part of the job
Weirdly, in one job interview they asked if I was willing to mentor junior devs. I said yes, they hired me, but the subject never came up after that. In another, the topic never came up at all, nobody approached me for mentoring at the job, but my management later hassled me about missing their expectations about it.
The article is generally pretty good.
To me, asking a prospective senior engineer if they're willing to mentor juniors is equivalent to asking "are you willing to put in time and effort to help juniors learn how to be better engineers?"
I imagined in-office mentoring as being something like meeting with the person for an hour or two a week, looking at the current state of their project and making comments, doing some pair programming, that sort of thing. I've received lots of informal mentoring myself in that way, so I was looking forward to doing it. But it never came up.
The best mentor I ever had helped me orient myself when I had no idea what I wanted to do. My answers were always, "I'm not sure. As long as I'm actively developing, I'll likely be fine." This wasn't quite true. Working on feature sets that didn't make sense with the code's architecture only to be thrown out 3 months later was rough.
She was the one that encouraged me to work on skills during work hours. No employer is going to miss 1/40 hours when it's used for professional development that directly benefits them. She encouraged me to stick with learning new things when I was ready to phone it in. AWS certs aren't hard to pass, but I probably wouldn't have taken the test without her push. I would have never dipped my toe into management. I found that management wasn't for me, but it was a better experience than resting on my laurels for a year.
A good mentor is like a good friend checking in on you from time to time, but the relationship is professional. Everything pertains to your professional goals (or in support of) from a place of wanting the mentee to succeed.
An interesting observation, and while you could say it's less efficient if you're the latter type it seems there are other benefits.
While I may have more flying hours in some topics of life or work, even a younger and/or less experienced person in some ways, can teach me something in other ways.
Building each other up makes for very rewarding bilateral relationship.
Like when someone misspells radical candor in the second sentence of a blog post about mentoring.
Seriously though, everybody makes mistakes but when I do slip up like this I don't expect people to engage with what I'm writing. And I do think proof reading is an incredibly important skill for new and experienced software engineers.
[edit] I just noticed the author is a staff engineer at MongoDB. He can misspell whatever he wants. I recant my sassiness.
And now I've discovered that vim spell check skips words with leading markdown symbols like `*randical`. I'll have to dig into that more.
Update: pasting the web page to Google Docs found a few more typos. I fixed those, too. Usually I print and read to find typos, maybe I skipped that this time. Good reminder to do that and the Gdocs review. Really: thanks for the reminder, regardless of the sassiness. :-)
I really am sorry for being a troll and writing the kind of comment that bums me out on a regular basis. This seems like a good post and a good discussion.
It can just be frustrating for those of us that have a hard time getting traction when we post projects etc on sites like HN. It can manifest into petty toxic behavior especially in comment sections.
In the words of Paul Doherty... "I'll do better next time."
Taking a quick look, for me it seems that (Neo)Vim spell check skips anything in italics or bold. No highlights whatsoever anywhere in that region. Definitely not something you want to realize _after_ publishing articles!
Edit: Considering the comment about using :syn off, seems like this is probably a conflict of some kind with the way Vim actually italicizes/bolds things in terminals that support it, now.
‘aspell -c text.md’
Also, I found that `:syn off` gets vim to spell check within markdown formatting.
Some are burnt out and unable to focus.
Some have dyslexia and are trying harder than you'll ever know to proof read.
If someone is burnt out, the attitude is typically the tell regardless of care. It's deliberately sloppy.
One of the best engineers I ever worked with had dyslexia and by God if his class names weren't the funniest things I've ever seen, but they were consistent and the structure and documentation was thoughtful.
Unfortunately, over 12 years, I had two spelling mistakes slip through my hours of editing and proofreading. Some people absolutely eviscerated me for it. I mean, how could I not know how to spell X word? I must be a moron! In my opinion, these "simple-to-catch" errors are not always simple-to-catch when the writer knows what it is supposed to say and they are trying to proofread their own work.
That said, it proves you're right -- people do think less of you when you make such a mistake. I think we should all strive to cut people a little more slack, at least on Slack.