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.

Alright, I've already ranted about this but I feel like that was rather incomplete.. there's some other things that make me want to kill myself every time I enter <!DOCT- WHERE IS THAT FUCKING KNIFE?!!!

First one I've mentioned earlier is its <repetitiveness></repetitiveness>. What was wrong with {brackets}? If only HTML was more like CSS.

But there's some other ones as well.

- Frameworks! Ain't there nothing like a good dozen resources that every single one of your web pages wants to get JS from.

- Quantity over quality. Let's just publish early with tonnes of bugs, move fast and break things, amirite 🤪

- General noobness of apprentice web devs. Now I'm not talking about the real front-end devs here - AlexDeLarge was one of them.. forever holding a special place in my heart - that know how to properly use their tools. But there's a metric shitton of people who think that being able to write <html><body>Hello world!</body></html> makes them a dev.

- The general thought of "it's slow? Slap in more hardware." Now this is a general issue with software development, optimization costs valuable resources while leaving it in a shitty state but released quickly costs pretty much nothing. A friend of mine whose post I'll attach in the image section illustrates this pretty well. You can find it at https://facebook.com/10000171480431....

I'm not sure if this is an exhaustive list, but those are the most important things that irritate me about web development in general.

On a side note, apparently 113 people visited my hiddenbio.html page.. I'm genuinely impressed! I had no idea that so many people on devRant would click through. On Facebook pages this has been an ongoing significant issue of getting people to leave the platform - it's huge but engagement on off-Facebook links is terrible. I guess that I'm dealing with an entirely different community here. And I'm pleasantly surprised actually!

There has been a post today about the existence of too many js frameworks. Which reminds me of this awesome post https://hackernoon.com/how-it-feels...

At first I thought someone was corpseposting, as it is my understanding that the js ecosystem is calming down a bit. But then I noticed that post got almost 20 upvotes. So here's my thoughts:

(I'm not sure what I'm ranting about here, as it feels kinda broad after writing it. I think it's kinda valid anyhow.)

I'm ok with someone expressing frustration with js. But complaining about progress is definitely off to me.

How is too many frameworks a bad thing?

How does the variety and creation of more modern frameworks affect negatively developers?

Does it make it hard to understand each of these new frameworks?
Well, there's no need to. Just because it has a logo and some nice badges and says it will make you happy doesn't mean you should use it.
You just stick to the big boys in the ecosystem and you'll be fine for a while.

Does it make you feel compelled to migrate the stack of every project you did?

Well, don't. If you don't like being on the bleeding edge of js, then just stick to whatever you're using, as long as it's good code.

But if a lot of companies decided to migrate to react (among others frameworks), it's because they like the upsides: the code is faster to write, easier to test and more performant.

In general, I'm more understanding/empathic with beginner js programmers.

But I have for real heard experienced devs in real life complain about having to learn new frameworks, like they hate it.
"I just want to learn a single framework and just master it throughout my life" and I think they're lowering the bar.

There's people that for real expect occupying positions for life, make money, but never learn a new framework.

We hold other practitioners to high standards (like pilots or doctors), but for some reason, some programmers feel like they're ok with what they know for life.

As if they couldn't translate all they learned with one framework to another.

Meanwhile our lives are becoming more and more intertwined with technology and demand some pretty high standards. Standards that historically have not been met, according to thousands of people screaming to their devices screens.

Even though I think the "js can be frustrating" sentiment is valid, the statement 'too many js frameworks is bad' is not.

I think a statement like 'js frameworks can go obsolete very quickly' is more appropriate.

By saying too many js frameworks is a bad thing you're
1) Making a conspiracy theory as if js devs were working in tandem to make the ecosystem hard,

But people do whatever they want. Some create packages, others star/clone/use them.

2) Making a taboo out of a normal itch, creating.
"hey you're a libdev? just stop, ok? stop"
"Are you a creative person? Do you know a way to solve a problem in an easier way than some famous package? it doesn't matter, don't you dare creating a new package."

I'm not gonna say the js world is perfect. The js world is frantic, savage, evolves aggressively.
You could say that it (accidentally) gives the middle finger to end users, but you could also say that it just sets the bar higher.

I liked writing jquery code in the past, but at the same time I didn't like adding features/fixing bugs on it. It was painful.

So I'm fine with a better framework coming along after a few years and stealing their userbase, as it happens almost universally in the programming world, the difference with js is that the cycle is faster.

Even jquery's creator embraced React.

This post explains also
https://medium.com/@chrisdaviesgeek...

Critical Tips to Learn Programming Faster Sample:

Be comfortable with basics
The mistake which many aspiring students make is to start in a rush and skip the basics of programming and its fundamentals. They tend to start from the comparatively advanced topics.
This tends to work in many sectors and fields of Technology, but in the world of programming, having a deep knowledge of the basic principles of coding and programming is a must. If you are taking a class through a tutor and you feel that they are going too fast for your understanding, you need to be firm and clear and tell them to go slowly, so that you can also be on the same page like everyone else
Most often than not, many people tend to struggle when they reach a higher level with a feeling of getting lost, then they feel the need to fall back and go through basics, which is time-consuming. Learning basics well is the key to be fast and accurate in programming.

Practice to code by hand.
This may sound strange to some of you. Why write a code by hand when the actual work is supposed to be done on a computer? There are some reasons for this.
One reason being, when you were to be called for an interview for a programming job, the technical evaluation will include a hand-coding round to assess your programming skills. It makes sense as experts have researched and found that coding by hand is the best way to learn how to program.

Be brave and fiddle with codes
Most of us try to stick to the line of instructions given to us by our seniors, but it is extremely important to think out of the box and fiddle around with codes. That way, you will learn how the results get altered with the changes in the code.
Don't be over-ambitious and change the whole code. It takes experience to reach that level. This will give you enormous confidence in your skillset

Reach out for guidance
Seeking help from professionals is never looked down upon. Your fellow mates will likely not feel a hitch while sharing their knowledge with you. They also have been in your position at some point in their career and help will be forthcoming.
You may need professional help in understanding the program, bugs in the program and how to debug it. Sometimes other people can identify the bug instantly, which may have escaped your attention. Don't be shy and think that they'll make of you. It's always a team effort. Be comfortable around your colleagues.

Don’t Burn-out
You must have seen people burning the midnight oil and not coming to a conclusion, hence being reported by the testing team or the client.
These are common occurrences in the IT Industry. It is really important to conserve energy and take regular breaks while learning or working. It improves concentration and may help you see solutions faster. It's a proven fact that taking a break while working helps with better results and productivity. To be a better programmer, you need to be well rested and have an active mind.

Go Online
It's a common misconception that learning how to program will take a lot of money, which is not true. There are plenty of online college courses designed for beginner students and programmers. Many free courses are also available online to help you become a better programmer. Websites like Udemy and programming hub is beneficial if you want to improve your skills.
There are free courses available for everything from [HTML](https://bitdegree.org/learn/...) to CSS. You can use these free courses to get a piece of good basic knowledge. After cementing your skills, you can go for complex paid courses.

Read Relevant Material
One should never stop acquiring knowledge. This could be an extension of the last point, but it is in a different context. The idea is to boost your knowledge about the domain you're working on.
In real-life situations, the client for which you're writing a program for possesses complete knowledge of their business, how it works, but they don't know how to write a code for some specific program and vice versa.
So, it is crucial to keep yourself updated about the recent trends and advancements. It is beneficial to know about the business for which you're working. Read relevant material online, read books and articles to keep yourself up-to-date.

Never stop practicing
The saying “practice makes perfect” holds no matter what profession you are in. One should never stop practicing, it's a path to success. In programming, it gets even more critical to practice, since your exposure to programming starts with books and courses you take. Real work is done hands-on, you must spend time writing codes by hand and practicing them on your system to get familiar with the interface and workflow.
Search for mock projects online or make your model projects to practice coding and attentively commit to it. Things will start to come in the structure after some time.