6 ms·
RTFC is an asshole response. If they're refusing to read, it's time for the mentor to get in some pair reading time. Scenario: you tell the junior "we have thi
by delinka 7y ago
RTFC is an asshole response. If they're refusing to read, it's time for the mentor to get in some pair reading time.
Scenario: you tell the junior "we have this code that isn't documented. it's for a process that does X, but we need to understand how it goes about doing X. I need you to read and document the code." If they're refusing to do the task assigned, you've got a terrible employee, but you still don't have to be an asshole about it.
- austincheney 7y agoYou are making several assumptions to qualify to something vague. If a developer doesn't understand the code after reading it the time is ripe for the mentor to get in some pair development time. Refusing to read code isn't that. The junior shouldn't be held to account for their lack of understanding, but they should be destroyed for their lack of effort.
- leviathant 7y ago>they should be destroyed Are you real? Is this a real person?
- austincheney 7y agoWhat would you do?
- deleted 7y ago[deleted]
- leviathant 7y ago>What would you do? Specific to the topic of this subthread: read the code with them. "I was looking over your commit, and I thought it might be helpful to show you how I approach solving the same problem." And then literally function by function, line by line, I explain why I made the choice I made. And when it makes sense to do so, I compare it to the code being submitted, and I ask, "Do you understand why I would do B instead of A?" until they indicate that they get it. I leave my code in a separate branch, and ask them to push updated code to their branch. I suggest that even though they have a working solution in another branch, that they type in their updates rather than copy and paste. At a high level, I try to find them something better suited for them to do. Sometimes reading the manual (or the style guide, or the code) isn't the best way for that person to learn. So, maybe I help them find a different way of learning. Or maybe that means pointing them to a different role in the company, or having a chat and seeing if there's anyone I know in my network who could better employ them, that's what I do. If this person got hired, they were the best out of a bunch of applicants, so there's usually something worth pursuing. I've helped ecommerce merchandisers pivot to QA roles, front-end devs refocus on backend, backend developers go heavy into infrastructure and deployment... Several times in my career I've been the last stop for the developer that all the other devs have rejected as useless. Sometimes, hey, they're right. Someone got in way over their head and is being dishonest, and you have to level with them and send them on their way. If they're being an asshole, let -them- be the asshole. Even the worst coworker I've had deal with has never had me thinking, "they should be destroyed" - I even felt a little bad as [this particular person] finally got let go, because they had started to turn things around. But I also knew they'd be better suited elsewhere, and we were better off without this person. Several other times, I've seen people on the edge of being fired eventually grow into senior leads, after having some conversations about where they're struggling and what steps they could take to improve. Even people who refused to just read the code came to see past their insecurities and stubbornness, and became better at working with other people. Whether this has been someone in their 20s, or someone in their 50s, my approach has been to help work towards a better solution and solve for a problem... not to tell them to "RTFC or be destroyed". I knew a guy like that. A junior dev in the desk next to mine was struggling with some code, and this dude (notorious for being an asshole if you let him) was yelling at him about how he needs to just figure it out. I was fed up with these interactions, so I stood up and asked the asshole how he'd fix the problem. He stammered a bit, looked at the code a bit, and said he didn't know how to fix the problem either. Well, why are you being a dick about it if you can't help? He walked away, I helped the dev with the issue. I'm going to bring out that e-word here, because it's not just a buzzword to throw around, it's something that is incredibly helpful once you incorporate it into your problem solving: empathy. Find out why that person is struggling and help them.
- austincheney 7y agoThe nature of your comment is what I call apprehension. Let's be very clear that we are talking about a job that provides compensation in exchange for work. If there is something that is not understood, even a little bit, it is more than acceptable to ask questions. This is generally encouraged. However it is helpful to have some clear questions to ask. This is when a mentor can step through the code with them, line by line if necessary and that's fine. Simply throwing up your hands because life is hard isn't an acceptable answer. Yes, I have encountered this frequently. This is typically manifested by hoping a tool writes your code for you only to be followed by soul crushing defeat (and endless excuses) when the reality sets in that the tool in question is a leaky abstraction. Simply asking a developer to try does not an asshole make, but actually it does (matter of perspective). I call this entitlement. It isn't a lack of empathy. Empathy is manifest through good mentorship on the part of the mentor. You can bring a horse to water but you can't make it drink when they as they think they should have to. This confusion is why I am walking myself out of the corporate world. I just received a recruitment letter last week from one of the FAANG companies and I will not respond. I am tired of the fun and games. You can have it. I am on my way to somewhere more selective that takes mentorship a bit more seriously.
- leviathant 7y agoOne of the most consistent means of self-improvement I've found is to think about the behavior that other people exhibit that has been irritating me, and consider whether or not I'm actually upset about my own behavior and projecting that elsewhere. It sucks, but more often than not, I've found that the things I'm upset at other people over are reflections of my own behavior. So, just in this thread, I've noticed a few interesting statements. > I am in management, possibly longer than you have held your career. vs. > I do not assert superiority and I also don't make baseless assumptions about strangers on the internet. Do you understand how those two statements are in direct odds with each other? >Oh how I tire of profoundly sensitive people. vs. > This is what causes me to look for new employment and cry into my pillow at night. Obviously this is an attempt at humor, and it's funny, but maybe not in the way you were thinking. >Simply throwing up your hands because life is hard isn't an acceptable answer. > You can bring a horse to water but you can't make it drink when they as they think they should have to. > I do think of people who have trouble with confrontations as weak. [...] >This confusion is why I am walking myself out of the corporate world. [...] I am tired of the fun and games. So... you're confused, having trouble with confrontations, and are throwing your hands up... because you're weak and life is hard? ;) Sincerely though, best of luck in your future endeavors! A few paragraphs in an HN thread is in no way an complete insight into the years you've had working wherever it is you work. Nonetheless, in this window you opened up, I hope you see some patterns in the feedback you've gotten here on HN from your posts in this thread and take that into consideration when working with other people in the future. Enjoy what's left of the weekend!
- deleted 7y ago[deleted]
- dang 7y ago> they should be destroyed Please don't post flamebait to HN. It makes this place worse. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html