There's a real danger as a senior level employee that if you go out of your way to mentor younger coworkers, you become the go-to training guy. Your coworkers stop asking their peers or their manager for help and start asking you directly. Other coworkers send the new hires directly to you so your manager doesn't even see the amount of questions you're answering. And all the while your actual workload isn't getting any lighter. And if you complain, you look like an asshole. What kind of person won't help train new employees? Why are you so anti-social? Why aren't you a team player? It's just one or two questions here and there. And when it comes to performance reviews, your mentoring counts for a hell of a lot less than the number of projects you finished on time, so now when the company isn't doing so well, your output per dollar is a heck of a lot lower than the people you trained, so you're out the door. No one sees that the new employees never would have finished their project without your help. Your name isn't on that checklist, it was their project. What do you mean you helped? We gave you two weeks to train them, why are they still coming to you for help? Did you not train them properly?
So either you get laid off, or you quickly realize that you have to start turning away questions and mentoring. I love training new employees. But that's not my job. My job is finishing projects. If mentoring gets in the way of shipping, guess which one I'm going to drop first?
The important distinction is that they make the call and you've both gained visibility into your workload and they own the outcome. If it's a bottleneck that's causing pain they'll quickly become aware of it.
There's a balance -- you can do more with more hands, and they need to be well trained hands. But if they're not your direct reports, ultimately they're not your problem. (This also means that you will need to be responsible for the outcomes of those you mentor, and you'll need to learn how to let slow learners go. Oh noes, you're becoming management! It's almost as if there's a reason that good managers with domain expertise are hard to find.)
I guess it comes down to, are you going to be a "helpful" "mentor" or are you going to accept formal responsibility for the success or failure of mentees (vis-a-vis grants, contracts, successful projects, etc.)? Instead of being a martyr, it seems that explicitly accepting or denying responsibility for people who eat up your time (within reason) is the best long-term strategy. You can still succeed without doing this, and you can still fail while doing this, but the odds are in your favor if you demand accountability. (Also, there's nowhere to hide if you aren't as good as you think you are; I think that's a feature, rather than a bug, but opinions may vary.)
The issue in a corporate setting is you are expected to make up for other people. Same in college.
Sorry but almost all forms of failure have individual liability. Merely knowing this helps a lot of people take their situation seriously and do something about it.
When key information regarding how you're supposed to do this thing or where that thing is located or how you're supposed to test Y, or how should this particular bit that wasn't communicated in the user story but was talked about in a meeting you weren't at be tackled, or whatever is locked inside people's heads you need to consult with them to get that information out of there.
And yes having information locked inside of senior employees is a bad idea for the company overall, but that's been the case to some extent at pretty much every company I've worked for.
Well there's your problem, it's a classic multiple-bosses insanity when anybody can put a new task (hire) on your plate. Furthermore, it may also come as bad news to you if you've already been "promoted" to company trainer, informally.
Talk to your boss about how all of this is getting funneled to you. At the very least you should be keeping them informed as to how your day is spent.
Not to mention, that if it's something they can be trained in once and monkey-repeat ad-infinitum, then there is a near-100% chance that I can automate it.
Doesn't this assume that the only mentorship (edit: We're really talking about "job training") is peer mentorship? What about classes, self-training, etc? Why should the onus be placed 100% on the senior employee? Why no onus on the junior employee?
>I believe this is especially true for aspects outside of writing code. This probably isn't true at every company, but from where I've worked, a big part of being a senior engineer is understanding how to tie in business goals to development. That's not really easy to learn in a tutorial online or by contributing to open source.
I went through four years of computer science education, had multiple jobs/internships in college, and even took over 10 MOOCs across Udacity, edX, and Coursera. None of those things prepared me to be the developer I am today (I won't deny that they helped, though). They certainly put me in a great position upon graduating college and got me a great job, but nothing increased my skills more than simply working with more experienced developers in a full-time role.
That's, fine, but that's not what we're talking about. We're talking about management placing an (implicit, unrecognized and uncompensated) expectation on one developer on a team who happens to have a lot more experience than their peers. In other words, management is happy treating him as equal to his peers when providing compensation, yet expects significantly more output for the same pay.
I understand that senior devs might mentor juniors, or that experienced devs might train up newbies, but to expect one dev to "step up" to mentor teammates without some kind of recognition or compensation is not reasonable. (edit: Especially if those teammates are a long way from being qualified to do the work.)
If someone is paid to literally write code, it's perfectly healthy for them to want to only write code and not provide free labor in a different domain.
I'd go so far as to say we currently have an unhealthy culture if we're expected to provide free training to everyone.
Job training used to be, and still should, be an explicit responsibility of the employer. Not an underhanded sneak expectation that's unofficially forced on people who were hired for other job descriptions.
"Healthy" is not a weasel word, but one half of a common term that people use[0].
>If someone is paid to literally write code, it's perfectly healthy for them to want to only write code and not provide free labor in a different domain.
It doesn't sound like humbleMouse is getting paid to literally write code. It sounds like they're getting paid to write code and mentor junior developers. It's also not free labor. If someone works 8 hours, gets paid for 8 hours, and spent half of that time mentoring others (which is incredibly generous), then I don't see the issue.
In any case, if someone finds themselves in this position and are unhappy with it, they should talk to their manager or find a new job. There's no shortage for experienced developers.
As a contractor? I have to say I find this doubtful. Without seeing the contract, neither of us can say for sure, but I'd be surprised if it specified mentoring.
Usually "employer" don't know nowhere nearly as much about code as senior devs. If somebody was hired purely to do onboarding, they wouldn't have good grasp on the code either. Seniors who have up-to-date knowledge of the is best bet, no?
I don't think this is a healthy attitude to have towards less experienced developers. Literally every experienced developer was once inexperienced, and I think for the vast majority of people, it's hard to become a senior or even intermediate developer without some mentorship along the way.
I believe this is especially true for aspects outside of writing code. This probably isn't true at every company, but from where I've worked, a big part of being a senior engineer is understanding how to tie in business goals to development. That's not really easy to learn in a tutorial online or by contributing to open source.
Anyway, I would just take caution when writing comments like this, and realize that in order for our profession to live on, we need experienced people mentoring inexperienced people. You were there once upon a time, and you probably wouldn't have liked it if people called you a "shitty college grad" and refused to help you out.