Hacker News new | past | comments | ask | show | jobs | submit login
Developers mentoring other developers: practices I've seen work well (pragmaticengineer.com)
425 points by fagnerbrack 3 months ago | hide | past | web | favorite | 72 comments



A big mistake I made when I started mentoring other developers was making the answers to their questions too easy.

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 can echo this experience. I guess this comes down to the Socratic method of teaching people: https://en.wikipedia.org/wiki/Socratic_method

I have yet to see a more effective method of teaching developers, as this encourages understanding and learning about underlying concepts and problems


While I agree, I think there is something to attest to watching someone solve.

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.


Yes, the best teachers ask questions of their students, engage in a dialog and provide "guard rails" for the student to gain mastery of a topic. The end result of learning is not merely knowing answers but being able to ask strong questions (pithy, but true).

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.


SO answers are really good learning place. That is if you read the whole thread instead of copypasting the accepted answer.

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.


SO is a great place to go when you're in a jam at work as a pro doing your stuff. It has specific answers to specific questions. Sure, if you have enough background expertise to navigate the answers, you can "learn something" (1) along the way.

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.


>> 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.

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.


StackOverflow is in a negative light? What did I miss?


People have complained for years about over-moderation on SO. Here's a good overview article[0]. You may also want to look into recent controversies about licensing[1] and how they treat their community moderators[2][3] (both of which were on the front page of HN).

[0]: https://hackernoon.com/the-decline-of-stack-overflow-7cb69fa...

[1]: https://meta.stackexchange.com/questions/333678/was-the-retr...

[2]: https://news.ycombinator.com/item?id=21113344

[3]: https://news.ycombinator.com/item?id=21176712


I really like this style too. When I get asked to do 1 on 1 teaching sessions I often find myself teasing out answers by asking a bunch of questions using the Socratic Questioning[0] strategy.

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...


To add a concrete example, one of the best uses of the Socratic method I've seen, teaching binary to 3rd graders - https://news.ycombinator.com/item?id=2446316


Cheers for the link, that's an amazing page.


Teaching developers how to find the answers to their problems is a crucial skill, and one that's often approached the wrong way - either new developers get all the answers easily and don't learn, or they spend days trying to unblock themselves. I recently wrote about that challenge in an article for junior developers. [1]

[1] http://www.pearlleff.com/seven-tips-for-a-junior-developer


I agree, but what do you do when others don't co-operate? My experience is that most people absolutely hate this. Only occasionally do I run into someone that appreciates figuring it out for themselves. More often, they feel like you're playing games with them, or being condescending. You become the jerk for withholding information, instead of them for wanting others to do their work for them.


I'm assuming that's due to the mental framing of the relationship. When a Junior Developer identifies the student/teacher relationship, you can encourage their growth in a way that you can't with a peer-to-peer relationship. The questions asker needs to understand that they're getting help LEARNING and not just an answer.


Naw, that's just the way many people are. If you can't give them the answers they want they'll assume you're incompetent (aren't you a senior engineer?), if you refuse to, they'll just think you're a jerk (quit playing games and tell me what I need to know). They don't want you to treat them like a child, because you're "trying to help them learn". Some people just hesitate to run with the premise, it'll look like you're making them jump through hoops, and wasting time.


This applies not just to developers but all the way "up the ladder". The problems will change but the effective learning and mentoring will be the same.


The trick is to play the question back at them: “What is your guess?”

If they got used to your service this might annoy them, but if you explain it beforehand..?


When I was a junior dev and was stuck on a problem (had to cap myself at 1 hour max because otherwise I'd spend the entire day) the first question my mentor asked was 'what have you found out?' and 'what is your thought process?' By regurgitating and trying to condense the things I figured out he could already point me to the right path and/or correct some wrong assumptions I made. It really helped me grow as a developer to not just be handed the answer.

But yeah, he did sit with me beforehand and explained how he mentors people.


Imagine a mentor who belittles you, exaggerates your flaws, and brings up false accusations only in private, during one-on-one meetings, and only picks on you in secret. But outside they are very friendly.

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.


Same here. I believe I’ve had two, possibly three “mentors” like this. Except instead of mentors they were managers and their managers.

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.


I totally agree that mentors and mentees should be free in their choice with whom they partner. So if you had bad experience with your mentors it should be easy and penalty free for you to change.

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.


> On the other hand, I would decline to mentor you:

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.


I think that can happen even without the mentoring context. Office politicians know how to throw bombs even when they just say hi.

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.


How would reporting change anything?

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.


> How would reporting change anything?

There are still companies that give a shit about this sort of things. Depends obviously on who is the perpetrator. (... sadly enough).


I've experienced something similar as well, although I think the 'mentor' was sincere they were also incredibly neurotic and a bit paranoid from my point of view. The few people that bought into their advice remained under their wing/control for over ten years and probably experienced less career development as a result.


I suspect that's because no one can really supply you with a mentor who's going to be good. There are only two reliable ways: you catch the eye of the person you want to be mentored by, you bug them till they mentor you.


Yep, and this kind of behaviour can't be fixed by having a formal company culture despite what many organisations think.

Mentoring should be voluntary and should just be about helping someone else on the team.


In my personal experience, apart from onboarding, "forced" formal mentoring is bullshit and a total waste of time. No one benefits.

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.


It's a catch 22 situation because a lot of organisations expect folk to skill up but don't provide a formal structure to do so. I've worked on projects where I was helping out junior developers but criticised because it wasn't a profitable use of my time.

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 struggle with this. We get juniors that really don't know much about programming yet, some that start because they know our domain well and know a bit of Python. There is a lot they should learn that others get from formal education before they start to work. But we don't know how to give structure to it as a company.


If your company cannot train junior engineers, perhaps you shouldn’t hire them. Doing does a disservice to all involved.


We don't really have a choice, but I wouldn't say we can't train them. They do improve a lot on their own and on the job. We do a lot of code review and give them time to figure things out, and we're OK at picking the ones who are able to learn like that.

I still feel we could have more structured, formal training but don't know how.


Could you share better your experience? And why do you think it's a pointless exercise?


The best kind is organic, but sometimes things need a little bit of a formal kick start.


Please don’t state your opinion as gospel truth.

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.


How do you read comment starting with "In my personal experience" and respond with "Please don’t state your opinion as gospel truth.". Wtf?


Please stop hedging every post on the Web with 100 disclaimers about everything when it's obviously an opinion, or obviously you don't think it applies in every case but is a useful generalization, et c. It's a crappy way to write. Ignore the obtuse nitpickers and posters who willfully misunderstand.

OP was fine.


In what way is it stated as gospel truth? It literally starts with "In my personal experience".


[flagged]


Whoa, personal attacks aren't ok and will get you banned here. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here? We'd be grateful.

Please read them all the way to the end, because you broke them with https://news.ycombinator.com/item?id=21514770 as well.


Op gave a personal opinion about how onboarding is ‘Total bullshit’. Commenter asked for OP to not throw their personal bias as truth. It is confirmation bias. I had this one experience so all experience are this one experience. Commenter two called commenter one out saying that commenter one is completely off the mark and that op was not speaking gospel due to one sentence they wrote at the beginning.

I merely pointed out how Saying one sentence does not change the sentiment and tone of the rest of the story.

Ie; ‘In my personal experience’ does not negate preaching nor gospel talk.

Sure I may have told commenter two to stop contributing, but that is because commenter two was also violating the rules that you so eagerly linked.

Agreeing with a commenter who calls someone out on their attempts to sway others through logical fallacies like straw man etc, is not breaking the rules. There is a huge problem in modern times of manipulation and when people are trying to manipulate others it should be brought to light.

There was nothing wrong in the example I provided and that was not meant to be taken literal, so the example provided does not break the rules.

Again, what is the point of dogmatically following rules, when rules aren’t a catch all to begin with? They are guidelines to help form a better community. The rules need to be analyzed in the context of the whole, not in some isolated measures. Nor garnered through a ‘reputation’ via downvoted. I bet most people who can downvote felt attacked when a personal experience was labeled as gospel because they are the same people who often find themselves preaching.

HN would be better off without downvoted in total rather then some gatekeeping effort to put downvotes ‘in the right hands’. Honestly this is silly that my comment was even flagged.

If an apology is wanted for telling commenter two to stop contributing I will do so, but commenter two should also apologize for making others feel they cannot contribute. Arguments are fine but when you take the stance of I am right and you are wrong without any evidence or support or argument at all, you are not starting a debate you are just contributing to the wide pool of logical fallacy.

Lastly I will defer to Paul Gharam’s Hierarchy of disagreement, which btw op and commenter two failed to reach the top:

https://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/Gr...


Other people posting bad things doesn't make it ok to break the guidelines and certainly not to escalate into personal attack, which you did. If you feel like other comments didn't get moderation replies and should have, we're always open to looking at specific links. If you flag one, we'll probably see it—but if you email us at hn@ycombinator.com, we'll definitely see it.

It's hard to tell from what you wrote here which specific other comments you're referring to. I tried, but got confused.

If you see a bad comment that didn't get moderated, the likeliest explanation is that we didn't see it. We don't come close to reading everything that gets posted to HN—there's far too much—and we usually read the threads in more of a random-access than a linear way, so a post that seems glaringly obvious to some readers may just have escaped our attention.

You've posted a lot of good comments here! I just want to acknowledge that. You have a nice way of finding something interesting in what other people have posted and replying with something interesting of your own. That's the most desirable quality in HN threads, the idea of which is to be good and fresh conversation. It's nice and surprisingly rare in this sort of exchange to look back through a user's comment history and see that.


When I started as a software engineer in the Aerospace industry, I was the "kid", one of the few young guys working amongst a large group of middle age (and up) engineers. Interestingly, there wasn't much in the way of mentorship -- just dump all of the grunt work on the kid. "It's good for you to cut your teeth on testing/maintenance/etc." And also "You need to pay your dues, son." - whenever I asked for more responsibility / new projects, etc.

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?


> 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.


Similar experience for me and we are the same age. I don’t feel cheated per say but I agree we had less opportunity available to us and less ability to affect change.

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.


Aren't those of us born in 1980 (+/- a year or so) millennials?

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.


Millennials were born early 80s to late 90s. The exact years depend on who you ask and are a bit fiddly anyway depending on how you interpret the phrase "was a teenager during the 'new millennium' (decade).". (For example, does pre-teen count, did the millennium start in 2000 or 2001, etc)


> Now that I'm middle-aged (39)

Excuuuuuuuuse me?!


How would you define middle-age? 39 is roughly half of the current US life expectancy for a human male (~78).

Barring a cure for aging coming along within the next few decades, I'm right about in the middle of my lifepsan.


Middle age is usually considered as the years from about 45 to 65


My issue with mentoring is that in practice it’s often just a way to help the mentor transition into managing or becoming a TL. Which isn’t necessarily good for the mentee because the incentives aren’t really there for you. Your org might force you to grab a mentor who does something unrelated, and not particularly well, just because of their level and career aspirations.

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.


> I’m just not sure about top-down forced mentoring as a career requirement.

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.


> 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


What everyone has to learn over time is

- 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'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.

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.


It helps if you don't think you're being judged. To me, these skills are learned through trial and error. Error is ok and I'm fine stumbling through ideas that could be wrong.

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.


> 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.


It helps to have a sharply defined goal. At a previous job, I mentored someone in a support role who wanted to move into a dev position. (They were also highly motivated, which was helpful.) Our meetings largely focused on preparing for the dev interview -- filling in knowledge gaps, working through standard whiteboard questions, understanding and being able to articulate software design principles, etc... We actually covered pretty broad ground here. They got the job and I found the experience quite rewarding.

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.


The site mentions https://codingcoach.io/ several times. Has anyone tried this service? How useful is it?


I was also noticing that - it almost seemed like an intentional plug. If anyone has experience with it I would love to hear about it!


Same here. I came to the HN comments to see if there was any other comparable alternative in some comment(s)!


How do you choose what to focus on with structured mentoring?

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 have had success at my org by anchoring a lot of the mentor/mentee discussion around our documented career ladder. If there's not a pressing specific discussion topic for one of their meetings, they can always bring that out and go through the ladder items to brainstorm ideas on how to progress.

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.


I wonder if this is something new, at least it seems to me new. Working now more than 10 years in Software engineering, I never experienced anyone appearing as mentor.

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.


i am looking for a mentor. I have 3 years of expirience of programming profesionaly. Currently working as a backend java spring programmer. I am on this weird spot where I am not junior anymore but I feel like my skills lacking big time to advance to mid / senior


While you're looking for a mentor, take a look at this guide and see if it helps. https://github.com/kamranahmedse/developer-roadmap#back-end-...


sounds like we need a "Ask HN: Who is available for mentoring?" kind of thread.


I've been fortunate to mentor a couple very sharp young engineers, while I can provide context and experience in long-term problem solving and project management I'm finding myself learning a ton from these guys who have more up to date coding skills.


I'll come back and edit this after I've finished the article but I have to admit I'm skeptical about taking advice on mentoring from Uber.

Edit: My skepticism was misplaced. A lot of this advice is very good and, as the site implies, practical.


This is not "Uber" but an employee of Uber who has worked other places too.


That's true. However, it does seem like the foundation for their mentoring-related experience is Uber:

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.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: