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.
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?
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...
So if you get laid off, it is probably a favor.
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.
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.
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.
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.
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.
Each company has different priorities. Some value face to face and direct team interaction. Others flexibility. Find one that suits your values.
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.
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)
> 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.
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.
I don't find your slippery slope argument compelling.
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.
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).
> 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.
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.
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?
Just so I know I'm understanding you correctly, are you saying that you refuse to tell your coworkers how code you write works?
Maybe the key is 100% remote though. I hear remote sucks if it's not ingrained in a companies communication patterns.
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.
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?
> 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".
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...
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.
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.
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 ;)
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.
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.
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.
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.
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.
You may want to look for a job on Wall Street (or at Amazon).
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.
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.
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.
Besides, training less experienced people is job expectation, exactly as writing unit tests and readabe code is job expectation. Nothing to do with morality.
* 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.
> 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.
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)
Did you ever consider that "top performers" are those who do more than "get [their] assigned work done and leave it at that"?
A good video chat system and IRC can substitute well enough though.
pretty broad statement to make, though I can see it having some merit in certain instances
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.
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.
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.
> 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.
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.