Ask HN: Anyone had a positive mentor/mentee experience as a software engineer?
I've been in the industry for quite a while and haven't had a mentoring relationship that really paid off, regardless of which side of it I was on. Have you? What made it successful? Asking for a direct report...
I had no idea what a good mentor was cause the type of people the orgs assign are doing it out of obligation or want an obedient slave and its a crap shoot whether personalities and needs match up.
The mentors who actually ended up taking me under their wing were people who saw something I could do for them. In one case the dude came looking for me cause I was patching some of his old work that no one else wanted to touch in their free time. So he had an incentive to coach me that turned out great cause he loved to teach and I am naturally curious.
In another case I reached out to someone who I had observed getting stuff done through all kinds of shit office politics. We had a reading/study group at work which would meet once a week and I invited him to give the group a talk. That talk got him a whole bunch of connections and he was really gratefully. He was a chain smoker (I dont smoke) but he would pull me out on every smoke break to give me lectures on everything under the sun. I think I learnt more under various trees on the campus than at college.
So its really about doing things for others genuinely, being curious about them and keeping your fingers crossed.
I had a mentor that was the team lead for another team that I wasn't on, but worked in close-ish proximity to. They were great for bouncing technical ideas off of because they were neutral and unbiased. I could agree or disagree with them on any topic and it wouldn't matter at all and since they're not working on the same thing they don't bogged down by the real constraints and could just give their opinion on what the ideal solution is. I think what made it successful was their willingness to listen to other peoples' ideas and problems even though they didn't have a stake in them, and my willingness to be open and frank with someone outside of my team. I've met a lot of devs. that want to project an image of utter competence to everyone around them and I think that precludes them from learning from the experience of others.
There's a piece of advice out there that says: Don't go to an engineering meeting with a proposal unless you've already got the majority on board with your plan. Having that sort of mentor/mentee relationship with the senior people on adjacent teams is how I followed through on that advice.
My mentors sucked. Many of them gave tips that were either just repetitions of what the hivemind said without the underlying basis or company does-it-this-way speals. I then turned to weekly book reading routines, learning by myself and the results have been far greater.
But then again I've always been someone who focuses on understanding the underlying rather than someone who follows best practices.
The person who taught me far more about how to program than anyone else wasn't a programmer. He was the operations manager of an Electrical Generating Station. He had a non-nonsense approach to testing, and the power to pull it off, that worked wonders. We both wanted the same thing, a program that users would have little trouble understanding or using, and accurate data when the reports were done. As others have said, it worked because our incentives aligned quite well.
Once the program was complete, it was deployed widely, and I spent a few happy years travelling around the region to support it, usually when the accompanying hardware failed and needed to be diagnosed/replaced.
I've had two good mentors so far in my 40 years of software:
During undergrad I worked at a research lab, and the professor running the lab wrote what would now be called a lab-wide IoT environment. But this was the 80's and he just called it "MS" for "modeling software" - it modeled "situations", verified/monitored by sensors (cameras, mics, clock) which had software triggers to run processes (send emails, turn on/off lights, run lab maintenance...) so we, the staff, could focus on the reason we were there - our research. How he set up MS, and how our research work ultimately tied into his stack to run our experiments and generate publication graphics taught me so much more than my undergraduate degree. His whole approach was to free us to focus on our other, more important work, and how software like that could be design and implemented.
I was involved in early streaming media. In the late 80's at Philips N.V., several working groups trying to create technology demonstrations of streaming media with early CD-ROMs failed to deliver demonstrations meeting expectations. A European executive from the Netherlands came to the multi-company joint venture in the 'States to try his hand, against local management's wishes. He was politically high at Philips, and the local management simply did not want a Parent Company takeover. I was one of a small team placed under him, and at the time a junior media engineer. His respectful personality and rewarding others management style encouraged his team and I learned the power of empathetic charisma. The guy had style and attributed it to others around him, as if he and his manner were due to us. He taught me to always look at the goal of a software's users, and the superior experience of creating transparent technology that augments a person's needs rather than attempting to take over their attention. Coupling his attitude with my prior automated lab experience enabled us to create a complete media production environment that "plugged into" existing media production teams. Not only did we produce technology demonstrations that became marketed and award winning products, but our production system became a professional product Philips sold to media companies.
Sure, yes, I won't name names here but I've worked with some wonderful programmers who I learned a ton from, and who pretty much set my life direction. It occurs to me though, that those were in organizations with almost no management interference in the tech stuff. Maybe today's corporate environments can't stand that.
I think I understand some of the dysfunction, but not quite well enough to write it down. It's the same mentality that leads to putting programmers in noisy open-plan offices though.
Yes, I haven't been to engineering school, so in almost every company or open source community I've been part of, colleagues have been mentoring me.
The mentors I had were very passionate about their field and happy to share their knowledge.
The mentoring was not really about small details. More about seeing what technologies and concepts I was comfortable with, and telling me what things I should explore next. It was most of the time very opinionated, but this was OK, as I had more than one mentor.
I've had many very helpful mentors. But basically all the mentoring boiled down to reminding me not to target more than the specifications and finishing things rather than leaving several things 90% done.
I had no idea what a good mentor was cause the type of people the orgs assign are doing it out of obligation or want an obedient slave and its a crap shoot whether personalities and needs match up.
The mentors who actually ended up taking me under their wing were people who saw something I could do for them. In one case the dude came looking for me cause I was patching some of his old work that no one else wanted to touch in their free time. So he had an incentive to coach me that turned out great cause he loved to teach and I am naturally curious.
In another case I reached out to someone who I had observed getting stuff done through all kinds of shit office politics. We had a reading/study group at work which would meet once a week and I invited him to give the group a talk. That talk got him a whole bunch of connections and he was really gratefully. He was a chain smoker (I dont smoke) but he would pull me out on every smoke break to give me lectures on everything under the sun. I think I learnt more under various trees on the campus than at college.
So its really about doing things for others genuinely, being curious about them and keeping your fingers crossed.
There's a piece of advice out there that says: Don't go to an engineering meeting with a proposal unless you've already got the majority on board with your plan. Having that sort of mentor/mentee relationship with the senior people on adjacent teams is how I followed through on that advice.
But then again I've always been someone who focuses on understanding the underlying rather than someone who follows best practices.
Once the program was complete, it was deployed widely, and I spent a few happy years travelling around the region to support it, usually when the accompanying hardware failed and needed to be diagnosed/replaced.
During undergrad I worked at a research lab, and the professor running the lab wrote what would now be called a lab-wide IoT environment. But this was the 80's and he just called it "MS" for "modeling software" - it modeled "situations", verified/monitored by sensors (cameras, mics, clock) which had software triggers to run processes (send emails, turn on/off lights, run lab maintenance...) so we, the staff, could focus on the reason we were there - our research. How he set up MS, and how our research work ultimately tied into his stack to run our experiments and generate publication graphics taught me so much more than my undergraduate degree. His whole approach was to free us to focus on our other, more important work, and how software like that could be design and implemented.
I was involved in early streaming media. In the late 80's at Philips N.V., several working groups trying to create technology demonstrations of streaming media with early CD-ROMs failed to deliver demonstrations meeting expectations. A European executive from the Netherlands came to the multi-company joint venture in the 'States to try his hand, against local management's wishes. He was politically high at Philips, and the local management simply did not want a Parent Company takeover. I was one of a small team placed under him, and at the time a junior media engineer. His respectful personality and rewarding others management style encouraged his team and I learned the power of empathetic charisma. The guy had style and attributed it to others around him, as if he and his manner were due to us. He taught me to always look at the goal of a software's users, and the superior experience of creating transparent technology that augments a person's needs rather than attempting to take over their attention. Coupling his attitude with my prior automated lab experience enabled us to create a complete media production environment that "plugged into" existing media production teams. Not only did we produce technology demonstrations that became marketed and award winning products, but our production system became a professional product Philips sold to media companies.
I think I understand some of the dysfunction, but not quite well enough to write it down. It's the same mentality that leads to putting programmers in noisy open-plan offices though.
The mentors I had were very passionate about their field and happy to share their knowledge.
The mentoring was not really about small details. More about seeing what technologies and concepts I was comfortable with, and telling me what things I should explore next. It was most of the time very opinionated, but this was OK, as I had more than one mentor.