This Part 3 and finale of the tale of Mr DDTW, or the worst coworker I've ever had to deal with. I suggest you start from the beginning if you don't have the context, it's been a trip.
Part 1: https://devrant.com/rants/4210605
Part 2: https://devrant.com/rants/4220715

The problem with this man threatening to snitch on me to the professor if I didn't revert my commit was that he backed me into a corner. Letting him go at his pace with his quality standards would have ruined the project for the rest of us, and I'm not going to let three other people's grades suffer because one was lazy. I'm the PM, team lead, the guy who will ultimately be held responsible for this project succeeding or failing and the mediator of problems.

So I snitched first.

The professor knew us. He had an idea of how we worked as a team, who was enthusiastic about this subject, who was diligent, and who wasn't. It'd been half a semester and he wasn't stupid. I'd also taken the not-so-minor task of testing our software and handling all the little integration problems between components and between the professor's server. This had resulted in several calls between me and him because he'd been flying by the seat of his pants with some of the upgrades he'd been doing to the server code and as the fastest group we were the ones running into all the bugs on his end. And he'd also noted our prior complaint and seen the discrepancy in commits, author tags and hours logged. Mr DDTW had been graded significantly worse than the rest of us. So when I sent him a goddamn novel about our team's internal problems, the bomb was set. And so we get to the conference call, with everybody panicking and with no clue what any of this is about. Except me.

Dear god. That call was pure catharsis. Never have I seen a man get demolished so hard. Mr DDTW got a 45 minute LECTURE, a goddamn SMACKDOWN, about how he needs to take some responsibility for this team effort and that in the real world he'd have been fired. And the professor was so incredibly serene throughout! He could've blasted him with the rage of a thousand suns but he said it in such a way that Mr DDTW's only real responses were "yes", "I understand" and "I'm sorry". An entire semester of this useless fucking bitch being nothing but a leech on our team in three separate projects and he was finally getting SCHOOLED. And then, it gets even better. The professor asked how we could solve this problem, as Mr DDTW needs to do work to be graded but he can't hold us back.

I dropped a suggestion: As I had implemented the module in a way that worked, we could carry on using my version while Mr DDTW could work on a separate branch. Everything else was working reasonably well for an MVP, we just needed to improve and test now, so if Mr DDTW got it working we could merge it back into the main branch. This solved the team's problem of not being able to progress, it solved Mr DDTWs problem of not wanting to fail the course, and it solved my problem of not having to work with this shit-for-brains for the forseeable future. A weight was lifted off my shoulders. No more Mr DDTW. No more bitching and no more shitcode. A grating arsehole that had been bugging everyone all sememster put in his place and out of my hair.

On the way home from uni that day, I rang a friend and told him the entire story as I needed to get it off my chest. Every time I brought up a problem, an issue, a setback, an argument, he made a remark.

"Damn, if only he just... did the work."

Every time he said it it was in a slightly different way, but every time it made me laugh harder as he just didn't stop interrupting me with the same comment. If only he did the work. But the funniest part of all was how right he was. Mr DDTW had so many opportunities to just sit down, shut up, and do the work like the rest of us, but instead he decided to do fuck-all until he got flak for it and proceeded to dig his own grave. What sort of delusional entitlement, sheer incompetence or other dumbfuckery was he suffering from to make such terrible decisions? It's his last year of university and he still hadn't learned to just do the goddamn work (I would later find out that his friend had covered his shortcomings a lot and was apparently the reason why he hadn't flunked out of uni yet).

And so ends the story of Mr Didn't Do The Work the worst person I have ever had the displeasure of working with. We never did merge his branch as we ran out of time during testing. The professor passed him, possibly out of pity or just so that he wouldn't have to resit the course and burden some other poor sods. We weren't the top scorers this time, partially because of my shortcomings as PM but mostly because of the huge delays and manpower deficit, but we did well enough to pass the course with some very high grades. With one exception of course.

In reply to this:
https://devrant.com/rants/260590/...

As a senior dev for over 13 years, I will break you point by point in the most realistic way, so you don't get in troubles for following internet boring paternal advices.

1) False. Being go-ahead, pro active and prone to learn is a good thing in most places.
This doesn't mean being an entitled asshole, but standing for yourself (don't get put down and used to do shit for others, or it will become the routine) and show good learning and exploration skills will definitely put you under a good light.
2)False. 2 things to check:
a) if the guy over you is an entitled asshole who thinkg you're going to steal his job and will try to sabotage you or not answer acting annoyed, or if it's a cool guy.
Choose wisely your questions and put them all togheter. Don't be that guy that fires questions in crumbles, one every 2 minutes.
Put them togheter and try to work out the obvious and what can be done through google or chatgpt by yourself. Then collect the hard ones for the experienced guy and ask them all at once. He's been put over you to help you.

3) Idiotic. NO.
Working code = good code. It's always been like this.
If you follow this idiotic advice you will annoy everyone.
The thing about renaming variables and crap it's called a standard. Most company will have a document with one if there is a need to follow it.
What remains are common programming conventions that everyone mostly follows.

Else you'll end up getting crazy at all the rules and small conventions and will start to do messy hot spaghetti code filled with syntactic sugar that no one likes, included yourself.

4)LMAO.
This mostly never happens (seniors send to juniors) in real life.
But it happens on the other side (junior code gets reviewed).
He must either be a crap programmer or stopped learning years ago(?)

5) This is absolutely true.
Programming is not a forgiving job if you're not honest.
Covering up mess in programming is mostly impossible, expecially when git and all that stuff with your name on it came out.
Be honest, admit your faults, ask if not sure.
Code is code, if it's wrong it won't work magically and sooner or later it will fire back.

6)Somewhat true, but it all depends on the deadline you're given and the complexity of the logic to be implemented.
If very complex you have to divide an conquer (usually)

7)LMAO, this one might be true for multi billionaire companies with thousand of employees.
Normal companies rarely do that because it's a waste of time. They pass knowledge by word or with concise documentation that later gets explained by seniors or TL's to the devs.
Try following this and as a junior:
1) you will have written shit docs and wasted time
2) you will come up to the devs at the deadline with half of the code done and them saying wtf who told you to do that

8) See? What an oxymoron ahahah
Look at point 3 of this guy than re-read this.
This alone should prove you that I'm right for everything else.

9) Half true.
Watch your ass. You need to understand what you're going to put yourself into.
If it's some unknown deep sea shit, with no documentations whatsoever you will end up with a sore ass and pulling your hair finding crumbles of code that make that unknown thing work.
Believe me and not him.
I have been there. To say one, I've been doing some high level project for using powerful RFID reading antennas for doing large warehouse inventory with high speed (instead of counting manually or scanning pieces, the put rfid tags inside the boxes and pass a scanner between shelves, reading all the inventory).
I had to deal with all the RFID protocol, the math behind radio waves (yes, knowing it will let you configure them more efficently and avoid conflicts), know a whole new SDK from them I've never used again (useless knowledge = time wasted and no resume worthy material for your next job) and so on.
It was a grueling, hair pulling, horrible experience that brought me nothing in return execpt the skill of accepting and embracing the pain of such experiences.

And I can go on with other stories. Horror Stories.
If it's something that is doable but it's complex, hard or just interesting, go for it. Expecially if the tech involved is something marketable.

10) Yes, and you can't stop learning, expecially now that AI will start to cover more and more of our work.