Hacker News Reader

Comment by humbleMouse | Hacker News Reader

There is a dirty secret that nobody talks about and the real reason that companies want programmers in the office.

Companies want their top performers in the office so they can serve as trainers/mentors/teachers to the new college kids and the incompetent older people they hire.

I think this is the real reason companies crack down on working from home. It's infuriating as a top performer - I just want to get my assigned work done and leave it at that. I don't want to teach all your shitty college grads how to actually code.

edit: I'm not against mentoring people and helping build teamwork, knowledge sharing, etc. I'm just saying that an all out ban on WFH makes me feel like I am sitting in an open office all day doing other people's assigned work.

I actually am very social and enjoy teaching and helping people. I just wish it wasn't one extreme or the other - I can still mentor/knowledge share with tools like WebEx.

edit2: I am a contractor who was recently banned from WFH. We used to have a very lax WFH policy and it was great. Now I'm banned from WFH completely. The article was discussing the merits of WFH policies, which I am commenting on.

View on HN

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

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.

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.

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.

How is that a dirty secret?

Helping build the team, sharing your knowledge and expertise, it's all part of your work. Odd attitude.

If you purely want technical tasks, go freelance. Of course then you need to spend time getting business so...

Maybe still not a secret, but the dirty part in some companies is that if there are layoffs, they'll lay off the people who are paid the highest and keep the people that they trained.

Still though, treating all junior developers as competition and your potential replacements, and thus refusing to help them, is shooting yourself in the foot. On the rare chance that you do get laid off, you can always find a new job, but what's much more likely is that a pattern of good mentorship will help you to advance in your career.

Plus those juniors might end up being part of your network next time around!

And having good peer reviews is helpful for performance reviews and promotion anyway. If everyone you've ever worked with hates you because you go out of your way to not ever be helpful to anyone, your career trajectory is going to be terrible. Working well with others, which includes enabling other members of the team to be maximally productive, is hugely important.

When companies are laying off their top performers to save money either (a) they are falling apart, likely near death, and you should leave anyway or (b) they are just a stupid shitty company that doesn't understand the value of top developers so you should leave anyway.

So if you get laid off, it is probably a favor.

Not much of a favor if you don't see it coming and still have bills to pay.

But a true "top performer" would have another job in a week (especially in a tech hub), no?

They don't all live in tech hubs, there are many very good reasons not to jump into one of the first offers you get, and just because you're a top performer at Widget Co doesn't mean that every other company you apply to will find that self-evident based on a few interviews.

That has never happened in my experience, and I've been through a lot of layoffs. It's usually the exact opposite. They lay off all the peons and keep the few high level experts. They're a lot harder to replace.

Same here. Order seems to be:

1) Bad contractors, 2) Bad employees, 3) Good contractors, 4) Good employees with Mgt going along the way from bottom to top. Pay doesn't usually seem to be the deciding influence except within the groups.

One of the places I've seen do it the best first moved the few good people off of the worst teams and then just got rid of entire teams at a time.

If you really are a top performer, a big part of the justification for your high pay is because you multiply your impact by mentoring more junior employees.

I respectfully disagree. The justification for my high pay is because I integrate complex systems with shitty vendor web service api's and automate the transmission of sensitive data. The work I am doing has a huge impact on profitability of my company - much more than the joke of a 6 figure rate they are paying to keep me around.

I avoid being a fulltime employee because I don't want to have some unwritten commitment/fake loyalty to the company I am working for. I am a contract employee - I am here to get the work done you assign me. If you ban me from WFH, it's an insult to my professionalism and work ethic.

Nobody wants your unwavering loyalty... mentorship is a part of any job. From bagging at your local grocery store, to the CEO of a Fortune 500.

No offense, but it just sounds like you don't really like being around/interacting with people. Theres not necessarily anything wrong with that, but it's not really conducive to long term success... whether that success be in your job, or life in general.

Not that I agree with humbleMouse ,as I view mentoring juniors as something I should pass on for having been mentored when I was a junior, but there are lots of companies I've interviewed for that do want unwavering loyalty. Ones that view <5 years at a job as job hopping even when they give 0% raises every year

Then take a job that has a strong remote policy?

Each company has different priorities. Some value face to face and direct team interaction. Others flexibility. Find one that suits your values.

> The justification for my high pay is because I integrate complex systems with shitty vendor web service api's and automate the transmission of sensitive data. The work I am doing has a huge impact on profitability of my company - much more than the joke of a 6 figure rate they are paying to keep me around.

be that as it may, mentoring, helping others, and setting examples are high-leverage. you may become 10x more valuable if you do your job while being effective at those.

these things are only at odds with your engineering work in that they take time, but a highly skilled professional knows how to manage their time to maximize impact.

they are also not at odds with working outside of the office -- there are many ways to communicate, you can be at the office only some times, etc.

I completely disagree about him becoming 10x more valuable. That only works if he's actually evaluated on these things. He probably isn't, nor are most technical workers. Now, if he were a manager/team leader, this would be very different: those are absolutely core aspects of the job and things to be evaluated on in your performance review.

Out of curiosity: if you are a contract employee, what does 6 figure rate mean? Contractors are usually paid an hourly rate.

i assume he means once calculated for yearly, it would be that of a 6 figure rate

Yes, this is a normal assumption, but then 6-figure sounds like s/he is seriously underpaid for a contractor. Assuming when people say 6-figure they mean something just above 100,000. Nobody says "I make 6-figure", if earns let say 250,000.

Depends on where the contracting is done. "Highly paid" is relative.

Well, you can disagree, but every engineering manager I've ever worked with would be surprised to hear you say that.

Small test - what would happen if you shared these thoughts with your boss? Maybe you work for a company that doesn't care about mentoring newbie employees, but I'd be surprised if that was the case.

Sorry, but if your 6-figure rate is a joke, go get a higher rate, or even better, go out and start your own company. If you build your own company you will understand the value that other roles have and get away from the arrogant mentality that good code is the most valuable thing. The fact is, you aren't in a position to evaluate the value that all the other roles are bringing to the company.

There's a reason that very few companies have a strong technical track, and managers tend to get paid more than ICs. It's because managing personalities and orchestrating teams to operate efficiently has a huge magnifying effect on productivity. On a purely technical track, you can have an even bigger impact if you are a highly skilled architect, but only if there are technical challenges of that scope, which is not the case for most companies.

A cognitive trap that programmers can fall into is that their work is the hardest and most valuable because of its exacting nature. Given the details you have to understand and reconcile, it's true that you can't bullshit your way very far as a developer the way that some managers can, but that said, since no one else is probably taking the time to understand your work in great detail, it's very easy to spin a self-serving story of your own superiority. Don't make the mistake of thinking that because you are technical your self-assessment is objective, it is not.

Also, a large part of being an architect is basically shuffling and convincing people to get on board with your vision, since you're not going to write much of the code yourself. Being personable goes far, being difficult means people tend to not actually do what you need and make fun of you after the meeting. I've witnessed both.

Indeed. I've been interviewing candidates for "Senior Developer" and mentoring is in the job spec and list of questions we consider when evaluating candidates.

If someone gets hired with "mentoring" in their job description I don't think it's reasonable for them to expect to do none of it. Now, if their performance metrics don't account for this, that might be unreasonable ..

(C++ in Edinburgh, if you happen to be looking for a job)

C/C++ amongst others, 10+ years, available immediately! (Seriously)

Was trying to work out how to give you the info without either of us posting personal information in the absence of a PM system AND the job is erroneously not listed on our website. Sigh. Probably easiest to phone the number on http://www.zonal.co.uk/zonal_careers/ and ask about the C++ job in Research&Development at Edinburgh.

Thanks, will do.

If thats true, it should be an explicit part of a job description. Not an implicit expectation.

At most big companies with a formal title ladder, this is an explicit criteria for being a "senior" engineer.

That's a very myopic view of your job responsibilities. Presuambly you had mentors yourself earlier in your career that helped you out greatly. I know I did. If they'd all been working from home, and thus were unavailable for the kind of help that they gave me, I might not be where I am today. Helping along the next generation of coders is part of your job description. Most employers would rather have a good programmer who can build up the effectiveness of the rest of their team than a great solo programmer who doesn't have any knock-on effects in making the rest of the team more productive.

> I just want to get my assigned work done and leave it at that. I don't want to teach all your shitty college grads how to actually code.

That's not a healthy outlook, and if any of my coworkers held such a view, it would be a negative for me.

I'm not the person you replied to, but ...

> Presuambly you had mentors yourself earlier in your career that helped you out greatly.

From personal experience, that certainly isn't a given.

My first job writing software was working solo. They had someone before I showed up, but that person left for greater things.

As the only person there, and having been hired right out of high school, I felt a strong responsibility to get things right. So I'd do my best during the day, and then then I'd spend 6-8 hours after work reading blogs/books, poring over my work, seeing if I could make anything better.

I didn't have anyone to mentor me in the things I did:

* Set up a Subversion server

* Set up automated testing, and imposed a strict lower bound for code coverage

* Sped up the existing code-base 20x over a weekend with FP-inspired parallelism (Microsoft's Task Parallel Library, PLINQ)

* Reduced the code size considerably through better approaches to architecture and design (OOP stuff like SOLID, and general good judgement), though I can't recall the exact reduction

* Proposed, designed and implemented systems that automated away many hours of daily work for each of the non-technical staff (takeaway: eat lunch with the people you're trying to help, try to find stuff that they take for granted that could be automated away)

And the list goes on quite a ways.

And then I got an offer somewhere else that subsequently doubled my (at the time, minuscule) salary. They were impressed that I had written an interface in my programming assessment (this was C#), as they "hadn't personally found a use for them". There were no automated tests, because tests were impossible to write due to coupling (recall that they didn't user interfaces -- there was zero abstraction). When Inversion of Control (specifically Dependency Injection) was suggested, implemented, and example tests provided -- all during my lunch hours -- the entirety of the work was rejected as being too "weird". Bear in mind that the effort had also removed 20K lines of copy-pasted-and-slightly-edited boilerplate -- boilerplate that would continue to accrete in a similar fashion with each new feature. It was a major bummer: these were industry veterans (20+ years of development experience each), and yet the code was in shambles, and they couldn't recognize when things were an improvement.

As someone who would desperately love to be the least capable person in the room, I can't say that's ever been the case throughout my career, at least professionally. Conferences are an entirely different thing: when I go somewhere like Compose Conference, I chat with people working at the frontier of type theory, optimizing automatic differentiation, etc. It's equally inspiring and humbling. While all of those people would be super awesome to work for/with, they're invariably either starving academics or they can't afford me by a wide margin.

So no, not everyone has had the pleasure of having a mentor.

Interestingly, I think it's precisely because I haven't had a mentor that I always extend an offer to mentor others -- including people I haven't even met in person. I reflect on all the stupid shit I've done in the past, and how I could have avoided many hundreds of hours chasing my own tail if someone had been in my life to:

* Point out when something is provably impossible (e.g. solving the halting problem)

* Point out the best algorithm (or class of algorithms) for an unfamiliar problem -- or perhaps most importantly, give a name to the problem you're trying to solve

* Distill and share the essence of wisdom / good judgement when it comes to design (instead of me spending many hundreds of hours reading over open source, trying to learn bottom-up while attempting to glean the author's mindset)

* Give me a vocabulary to help accelerate my learning (things were often hard to research because I lacked words like: extent, binding, continuation, etc)

* Etc, etc, etc

Sadly, very few people reach out. Every now and then I'll see that someone is struggling with something, and then I'll help them flesh out their understanding. Once it clicks you can see a big smile light up across their face, and then they'll say something like "damn, where were you when I got stuck a couple days ago -- that's precisely what I needed!"

And then I don't hear from them.

What's wrong with asking questions over email? Is physical presence actually needed for effective mentoring?

Your view taken to the extreme would mean that this thread itself is dysfunctional because people aren't face-to-face and instead discussing on a message board.

There are a variety of situations for which direct face-to-face communication, or two people huddling in front of the same computer, is the best low-latency, high-bandwidth mode of communication. I use email all the time, but it's not always the optimal mode of communication. Just yesterday I spent an hour mentoring the most junior member of my team through our tricky dependency injection setup by sitting in front of the same computer with him. It would have been harder remotely.

I don't find your slippery slope argument compelling.

Why couldn't you have provided the same kind of mentoring over email? If you had a guide detailing the steps of the setup your junior developer could follow it. If he or she had any additional questions then he or she could have mailed them to you.

I would understand if you said you didn't like typing or that you enjoyed being in proximity of others. But I don't buy the claim that methods other than face-to-face communication would be objectively inferior.

What you are describing would've taken days, whereas I got him squared away in an hour. I know because he'd already been stuck on it for days, with him asking the occasional question in person and via chat. It wasn't until we sat down together and went through the process of how to make these kinds of modifications step-by-step that he really got it.

We don't have guides for how to make every different potential change to the code. That'd take more time to write than I currently spend coding, and they'd constantly be getting out of date with every refactoring. And anyway, the change I was walking him through was a refactoring of a kind we hadn't yet done before, so no guide would've existed anyway (and, if written, would likely be a one-off). I'm not spending hours writing a speculative guide on how to make that change, which I couldn't even write properly without actually making that change, when it takes much less total time just to sit down with him and work through it together.

I don't understand what programming world you are talking about, because it's completely different from my own. My experience has been that collaborative, high latency development mentorship via email tends to take an order of magnitude more walltime than sitting down and writing the code together end-to-end (similar to "extreme programming", but for mentoring).

What a horrible attitude. I hope you're just having a bad day and this isn't how you typically act around other because I wouldn't even want to work in the same building as you when as a supposed "top performer" you don't feel the slightest obligation to share your knowledge, your skills, your experience, etc with "shitty college grads." I'm sure you were born knowing how to code so you can't relate, but for everyone else, we were all terrible programmers at some point. The only reason we're not is because someone took the time to document their knowledge, be it through a book, a blog, an online tutorial, or college.

> you don't feel the slightest obligation ...

No morality whatsoever emanates from a company's bottom line. It can certainly not compete with my own bottom line. How can you expect people to agree to train their own competition? Publishing general open-source code is ok, but telling other people how the code works that you write and maintain for a living ... why would anybody do that?

One compelling reason: if you need to hire down the road (once you're CTO/manager/equivalent), it makes much more sense to hire devs who you've trained and invested in at a previous company.

> telling other people how the code works that you write and maintain for a living ... why would anybody do that?

Just so I know I'm understanding you correctly, are you saying that you refuse to tell your coworkers how code you write works?

Because your job is not to gatekeep at the companies expense?

I'm not saying I don't enjoy mentoring people and sharing knowledge! I'm saying that it is unreasonable for companies to ban WFH, and I explained what I think is the true motivation behind that decision.

To clarify - companies are banning WFH so they can lower their hiring bar and take on incompetent people and not have to pay for or provide any company training. They just rely solely on their senior people to teach the new people everything.

The article was about WFH policies, and that's what I am commenting on. I'm not saying mentorship == bad or coming into the office == never. I'm saying mentorship can be done while working from home, and banning it is a terrible company policy.

I work at a 100% remote company and I have no trouble getting the mentorship I desire/need from more experienced folks.

Maybe the key is 100% remote though. I hear remote sucks if it's not ingrained in a companies communication patterns.

How do you handle discussing complex code, data structures and such concepts over online? In such cases, I find that being in the same room and using a white board makes it easy to communicate across. Maybe some programming domains that type of issue if less common?

Some kind of screen sharing app with Krita = virtual whiteboard. You have a lot more room than a real whiteboard offers, since Krita has a "pseudo-infinite" canvas, so you don't need to erase things. And you can save the file for reference, or to send it other people.

Sometimes (not too often) I do such things remotely.

In my case, voice call + screen sharing works OK. On the screen sharing I can use whatever software I find adequate, be it Word, Visio, Paint.net, balsamic mockups, etc.

As a side effect, we can continue working on those documents/diagrams/whatever after the discussion, e.g. include it in the documentation. Much harder to achieve with a white board as someone needs to digitize those drawing. In my experience working offline with whiteboards, no one actually doing that. In the best case, a digital photo is kept somewhere no one will be looking, in the worst case the board is just wiped clean.

In some cases people literally point their camera at a whiteboard!

You laugh, but it works really well to do this so long as you remember to stand out of the way of the camera.

My previous job wasn't really setup to do remote work but we had a second team working almost 12 hours opposite (Romania vs Kansas). The "offshore" team was paying a heavy tax because everyone was working at the office, so we had a ton of hallway conversations that never got documented anywhere they could access it. Even though everyone knew this, because we were co-located it was extremely difficult to overcome because it's just so easy to not document things. When your entire team is 100% remote, you are forced to document things a lot more since there aren't hallway conversations unless you specifically video chat with a single individual.

As a junior software developer, it's sad to hear this point of view. Many of us put an extraordinary amount of time towards improving our craft.

On the other hand I've worked with many people who have very similar opinions as yours and they suffered from reality distortion. Their code was poorly implemented and poorly tested, despite what they say, and caused many headaches.

Are you actually a top performer in the software world?

True top performers are constantly trying to expand their skills. The only way you do that is by interacting with other people, even less experienced/talented folks. You don't get new insights by being around the same great people all the time.

Linus Torvalds wrote Linux from his dorm room. John Carmack wrote the Doom engine solo. Einstein worked alone, the inventor of PCR did it alone, Wozniak, Picasso, Hendrix, Mitnick.

Holy crap almost all incredible innovations were invented by solitary passionate people working alone!

Then we have Cascading Style Sheets..that.. was invented by a committee...

Einstein didn't work alone http://www.nature.com/news/history-einstein-was-no-lone-geni...

Torvalds didn't either https://en.wikipedia.org/wiki/History_of_Linux#Chronology note 100+ devs in 1993 working on the kernel to build a userland for it. If they didn't you'd just have another toy kernel floating around nobody uses.

Edit: Apparently Hendrix didn't work alone either he claimed Foxey Lady was just something him and his band put together while randomly playing during a rehearsal.

You're conflating 'influences' and 'being part of a team'.

Einstein used the tools that were available to him. He was influenced by other people sure.

But Einsteins WORK WAS HIS ALONE.

IT WAS NOT THE RESULT OF A TEAM.

By your logic... because I contributed to the Linux documentation I was part of the thousand person team that invented Linux!!!

Adding that to my resume!!! I invented Linux!!

In all seriousness, there's a difference between influences and being part of a team...

All major human innovations, at their root, have resulted from passionate smart people working alone without a team to make them compromise on any aspect of their vision.

Hey, documentation (along with device drivers and userland apps) are tremendously important. Without them, linux would have been another toy project and none of us would have heard of it.

Also linux follows in the footsteps of minix and other closed source unix systems right out of Bell Labs, so it's not like he wasn't drawing on a larger body of work. Hard to say he was inventing a whole lot of new stuff as opposed to duplicating an existing refined design. And large parts of what he did write were eventually replaced by others (the scheduler has gone through several iterations now), so those pieces are at least collaborative.

The lone solo genius is a trope for an Ayn Rand novel, not achievement in real life.

The closest thing is a guy who has a mental illness (or should I say non-neurotypical?) and writes code by himself for himself. But I'm sure even he uses stack overflow ;)

Agreed. We all stand on the shoulders of giants.

The point is one SOLO GENIUS took all of the tools available to them at that point in history and made something amazing.

By your logic we have to go back and say cavemen inventing fire are key contributors to the Linux kernel because fire was an important tool to the creation of civilization which was critical for the invention of operating systems.

Well if you want to take my logic down the slippery slope of your own invention then you can make me claim anything :)

I don't doubt the importance of taking ownership for your projects and having good taste, as opposed to design-by-committee. But I think you're overstating the degree to which they worked isolated from others. I think these examples you've given involve people with good taste (or call it vision) who said no to a lot of prevailing wisdom and yes to other ideas... but it wasn't literally "I'm going to go into my house for 5-10 years and emerge out with perfection". It's usually more iterative.

To add to sibling, Hendrix didn't work alone. Not only did Noel Redding and Mitch Mitchell (the rest of the Jimi Hendrix Experience) contribute massively to his work, but Hendrix spent the first 3 years of his (unfortunately only 6 year) career cutting his teeth (literally) as a backing player for much bigger performers (Isley Brothers, Sam Cooke).

While he had influences...at the end of the day... you went to the show to see JIMI FUCKING HENDRIX.

As a more senior individual myself, don't sweat it there's plenty of us who love to expand our tool belt and mentor those following the path.

> Are you actually a top performer in the software world?

Having to ask that question should be an answer in of itself, a resounding "no".

I get what you're saying, it sucks training the new guy. It is however, the sign of a good/great programmer/performer to be able to train other people. Also, frankly, it just has to be done. Companies don't want to lock their knowledge into a few good people.

You take on the challenge of efficiently "getting your assigned work done". I'd challenge you to take on the task of teaching others with the same mentality you approach your "regular" work. Do it as efficiently and productively as possible. Then when you're done, go about your day.

> Companies don't want to lock their knowledge into a few good people.

It is not their knowledge. It is these "few good people"'s knowledge.

> I'd challenge you to take on the task of teaching others ...

Never, ever. Only idiots agree to train their own competition.

You sound like a horrible person to work with. Software development is a collaborative process. I would never want to work with someone who treats all of their peers as competition and refuses to help them achieve the team's mutual goals, and were I your manager, I'd likely fire you.

It is not uncommon that the people seeking to be mentored are lazy to put any effort into learning. It is also not uncommon for a lazy manager to put an effort to see how much this senior programmer is mentoring other. It is also not uncommon that this senior person might have learnt all his/her skills from books/discussions forums etc. Some of these senior programmers put their personal time because they are passionate about their craft. Please don't make assumptions that anybody who is not so pleased about sharing his skills is not a team player. Oftentimes, a lazy manager pits team members against each others. You sound like that horrible manager to work with. If I were your team member, I would find another manager.

To be fair, with their mindset, they are probably right to view everyone else as competition. They clearly feel the clock ticking down to their termination, and management is probably trying to replace them as we speak.

A developer with no leadership or social skills is very replaceable. Unlike software development, those are the skills you can't develop alone in the bedroom.

People who can actually get work done and do the hard things are hard to come by, unfortunately. You can be quite an asshole if you deliver and there's no one else around competent enough to take over.

All I can really say is that I'm sorry you have this mindset. You can share knowledge and cultivate the people around you without worrying about your job or treating your coworkers as competition. I think that that actually makes you more valuable.

You may want to look for a job on Wall Street (or at Amazon).

This is cynical and depressing, but it's less off the mark than people here seem to think. In a _well_ run company, this attitude doesn't make sense. But in a company that does not respect or have loyalty to its employees, this attitude should be the expected result. Over time, it seems like more and more companies are falling into the second category and they will get the employees they deserve.

Peer mentoring is part of your job in any field. It's not a secret that your better people are supposed to help train other employees. Senior people train junior people, people with expertise in a domain share it, etc. Some fields even make this formal at the early levels, with apprenticeships, but I've worked in a number of fields and never had this not be the expectation.

It's part of why you (should) get paid more than them.

The real "dirty secret" is if you're not a team player, you're not a top performer because force multiplication through mentoring adds more value than the difference in your individual work.

> Peer mentoring is part of your job in any field.

All morality in a corporate setting is fake by design. Everybody simply maximizes their own bottom line, and if you don't too, you are an idiot. Training your own competition is simply not a way to maximize your revenue.

I disagree on three levels:

1) I don't think the premise is true, that everyone maximizes their bottom line figure.

2) Prisoner dilemma logic is suboptimal in the iterated prisoner's dilemma. Alliances are a thing in ongoing relationships.

3) Even if I were trying to maximize my individual value, training would still benefit me. Programmers with strong mentoring and management skills are more valuable to the corporations than programmers with just technical skills. Mentoring increases my value as a force multiplier faster than it increases any individual mentee's value.

If you are immoral in corporate setting, then you are immoral person. There is nothung special about work that would up it outside of morality.

Besides, training less experienced people is job expectation, exactly as writing unit tests and readabe code is job expectation. Nothing to do with morality.

In "The Mythical Man-Month", Fred Brooks writes about two concepts that I think are important considerations when deciding whether to leave the experienced programmer alone or train up the team:

* The communication overhead that adding more programmers adds. Training time can be thought of as a manifestation of this tradeoff. * The conceptual cohesiveness that comes from having one developer or a small team design a system, as opposed to a free-for-all design that can arise when a large team is unleashed on a program.

Whether or not to train teammates is (ideally) a development strategy, given the needs of the business.

You're backpedalling hard, but it doesn't change the fact that you said:

> I just want to get my assigned work done and leave it at that. I don't want to teach all your shitty college grads how to actually code.

I'd say stay behind your statement, man. If that's how you feel, that's how you feel, and despite the fact that your feelings are generating ire from those that are more generous with their time, backpedaling isn't going to make anybody think you don't feel that way.

If the scope of your work is to "just code" then fair point. On a previous job I was supposed to:

a) do my thing, b) teach people to learn to do my thing..

Lync worked miracles doing that and we could all WFH while doing the (b)

(I still dislike the "Skype for biz..." name)

You are rationalizing this. If they were into mentoring they would push for pair programming or trainee programs. It's a pure control thing.

Maybe companies want their top performers in the office in order to force them to develop their social skills.

With that attitude, you should stay remote.

You had it backwards - should have read "new older people and incompetent college kids"

Are you compensated / rewarded for your mentorship? That is, come performance review time, does "I spent half of my time at work in the last year training folks and they said it was great" count as a positive, or a negative because you were expected to get other things done?

For engineers/developers, mentoring is not necessarily having a seasoned person training someone with no experience. Everyone on the team has a different background and experience. We ran into an issue the other day where we identified a developer misunderstanding how a certain kind of technology is supposed to be used. This developer is outstanding on many levels, super focused and a great asset. English is also not their native language. Try describing a concept over Skype with paint.exe. It is much easier to put it on a white board so everyone can see how their piece fits into the larger picture. Having everyone in the same location brings synergy you can’t achieve in remote locations and timezones especially if you are a startup.

You can't consider yourself a "top performer" if you are unable to mentor the more junior folks below you. You should check that chip on your shoulder, because "top performer" programmers do not self apply such a title.

That can be one of the reasons, but not necessarily the only reason. I have experienced this in my own career, for sure. Top performers sometimes are implicitly disallowed from performing because they are too busy making up for the mistakes of others. Unfortunately, often these top performers don't have the authority to make the necessary staffing changes that would actually lead to success.

Some people like to learn by themselves, some others are careful to only ask the necessary questions, and some others think it's part of your job to teach them. That's a common situation in an office, though i m not sure its the real reason why someone would not offer you work-from-home arrangement. I do understand how annoying it must be for a contractor though.

>It's infuriating as a top performer - I just want to get my assigned work done and leave it at that. I don't want to teach all your shitty college grads how to actually code.

Did you ever consider that "top performers" are those who do more than "get [their] assigned work done and leave it at that"?

I'm not buying the training/mentoring argument. Companies want their hires to have all the knowledge about what they use before they are hired. If you don't have those skills and this experience, you simply won't be hired in favor of someone who does.

This is likely true, and I've actually been told that directly by a company's recruiter. They wanted me on-site to mentor and guide other developers.

A good video chat system and IRC can substitute well enough though.

If you are senior and getting paid enough it is kind of part of your job.

> the real reason that companies want programmers in the office

pretty broad statement to make, though I can see it having some merit in certain instances

> Companies want their top performers in the office so they can serve as trainers/mentors/teachers to the new college kids and the incompetent older people they hire.

It is not hard to avoid training your own competition. Three people have left in despair over the last two years trying to get me to train them. I just happen to be not particularly talkative when it is about the details of my work.

I'm not sure why you call it a dirty secret. It's not dirty or a secret.

programming is a team sport - you might well be better than average but if you're leaving your team to eat dust then you may well be causing more harm than good.

what did you do bro

I don't want to teach all your shitty college grads how to actually code.

Only a very inexperienced developer would actually want to work with people who aren't as good as they are. I genuinely want to be the worst person on my team. I'm pretty good, so that would mean we could do some amazing stuff.

>Only a very inexperienced developer would actually want to work with people who aren't as good as they are.

Not true.

>I genuinely want to be the worst person on my team.

I feel the same way, but only because I've adjusted to the role and enjoy relentlessly leeching knowledge from the top performers.

>> Only a very inexperienced developer would actually want to work with people who aren't as good as they are.

> Not true.

Could you explain your position on this?

I feel that perhaps "inexperienced" is the wrong adjective, but rather developers whose ego or lack of desire to progress would want to work with people who aren't as good as them. "Inexperienced" is a decent approximation of that description as experienced developers with no desire to progress would be rare.

It could also mean you will do all the routine menial work and will never get a chance to touch something more complicated :). I have seen more experienced seniors to treat less experienced junior pretty badly in the past. Junior did not learned all that much imo nor was given chance.

Reply on news.ycombinator.com