5 ms·

This comment doesn't read like it was written by a "humbleMouse" :) I don't think this is a healthy attitude to have towards less experienced developers. Liter

by grardb 9y ago

This comment doesn't read like it was written by a "humbleMouse" :) 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.

jt2190 9y ago
> I think for the vast majority of people, it's hard to become a senior or even intermediate developer without some [on the job] mentorship along the way. 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?
- grardb 9y ago
  As I wrote in my comment: >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.
  - jt2190 9y ago
    > [Formal education in software development] 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.
- chillacy 9y ago
  At the few places I've worked I've found a large part of the training was company-specific or team-specific tribal knowledge (here's how you restart our service, here's how our data pipeline works) that was either not actually documented, or documented somewhere in a wiki and despairingly out of date or unfindable. That's arguably the fault of the team, but one of the companies (can't mention names) flat out said that it was one of their strengths to be a "storytelling" company.
- jt2190 9y ago
  Downvoters: Consider the context of this thread... Imagine you're asked to train your peers for no extra compensation or credit, and you're still expected to produce 100% of the typical work output. At the same time, your peers are compensated at the same rate, are considered equally for raises and promotions, but are not expected to train anyone. 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.)
  - icebraining 9y ago
    The issue of having too much work for your time is valid, but it hadn't been raised, as far as I can see, and it's mostly irrelevant whether it's mentoring or any other kind of work.
freehunter 9y ago
I completely understand where he's coming from in writing that. Sometimes it feels like my entire day is spent training new hires, repeating the same things over and over again. In jobs where being an expert is a requirement, it's very frustrating to see the company hire employees fresh out of college and expect the senior employees to feed them 10 years of experience in a matter of weeks. And then either they take that knowledge and leverage it into a higher paying job or they get discouraged that they were hired for a job they are woefully unprepared for (through no fault of their own) and they leave. And then the company hires more college grads for pennies on the dollar and the cycle repeats. 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?
- jrs235 9y ago
  This problem exists because companies and management are overly concerned and focusing on resource efficiency rather than for flow efficient. http://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-1-seeing-your-system/ http://www.jrothman.com/mpd/agile/2015/09/resource-efficienc...
- 9y ago
droopyEyelids 9y ago
Healthy for who? The way you're using it, healthy is a weasel word. 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.
- mantas 9y ago
  Isn't it expected that mentoring is fundamental part of being a senior worker? 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?
  - TeMPOraL 9y ago
    Sure, but this needs to be accounted for and the regular workload for such seniors needs to be appropriately reduced.
- grardb 9y ago
  >Healthy for who? The way you're using it, healthy is a weasel word. "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. [0] https://www.quora.com/What-is-healthy-attitude https://www.quora.com/What-is-healthy-attitude
robotjosh 9y ago
This attitude is understandable. A lot of the "college grads" I graduated with were people who I watched for 4 years not try very hard and walk away with the same degree as I had after I worked really hard preparing myself to be an effective engineer. Then I watched as they got nice paying desk jobs while I work around the clock being a freelance engineer who has to deliver working products to get paid. Hard work and dedication are what this job takes, not somebody older holding your hand. Looking at the code and process of older engineers is valuable but you have to proactively do that, it is part of being a dedicated engineer.

by grardb 9y ago

jt2190 9y ago

> I think for the vast majority of people, it's hard to become a senior or even intermediate developer without some [on the job] mentorship along the way. 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?

grardb 9y ago
As I wrote in my comment: >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.
- jt2190 9y ago
  > [Formal education in software development] 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.
chillacy 9y ago
At the few places I've worked I've found a large part of the training was company-specific or team-specific tribal knowledge (here's how you restart our service, here's how our data pipeline works) that was either not actually documented, or documented somewhere in a wiki and despairingly out of date or unfindable. That's arguably the fault of the team, but one of the companies (can't mention names) flat out said that it was one of their strengths to be a "storytelling" company.
jt2190 9y ago
Downvoters: Consider the context of this thread... Imagine you're asked to train your peers for no extra compensation or credit, and you're still expected to produce 100% of the typical work output. At the same time, your peers are compensated at the same rate, are considered equally for raises and promotions, but are not expected to train anyone. 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.)
- icebraining 9y ago
  The issue of having too much work for your time is valid, but it hadn't been raised, as far as I can see, and it's mostly irrelevant whether it's mentoring or any other kind of work.

freehunter 9y ago

I completely understand where he's coming from in writing that. Sometimes it feels like my entire day is spent training new hires, repeating the same things over and over again. In jobs where being an expert is a requirement, it's very frustrating to see the company hire employees fresh out of college and expect the senior employees to feed them 10 years of experience in a matter of weeks. And then either they take that knowledge and leverage it into a higher paying job or they get discouraged that they were hired for a job they are woefully unprepared for (through no fault of their own) and they leave. And then the company hires more college grads for pennies on the dollar and the cycle repeats. 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?

jrs235 9y ago
This problem exists because companies and management are overly concerned and focusing on resource efficiency rather than for flow efficient. http://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-1-seeing-your-system/ http://www.jrothman.com/mpd/agile/2015/09/resource-efficienc...
9y ago

droopyEyelids 9y ago

Healthy for who? The way you're using it, healthy is a weasel word. 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.

mantas 9y ago
Isn't it expected that mentoring is fundamental part of being a senior worker? 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?
- TeMPOraL 9y ago
  Sure, but this needs to be accounted for and the regular workload for such seniors needs to be appropriately reduced.
grardb 9y ago
>Healthy for who? The way you're using it, healthy is a weasel word. "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. [0] https://www.quora.com/What-is-healthy-attitude https://www.quora.com/What-is-healthy-attitude

robotjosh 9y ago

This attitude is understandable. A lot of the "college grads" I graduated with were people who I watched for 4 years not try very hard and walk away with the same degree as I had after I worked really hard preparing myself to be an effective engineer. Then I watched as they got nice paying desk jobs while I work around the clock being a freelance engineer who has to deliver working products to get paid. Hard work and dedication are what this job takes, not somebody older holding your hand. Looking at the code and process of older engineers is valuable but you have to proactively do that, it is part of being a dedicated engineer.