Having things like code reviews, regular pair programming sessions and cool non-work activities are some of the nice to have things I look for when joining a team/company.
But what really stands out for me is the idea of having someone who can mentor me during my journey. I don't exactly know how to describe it, but I just value a lot the personal experience of others so I can then put them to the test and discuss why we should do things a way or another.
So, for those of you who have the chance to mentor others: [read the title/question]
Top comments (10)
Yes and no.
Yes, because it's a great experience and we both come out of it as better programmers. Teaching and guiding someone is a very humbling experience and seeing the results of ones advice is heartwarming.
No, because if we're talking about doing this during company hours, as a Senior I have tight deadlines on projects that only I can complete, and spending time mentoring is time that could've been taken to ease the pressure of ongoing projects.
Mentoring a Junior is a company investment with payoff being several months to a year down the line, and not every company can afford it. On the other hand, if handled well it's a worthwhile venture. It helps if the mentoring is spread across multiple developers, but a lot of the mentoring difficulty is going to depend on the non-technical skills of the Junior: Their attention to detail, ability to take notes and their tenacity while researching and debugging.
So, in conclusion, it's a mixed bag, depending on the circumstances - if we're talking about company time.
In my free time, online, I do enjoy giving advice and pointers to people learning programming. I've written a beginners course in my native language and made it available on Github, and at any given time I'm guiding a few people through it. Honestly, this version of mentoring I find more fulfilling, as it involves people getting better at programming in their own time, which often means they're self-motivated to a much greater extent than somebody at an intern position.
I have worked for 3+ years at a company that values mentoring a lot. In fact, mentoring is an actual expectation starting at senior level and going up. They're an industry leader and push a lot of innovation, thus this incentive might seem obvious.
But, to be really honest, all, and I mean ALL, companies should do it. And it can be done effectively without the need of a lot of hours. I had a mentor/sponsor for two years, as I was an already senior consultant but new to their culture I really needed some help, and it DID help me a lot. And we met for 1h every two weeks. That's 2h per month. That's why I think any company can spare this, it's just 2h. We would still exchange some e-mails, have chat at the water cooler, but all of these would be either really small or on personal breaks (lunch, etc).
I'm going to go out on a limb here and say that just 1h every two weeks is probably not the norm.
I am inclined to agree that all companies should do it, and I think that 2h a month is not a problem for any company. And that's probably ok for somebody with some seniority, but for a true Junior (think, 1-2 years of code-camps, or a fresh CS grad) a more realistic number is 1-2h per day. And those kinds of hours add up.
I totally agree with you! Junior people would require more face time, and they do get that there. But it's mostly as work-as-usual approach. Pairing (for starters and as a constant for all the team) and a close contact with the team leadership (PM and tech lead) which should both have frequent catchups to provide feedback and mentorship.
For instance, this experience I mentioned was when I was playing the tech lead role, so I would have a 1h catchup with everyone on the team once a month, and sometimes twice a month, where I would present my expectations for them and assist them on their journey. Also, they would have a more frequent meeting with their mentors (usually 1h per week).
My point is, which is what I've learned after 2 years of playing a leadership role, is that what really matters is the people. If I'm a senior/leader on a team I should pay attention to the people and do my best to support them 100% of my time. Be that through one-on-ones, pairing, code review, 30 min talks about interesting code, etc. And it's always for the benefit of the company, even if they don't think so (in which case I would still do it and then present the results later).
Sounds like we're on the same page then! I agree about people mattering, and it's really the tougher part of the job, especially for someone coming from a purely technical background.
I'm not a senior engineer at a company, but I mentor several students at my university through our ACM chapter.
I love helping out students that are less experienced! I had an amazing mentor at my first internship, and I strive to provide the same experience I received to them.
I would be very interested to learn how others mentor your juniors. I usually help them professionally through Resume/LinkedIn/Website building, and technically through their programming interests. (I'm usually matched with students interested in Web Development as that's my interest as well.)
Mentoring has been an invaluable part of my career. As a mentor, I am able to help others develop their own skills and prepare them to move to the next level in their career, but I also learn so many new techniques from those who I mentor.
At Cerner, code reviews are a mandatory part of our development process. We believe that having more than one pair of eyes on our source code at all times leads to higher overall code quality and stability. It gives more senior engineers an opportunity to teach newer engineers some different techniques, while the rookies get the opportunity to keep the senior folks in check ;)
Let me reframe the question... how about "Do you enjoy mentoring others?"
You are already a "senior" in something and are capable of being a mentor. You can volunteer with local high school or middle school groups, or help mentor summer interns at a job. You don't have to wait until you are "senior" in your career to think about mentoring. In fact, start with peer-mentoring and build strong connections to those around you.
I have organized a number of successful mentorship programs, so let me frame the term 'mentoring':
The best formal mentoring programs have a clear timeframe, so both parties know the bounds of the relationship. It allows each person to move-on, guilt free when the time is up.
Yes. I understand this also depends on your company and culture too. Where I work we actually account for "training" as part of our times in sprints (2 week sprints). So in that time we make sure we always have time for learning/mentoring. which is about 1 day over the 2 weeks. This time accounts for things like having to learn something related to your task, teaching a new engineer, and so on. If that takes more time with a new hire, its usually fine.
We work in 3-5 person squads and most squads have minimum 1 each of front end and back end engineers. Often times one of them is full stack somehow even they will focus on one aspect. My squads main front end dev is a full stack dev but he focuses on the front end (IMHO you should have some familiarity with the other half of your field).
So when our squad brought in a new engineer, they understood that getting him up to speed may take more time, so we made sure we weren't too overloaded. But also the new engineers first sprint was almost all learning time. Getting up to speed on our stack and in our case, learning React (we have 2 backend devs (myself included), and 2 front end devs).
I personally enjoy teaching people and it is what one of my goals are is training. We also have a weekly "book club" for various books related to code architecture, or similar to help us be better devs. Anyone in the company can join. Currently were going through the new Clean Architecture book.
For the No side. some times it can get frustrating as Nick's comment states. Which is why I think "time boxing" your training time is helpful. some of the best things you can teach them is HOW to find the answer in your code base or google or where ever.
I know not all companies work it into their culture. And I have been with ones who don't so I get haw hard it can be especially with deadlines. But I very much enjoy the practice of doing it.
YES definitely! :-) I love it.