it's funny, how doing something for ages but technically kinda the wrong way, makes you hate that thing with a fucking passion.

In my case I am talking about documentation.

At my study, it was required to write documentation for every project, which is actually quite logical. But, although I am find with some documentation/project and architecture design, they went to the fucking limit with this shit.

Just an example of what we had to write every time again (YES FOR EVERY MOTHERFUCKING PROJECT) and how many pages it would approximately cost (of custom content, yes we all had templates):

Phase 1 - Application design (before doing any programming at all):
- PvA (general plan for how to do the project, from who was participating to the way of reporting to your clients and so on - pages: 7-10.
- Functional design, well, the application design in an understandeable way. We were also required to design interfaces. (Yes, I am a backender, can only grasp the basics of GIMP and don't care about doing frontend) - pages: 20-30.
- Technical design (including DB scheme, class diagrams and so fucking on), it explains it mostly I think so - pages: 20-40.

Phase 2 - 'Writing' the application
- Well, writing the application of course.
- Test Plan (so yeah no actual fucking cases yet, just how you fucking plan to test it, what tools you need and so on. Needed? Yes. but not as redicilous as this) - pages: 7-10.

- Test cases: as many functions (read, every button click etc is a 'function') as you have - pages: one excel sheet, usually at least about 20 test cases.

Phase 3 - Application Implementation
- Implementation plan, describes what resources will be needed and so on (yes, I actually had to write down 'keyboard' a few times, like what the actual motherfucking fuck) - pages: 7-10.
- Acceptation test plan, (the plan and the actual tests so two files of which one is an excel/libreoffice calc file) - pages: 7-10.
- Implementation evalutation, well, an evaluation. Usually about 7-10 FUCKING pages long as well (!?!?!?!)

Phase 4 - Maintaining/managing of the application
- Management/maintainence document - well, every FUCKING rule. Usually 10-20 pages.
- SLA (Service Level Agreement) - 20-30 pages.
- Content Management Plan - explains itself, same as above so 20-30 pages (yes, what the fuck).
- Archiving Document, aka, how are you going to archive shit. - pages: 10-15.

I am still can't grasp why they were surprised that students lost all motivation after realizing they'd have to spend about 1-2 weeks BEFORE being allowed to write a single line of code!

Calculation (which takes the worst case scenario aka the most pages possible mostly) comes to about 230 pages. Keep in mind that some pages will be screenshots etc as well but a lot are full-text.

Yes, I understand that documentation is needed but in the way we had to do it, sorry but that's just not how you motivate students to work for their study!

Hell, students who wrote the entire project in one night which worked perfectly with even easter eggs and so on sometimes even got bad grades BECAUSE THEIR DOCUMENTATION WASN'T GOOD ENOUGH.

For comparison, at my last internship I had to write documentation for the REST API I was writing. Three pages, providing enough for the person who had to, to work with it! YES THREE PAGES FOR THE WHOLE MOTHERFUCKING PROJECT.

This is why I FUCKING HATE the word 'documentation'.

"My code is explain itself. Well, I need no comments to understand it."

I don't care if you wan't to write comments or not; If don't write any then i don't care because fuck you and your code.

May it be java, kotlin, python, javascript or anyother language, you think "everyone can read", i hope you'll never find anyone who has to deal with you and your cancerous code.

Another gem from my Database Fundamentals class, this time it's from the textbook:

So right now we're learning about data modeling with ERDs and the book is explaining a few things about attributes. I got to a part where the book was explaining when you should split an attribute into many (the book mixes up conceptual modelling and logical modelling). The first example the book gave was an address, splitting it up by street name, address number, city, postal code, etc. So far so good. Now we get to the second example: a phone number. The book split the the number 55 11 9784-8900 into four parts:

Country code: 55
Area code: 11
Number prefix: 9784
Number suffix: 8900

At this point I was like "WHAT?". Separating area and country codes from the rest of the number is ok, that's useful, but splitting the number itself in half? Why the fuck would you want to do that? Correct me if I'm wrong but the dash in the middle of the number is just used for "chunking", to make it easier for our brains to read the number. Why would you want to split the number in half? There's literally no reason to do it, at least not in the example the book was showing.

Every time I open this book I keep wondering why the hell my teacher chose it to be our textbook. He's a great teacher, his lectures are awesome, he explains stuff super well, but he chose this book. A book that's filled with shitty literal translations to domain-specific words and acronyms, shitty examples, and convoluted sentences.