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