3 ms·
Seeing some of the responses in this thread, I hope some of you never manage people, especially anyone junior/mid. If you have a (eager) junior on your team an
by FridgeSeal 3y ago
Seeing some of the responses in this thread, I hope some of you never manage people, especially anyone junior/mid.
If you have a (eager) junior on your team and they contribute a helpful, but sub-par quality PR for some issue, the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself.
You’ve destroyed morale, wasted their time and yours, ensured that they haven’t learnt anything - and thus won’t be able to improve or meaningful contribute next time and you’ve likely dissuaded them from asking for help or volunteering for anything next time. Even if they waded into a hectic past of the codebase, there’s better ways to handle this interaction.
- mellosouls 3y agoSeeing some of the responses in this thread : the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself. You should perhaps read through again, that's not what appears to have happened, or at least it's possibly an emotional retelling of one side of the story.
- Cyph0n 3y agoNo, that is exactly what happened: A new kernel contributor spent 5 days investigating an issue only to have their fix slightly adjusted and committed by a tenured maintainer. See comparison: https://news.ycombinator.com/item?id=37673443 https://news.ycombinator.com/item?id=37673443 How should have this been handled? Easy: something called “code review”. The maintainer could have simply reviewed the patch and suggested what changes need to be made for it to be accepted. And if the maintainer really wants some credit for some odd reason, they can get the Reported-By tag. Win-win! But what ended up happening is a loss of (at least) one potential long-term contributor. I for one definitely thought more highly of kernel maintainers.
- mellosouls 3y agoNo, that is exactly what happened No. It's not as simple as represented in the OP, though perhaps your suggestion would have been a useful approach to consider. See the details of the discussion in the email thread.
- Cyph0n 3y agoCould have OP presented their case in a more neutral manner? Sure. But it is nonetheless an extremely frustrating situation that was handled terribly.
- bitcharmer 3y agoRight?! It's so disappointing to see so many toxic comments here. This thread feels a little like one of the worse ones on LKML. The guy literally did 95% of the work and he gets criticised here for wanting to be recognized for that. What is wrong with people.
- _gabe_ 3y agoIf you have an overeager junior that went off and spent a week resolving a task that wasn’t prioritized and wasn’t what they were supposed to be working on, I think you could rightly take them aside and tell them “we’ll have to table this for now and come back to it later. Right now we’re prioritizing X and can’t be spending time on…”. Being a professional is partly about learning how to dissociate yourself from your work, and to realize 99% of the time, your teammates aren’t trying to sabotage you for some nefarious scheme. We’ve all worked on projects for months that eventually got canned. We’ve all gotten rough comments in a code review. It’s up to you as a professional to take those things in stride and learn from it rather than letting that stuff destroy your morale. And of course, the people who are blunt and rude will also have to learn that being blunt and rude ruins many relationships. But we’re all professionals here, not artists. If a junior civil engineer was building a bridge and ended up designing it with structural defects, and the senior engineer came up to him and said “I’m sorry we’re just going to have to redo all this because it’s unsalvageable at this point”. The senior is perfectly fine in this case! I don’t want to drive on shoddy bridges built to protect a juniors ego. Edit: I also think a lot of the comments responding talking about how toxic the maintainer is may not have much experience maintaining a large open source project. I’ve had contributors for some of my OSS projects, and accepting a PR from a random person is a lot of work. Often, it’s more work than doing it yourself. The amount of time needed to carefully review the code, communicate with the contributor to fix issues, make sure the code is upholding the expected quality and expectations is immense. At a job, a junior has already been vetted through an interview process. It’s not some random stranger requesting a change. There’s way more factors here than many of the dissenters here seem to be taking into account. And getting a PR rejected does suck. But having been on both sides I understand both sides. It’s a difficult situation and it’s hard to resolve these things without upsetting someone unintentionally. (Based on the maintainers communication, it doesn’t seem like they were being particularly nasty or rude).
- deleted 3y ago[deleted]
- andrewmcwatters 3y agoYeah, this thread is a lightning rod for people demonstrating bad interpersonal relationships and it’s really cringeworthy considering what the age range of HN readers can be.
- hnfong 3y agoThere's a difference between managing or coaching juniors in your company/team, and random persons on the Internet offering a tiny patch. There's an expectation for junior devs on your team to stick around for a while, and presumably there was an interview process that established some baseline ability so you're reasonably confident that they can grow towards your expectations. The random person on the internet isn't obliged to stick around, and most often for these kind of "drive-by" fixes they won't be. You don't know the actual abilities of this random person and how well they'd respond to your comments on their fixes. If we're talking about management, IMHO one of the most frustrating things of managing people is when somebody else assigns random people as your reports and you're now responsible for their performance. Now imagine some random self-entitled person on the Internet spent a couple days working on a sub par fix, and now you're responsible for coaching them as if you're their manager? The analogy is honestly ridiculous. I often wondered what the big fuss was about when people talked about hosting projects on github and unwanted PRs (eg. https://news.ycombinator.com/item?id=25940799 https://news.ycombinator.com/item?id=25940799 ) Now I kind of understand. Not wanting to deal with random PRs and you'd be accused of "destroying morale, wasting people's time" and being a bad manager. Such insane ideas of entitlement...