Hacker News new | past | comments | ask | show | jobs | submit login

I've been a professional developer for about 5 years, and I've never seen great professional mentorship. In my experience, one should plan on working alone, and look & hope for good mentorship. For my first job, I was lucky to get a single offer, and that meant I didn't have much of a choice in what kind of learning & earning potential I had.



In my career, I've had a handful of occasions where someone mentored me. When they do, you can learn very, very rapidly.

But as good and valuable as that is, I think everyone needs the experience of solving multiple, hard problems mostly using books and the Google machine. You can never be senior until you can solve hard problems without someone holding your hand.


A good mentor should know when to suggest to the mentee that the next step is reading a book and solving a problem themselves.


You are lucky if you get to bounce ideas off of someone. The relationship you describe doesn't exist between peers and reminds me of a teacher student relationship.


> reminds me of a teacher student relationship

... isn't that by definition what a mentor-mentee relationship is?


That's the classic example but doesn't apply because in a teacher student relationship there is a level of trust and control with each person at a different level.

If you find someone to mentor you in programming and they are on your team at work you are more like peers. Equal and in some cases the mentor becomes the mentee when another subject is in focus.

It's more of a peer to peer relationship.


I'm curious, what would you consider the right point?


It depends a lot on the person and how they prefer to learn.

For people who are very analytical and self-motivated, i think it's fine to suggest reading books fairly early on in their development and just be there to answer questions or indicate how those theories are applied in the company's processes and tooling.

In this case the challenge is more around finding a book to suggest that suits the work. Coaching can end up being more around where to focus or how to skill up on one topic at a time.

Some people find it tough to digest knowledge in written form. In my workplaces this is often compounded by many good tech resources only being available in English and many developers not being native English speakers.

In these cases i have found it helps to start with pair programming (best case) or detailed code review (at minimum). After each "learning session" you can then provide links to references (book, article etc) for more info or background on the comments. This helps contextualize the theory upfront and shows the value of the source.

Sometimes when a certain source is referenced frequently, people take the initiative to read it to better understand the fundamentals for future work. Sometimes they don't.

That's where management comes in, i think. Regardless of whether a person chooses to learn with a book or some other source, at some point they are going to have to be able to solve challenging problems on their own. Managers are able to facilitate growth by allocating tasks that are at the right level of complexity for the dev.

I think the point is that it's not the job of a mentor to step in and solve the mentee's task, but to provide support and explain what sort of techniques and resources may be helpful to solve it. It's still up to the mentee to do the work.


Thank you for the detailed answer. I know this is somewhere I still have a long way I could improve so it's definitely interesting to get another's thoughts.


Couldn't agree more with this perspective on mentorship. You nailed it.


I think there's some confusion in this thread: yes, all programmers should develop their ability to solve problems alone. But new programmers should definitely avoid accepting a position where they would be the only programmer, if at all possible. If you get such an offer and are worried it's the only offer you'll get, I think you should bank on that being wrong and stick it out and wait for an offer with an actual team.


You have to bring it up when you're interviewing, and get in deep. Tell the technical interviewers what you want to get better at and be honest and be prepared to say no to good offers that aren't going to nurture your skill set. Ask about how they do code reviews, what professional development they offer, how often they pair program, do they do tdd or just make it work as fast as possible to appease the business, how the team has helped each other to grow and whatever else feels important to you


It's hard to break in with no experience. I'm not sure everyone can filter out companies based on mentorship.


I've mentored people and gotten decent feedback on that. If that's what you're missing, move around. See if there's someone internally to get what you need, else jump ship for a new employer. Also, mentoring is mutually beneficial. As a mentor I get someone I can trust to do things in a particular way. Value for the mentee was already implied.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: