Comment by grardb | Hacker News Reader

Comment by grardb | Hacker News Reader

Parent Full thread

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.

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?

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-efficienc...

The solution there is direct, open communication. With each new-hire you need to train if you don't have capacity you need to raise it with your management chain and let them know that you can either on-board or ship feature X.

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.

The root problem here seems to be organization and task assignment. Unless the project is exceptionally complicated or badly designed, it should be easy or at least possible to separate easy tasks for less experienced people.

Irrespective of how small or isolated the task, you have to train them to do it. And more often than not with a junior hire, you have to re-do their work anyways, or baby-sit them the entire time while you tell them what to write.

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.

I enjoy teaching people who like learning. The effort required to teach those who aren't that curious saps my energy, and eats into time I need to advance my own skills. I didn't work super hard to learn what I've learned just to give it away to someone who is indifferent.

I think you are being a bit dramatic, however what you describe does happen to some extent. When it does, its either a management failure for not responding to the senior software engineer voicing concerns that his/her time is not spent in the proper proportion between work/mentoring, or, it is the fault of the senior software engineer for just sitting there, refusing as much as possible to help the less experienced co-worker, whilst not properly communicating it upwards. It is certainly not the fault of the one asking the questions.

My god this sounds exactly like academia: your job as a professor at a research university is to obtain grants, publications, and donations. Pretty much everything else is incidental. "Service" to a department, to students, etc. is "emphasized" in reviews, but if push comes to shove, the asshole with a bunch of big grants is going to steamroll the "nice" junior faculty who "mentors" the asshole's students. If you're teaching, preparing to teach, or holding office hours, you're not writing grants or manuscripts. And the odds are that everyone will say "thank you so much!!" as you get turned down for tenure, UNLESS you managed to satisfy your true primary responsibilities so efficiently as to leave time for the "fun" stuff (teaching, watching people discover, blah blah)

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.)

Just like academia the onus of learning is on the individual in all settings. The senior guy or the professor owes nothing to the junior folks or students, if they themselves don't care.

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.

Or lack of documentation/communication within the company.

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.

Other coworkers send the new hires directly to you so your manager doesn't even see the amount of questions you're answering

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.

If your responses to questions aren't well written and concise confluence/wiki pages (with an example or two) - you're doing it wrong.

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.

> 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?

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.

> [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.

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.

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.)

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.

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.

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?

Sure, but this needs to be accounted for and the regular workload for such seniors needs to be appropriately reduced.

>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

> 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.

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.

I've been a contractor and led teams and mentored juniors on a number of occasions - I don't think it's very unusual at all. I don't know if it would be literally specified in a written contract in those terms, but it's very much what happens in reality.

Reply on news.ycombinator.com