Developers mentoring other developers: practices I've seen work well
blog.pragmaticengineer.com
blog.pragmaticengineer.com
I spent a lot of my early career crawling around on linux servers trying to fix weird bugs in pretty typical web stacks. Later on, when other developers needed help diagnosing an issue on a server I would say something like "sounds like X problem, look at the log file in Y". After several years of this, the same devs were still asking the same questions. I was helping them solve immediate problems quickly and easily, but I was not mentoring them.
Developers don't grow by being given the answers. They grow by trying things and experimenting and solving problems themselves. These are the skills and the lessons that will serve them well as they level up their career. Not giving them the answers but giving them the tools to find the answers.
These days, if there's no urgency, I would say something like "where are the places in the stack where a problem like that might occur, and what can we do to narrow down the set of likely issues?" I might give them some ideas, but let them do most of the legwork.
I have yet to see a more effective method of teaching developers, as this encourages understanding and learning about underlying concepts and problems
This is also part of the reason why Stackoverflow is in such a negative light lately. SO is extremely good at providing answers to narrowly-focused well-defined questions, people forget or aren't aware that this IS NOT a good way to learn subject-matter. It leads to frustration from users because they're expecting someone to give them pointers on how to move forward on general problems and it's frustrating to point-mavens because they aren't empathetic enough to see what the problems are.
[0]: https://hackernoon.com/the-decline-of-stack-overflow-7cb69fa...
[1]: https://meta.stackexchange.com/questions/333678/was-the-retr...
Usually, at least for .net, there are explanations not only how to do something, but why do it this way.
I learned quite a bit from SO, it at least pointed me towards right direction in docs. Nowadays i just read the docs instead, but i still google for SO answers for new problems.
Maybe there is an API i have no idea about ,nor my colleagues do? Maybe there is a better way to solve problem XYZ?
Instead of skimming myriad of blogs i can just read the answers on SO and then read up the docs.
SO is as good, or bad, as you make it - if you just copypaste answers, or provide an answer in form of code with minimal explanation why - then that's on you.
The kinds of questions that people ask when they're focused on learning something new, however, are DEFINITELY NOT what SO is intended to handle. It is why SO is actively hostile to people that try to use it to learn by asking questions.
(1) For .net in particular, Jon Skeet's answers are magnificent resources. He even made the content from his answers into a book. The book, of course, has context and coherence. It's not just the answers copy-pasted into a text. Sadly, Skeet is the exception rather than the rule. For everyone putting up nice answers to questions following the example of Skeet, there are dozens of smug, persnickety jerks making people feel like shit in a hundred different ways for daring to ask a question.
Exactly, at this phase of learning go and read other questions and answers related to your topic instead.
Jon Skeet is a goddamn national treasure.
When I first started, I was really shit at finding bugs, didn’t understand the total scope of parsing (used in almost every oop method / solution), and general searching how to solve a problem.
I started watching some coders, specifically geohotz, on how they search problem parameters to find solutions, and how they implement solutions. There seemed to be a gap in my investigative research that was filled by watching others investigate and solve sophisticated problems. Ie; implementing ai api in python, really showed me how to take the general knowledge you can learn from documentation ie git or more official places like Microsoft docs and apply it to specific problems that may not have been directly related.
I think, if there is a way to explain and show a junior your thought process and problem solving process while keeping a great mix of allowing the junior to solve themselves as well, there can be great benefit. The hands on approach as described above requires a lot of time and attention, maybe time most senior devs do not have. It can be very beneficial. Maybe some paired programming sessions where the senior works on his sophisticated problems and allows the junior to watch, while also introing the junior to the scope of problem trying to be solved.
A couple of years ago I wrote a blog post on "Would Socrates to use Docker today?"[1] which uses Socratic Questioning to help pick a tech choice. If anyone is curious on how to apply it to technology, that post goes into a bit of detail. It could also be directly applied to solving specific programming problems too. I use it to make a lot of decisions.
[0]: https://en.wikipedia.org/wiki/Socratic_questioning
[1]: https://nickjanetakis.com/blog/would-socrates-use-docker-tod...
[1] http://www.pearlleff.com/seven-tips-for-a-junior-developer
If they got used to your service this might annoy them, but if you explain it beforehand..?
But yeah, he did sit with me beforehand and explained how he mentors people.
I have had two such mentors.
I am extremely suspicious of any such one-on-one arrangements when there are no written records and opportunities for challenging unfair assessments formally. There has to be second opinions from disinterested parties.
Now imagine an office politician who relays to you bad things other people said about you, and relays to others bad things you said about them, and encourages retaliation between staff. I have worked with one such person. Again here, under the guise of mentorship of one-on-one feedback there is a lot of gossip being generated.
I can already predict that there will be more people who think they can mentor than people who think they can improve.
Two in particular were only a few months ago and it still confuses me if I think about it. They did every single thing you mentioned, mostly in private, no written record of any of it, moving goal posts, sometimes really scraping the barrel when looking for negative feedback.
Sometimes it would be in public too - really petty stuff. Sometimes it was basically “Oh, you’ve forgotten that one particular API of the framework we know you haven’t had to use for over a year? Fuck you, you are incompetent.”
I’m starting to think I was hired specifically to work on all the projects no one else wanted to do, while dangling the interesting projects like a carrot.
I too am now extremely suspicious of any one on one arrangements - by nature they are specially designed to favour the organisation without fair representation for the employee their are victimising.
On the other hand, I would decline to mentor you:
> I am extremely suspicious of any such one-on-one arrangements when there are no written records and opportunities for challenging unfair assessments formally.
I'm not interested in wasting my time with a mentee on bureaucracy instead of actually mentoring. Luckily, there are many different workplaces we can pick from, so your need for proper documentation can be satisfied while my wish to use the time for mentoring is also satisfied (possibly in different places).
> I can already predict that there will be more people who think they can mentor than people who think they can improve.
I love to be a mentee. It usually feels better to learn than to teach. It also increases your value more. I quite often struggle that I don't have a mentor (and it is a good reason to change workplace). As compensation, I frequently send out mentees to learn new stuff and teach it to me.
Here's a thing. If both of you knew each other personally, started becoming friendly, then you might end up mentoring GP and I'm sure GP wouldn't demand written records. This is how mentoring looks like. It's not some top-down prescribed job task, and it's not done by matchmaking.
However, I agree that in order for mentoring to be formal it has to be written down, or at least the progress tracked.
Also, where is your manager if you can't report to him such bad things? I think that the bad mentors you had are a consequence of a bigger issue you had at your company.
I have a close friend who were harassed by a colleague, but only when they were 1-1. Whenever they were in a group, the harasser were the friendliest sunshine you could imagine.
Everyone my friend talked to would not believe them, and instead started questioning if they were feeling alright.
There are still companies that give a shit about this sort of things. Depends obviously on who is the perpetrator. (... sadly enough).
Mentoring should be voluntary and should just be about helping someone else on the team.
I totally get the benefits of getting advice from more experienced folks, but you can do that ad-hoc so I just don't see the point for formal set ups and have chalked it up as something that someone somewhere in the organisation thinks is useful that everyone should do - kinda like all the bullshit "team work" or "what colour are you"/"look inside yourself" training courses that we are all required to take from time to time but no one actually wants to do and are a 100% totally pointless exercise.
I agree with your point about "forced" mentoring though, some people just don't like to mentor so they shouldn't have to, but an organisation should encourage and reward it if it happens voluntary.
I still feel we could have more structured, formal training but don't know how.
In my experience I have benefited from being on both sides of the mentor-mentee relationship. I learned a lot from mentoring an intern, especially.
OP was fine.
Now that I'm middle-aged (39), I'm one of the few older guys working amongst a large number of younger folks. Formal mentorship and leadership development programs (so you can be promoted past the Gen Xers we're currently targeting for layoffs) are real things now focused solely on the younger generation...
Any other Gen Xers feeling cheated?
I’m unlikely to be called Gen X, but my attitude has always been the same: it’s our duty to make the lives of future generations better than ours. Raise our children better than we were raised. Provide our juniors the opportunities and resources we didn’t have.
So, I don’t feel cheated. I feel happy because my efforts are helping future generations.
The thing to remember is that we are a small generation sandwiched between two big ones (baby boomers and millenials). We never got to move the needle as much culturally as these two generations did.
The boomers set the rules, which we begrudgingly followed. And the millenials are breaking the rules and we have to roll with that too.
Sometimes it feels like we are caught between both worlds, and forced to choose a side where we only agree with them 50% of the time.
I'm about the same age (38) and I guess I count myself as a millennial. I'm certainly considered a millennial by everyone older than me. I'd always heard the cutoff between Gen X and millennial was 1975, but now that I search I'm seeing '82 or '83 a lot. That doesn't fit with how I typically see the term used, though.
That having been said, I feel like there were plenty of mentorship programs when I was first starting my career, but I haven't worked for too many pure software companies. It may have been very different in actual tech companies. The more traditional corporations I've worked in tend to be big on formal mentorship programs.
Excuuuuuuuuse me?!
Barring a cure for aging coming along within the next few decades, I'm right about in the middle of my lifepsan.
That said, technically capable mentors who actually care about mentoring can be great, I’m just not sure about top-down forced mentoring as a career requirement.
Tell that to all the people in this thread who thought I should accept my company's top-down mandate to do mentoring: https://news.ycombinator.com/item?id=21229910
Indeed, it feels like saying "oh you two are gonna be friends!"
I feel there's a confusion around terms. Life is a bit more complex. Mentoring is a rather specific thing, and 'real' mentors are a rare (and precious) relationship; it's long-term (at least in perspective, however long it actually lasts) and much more emotional in that there's admiration (reciprocal), there's care (genuine) for the other, it just can't be decided (even for oneself). It's not something you can commoditize with policies or incentives. You don't have 6 or 10 such people in your life, more like 1, rarely, 2 if you're really lucky.
What most of the article seems to be talking about is very good but it's not really 'mentoring'. More like "skill sharing", good "onboarding" (even with seniors as we onboard others onto the systems we happen to know better in the organization or the field at large). It's informal teaching, transmission, it's an organization thing he's describing — not a human-driven relationship that exists around all else.
The platform is more interesting. People with a desire to mentor may find a good match, and stick with it. Reciprocally. But the truth is that no more than online dating, you just can't be sure there's a match right now for you, you may find students / teachers (like find people to grab a drink sometimes), but mentees / mentors (long-term relationship) is a whole other ballpark.
I'd say this: it is a good cultural evolution to value mentorship and try to form minds into engaging in such relationships, like you'd think it good people want to marry or raise kids. It also shows how learning isn't a school thing only, actually very little, but a life-long endeavor wherein all parties grow in the process. But just like Disney movies aren't reality for most people most of the time, a little temperance on the real felt experience of mentorship may be in order when encouraging people to the possibility.
- why you choose to do things a certain way
- how you figured out a pattern or solution
- extracting the most from your tools, such as debugging
- that this isn't magic, persistence can be key for tough bugs and performance problems
I've had mentors just answer one-off questions, and I've had others that gave me the above insights. When I'm helping someone, I try to "think out loud" and teach them process.
Language-specific structures and patterns can also be taught, but they shouldn't be the focus. More like incidental tidbits a junior can and should pick up along the ride.
I find it incredibly hard to think out loud and work through a problem with an audience. Going away, to my own workstation, spending 2-3 minutes looking at things and investigating will often get me some ideas. Which I can communicate back. Often describing how I got there.
Put me on the spot and if I don't already know the answer I probably cannot find it under scrutiny. This is my failing, I know, but it's demonstrably true.
As soon as you start to perform with your status as a skilled developer hanging in the balance, your brain will lean towards " fight or flight" mode and decrease your cognitive abilities.
You are 100% correct that this is a large part of the problem, but I cannot get rid of it.
After that, without the clear goal, I think we drifted a bit. Mentoring still had positive value, but I in general I think the value curve is logarithmic and after a while one reaches a point of diminishing returns.
It feels like current issues are too short term for this, unless it is a fundamental issue like no having enough domain knowledge. Googling and/or a quick discussion with your colleagues should suffice in most cases.
If it is a more general subject, how to choose which one? Obviously there are a lot of things I don't know, but it's quite hard to pinpoint what would be the most beneficial thing to learn right now; otherwise I would have researched it already.
Maybe reviewing the recent work with the mentor, and trying to extract pain points from there could work?
We also recommend mentors to sit in on some agile ceremonies with the mentee's team to get a feel for how the mentee's dynamic is with their team, which can spark some discussion as well.
Fundamental, long-term issues can include encouraging the mentee to be more assertive, how to help their team become more effective, and how to approach navigating the inevitable politics of the organization.
Nowadays I both have to mentor and get mentored. This seems so weird to me. People did really well for years without it. People got really crazy skills, came up with great ideas and wrote rock solid software. This works very well when being both responsible and open to experimentation.
Edit: My skepticism was misplaced. A lot of this advice is very good and, as the site implies, practical.
I joined Uber. Until then, I've never received or done mentoring, or at least never put this label on any activity I've done before.
I've never worked at Uber and I don't know many people who have. So most of my knowledge of how Uber operates and of the culture they espouse comes from places like HN. Overwhelmingly the press' depiction of Uber's culture is extremely negative. Mentoring is one of those potentially formative experiences in a person's career. Presumably the "Uber way" of mentoring forms a large part of the author's experience and approach to mentoring. It was an interesting divergence from what I would have expected. It's a good data-point on the other side of all the negative we hear related to Uber.