Attended one of the best meetups ever. To give you an idea how awesome it was..

Speaker took the first ~20 minutes introducing himself.
His intro card deck kept referring to himself in the third person (he is the only employee in consulting 'company'). Ex. "Mr. Smith began his humble career .."

The powerpoint presentation began with him clicking each page, not executing the slideshow (ex. pressing F5).
Finally someone asked "Can you make slide bigger?"

S:"You can't read that?..um..sure...I guess .."
Starts fumbling around the zoom ...
Dev: "No, can you start the slideshow?"
S: "I don't know what you mean...there...I zoomed it, is that better? Now I can't see my notes..just sec.."
<fumbles again with the zoom>
Dev: "No, not zoom, start the slide show, press F5"
S: "Oh...you want me to F5 it...OK..."
<he *clicks* the slide show button>

Finally getting into code, trying to get out of powerpoint ...
S: "How do I get out of this fullscreen?.."
Dev: "Hit escape"
S:"No..um.."
<keeps trying to click on 'something'>
S:"I see visual studio, but its not on the big screen... "
<keeps click on 'something', no one is sure whats going on>
Dev: "Hit Escape to stop the slideshow"
<finally hits escape, then able to put Visual Studio on the big screen>
S: "Ahh...there, I figured it out."

Speaker had no end of making wild/random statements like:
".Net Core is the future of Microsoft, if you're using .Net 4.5...forget it, its not even supported anymore."
"When I was at Microsoft Build, I asked them why not put all the required .Net assemblies in one directory. Looks like with .Net Core, they listened to me" (he was serious)
"I don't use SQL Server Mgmt Studio. Its free and it sucks. I use <insert a very expensive SSMS clone>, its great, you guys should check it out", then proceeds to struggle to open a query window to write some SQL.
"When you use .Net Core and EntityFramework, you have to write your own stored procedures. If a developer can't write stored procedures, he shouldn't be in this business."

I was on the edge of my seat, hungry for the next crazy bat-shit thing to come out of his mouth. He did not disappoint. BEST MEETUP EVER!

I have been a mobile developer working with Android for about 6 years now. In that time, I have endured countless annoyances in the Android development space. I will endure them no more.
My complaints are:

1. Ridiculous build times. In what universe is it acceptable for us to wait 30 seconds for a build to complete. Yes, I've done all the optimisations mentioned on this page and then some. Don't even mention hot reload as it doesn't work fast enough or just does not work at all. Also, buying better hardware should not be a requirement to build a simple Android app, Xcode builds in 2 seconds with a 8GB Macbook Air. A Macbook Air!

2. IDE. Android Studio is a memory hog even if you throw 32GB of RAM at it. The visual editors are janky as hell. If you use Eclipse, you may as well just chop off your fingers right now because you will have no use for them after you try and build an app from afresh. I mean, just look at some of the posts in this subreddit where the common response is to invalidate caches and restart. That should only be used as a last resort, but it's thrown about like as if it solves everything. Truth be told, it's Gradle's fault. Gradle is so annoying I've dedicated the next point to it.

3. Gradle. I am convinced that Gradle causes 50% of an Android developer's pain. From the build times to the integration into various IDEs to its insane package management system. Why do I need to manually exclude dependencies from other dependencies, the build tool should just handle it for me. C'mon it's 2019. Gradle is so bad that it requires approx 54GB of RAM to work out that I have removed a dependency from the list of dependencies. Also I cannot work out what properties I need to put in what block.
4. API. Android API is over-bloated and hellish. How do I schedule a recurring notification? Oh use an AlarmManager. Yes you heard right, an AlarmManager... Not a NotificationManager because that would be too easy. Also has anyone ever tried running a long running task? Or done an asynchronous task? Or dealt with closing/opening a keyboard? Or handling clicks from a RecyclerView? Yes, I know Android Jetpack aims to solve these issues but over the years I have become so jaded by things that have meant to solve other broken things, that there isn't much hope for Jetpack in my mind 😤

5. API 2. A non-insignificant number of Android users are still on Jelly Bean or KitKat! That means we, as developers, have to support some of your shitty API decisions (Fragments, Activities, ListView) from all the way back then!

6. Not reactive enough. Android has support for Databinding recently but this kind of stuff should have been introduced from the very start. Look at React or Flutter as to how easy it is to make shit happen without any effort.

7. Layouts. What the actual hell is going on here. MDPI, XHDPI, XXHDPI, mipmap, drawable. Fuck it, just chuck it all in the drawable folder. Seriously, Android should handle this for me. If I am designing for a larger screen then it should be responsive. I don't want to deal with 50 different layouts spread over 6 different folders.

8. Permission system. Why was this not included from the very start? Rogue apps have abused this and abused your user's privacy and security. Yet you ban us and not them from the Play Store. What's going on? We need answers.

9. In Android, building an app took me 3 months and I had a lot of work left to do but I got so sick of Android dev I dropped it in favour of Flutter. I built the same app in Flutter and it took me around a month and I completed it all.
10. XML.

If you're a new dev, for the love of all that is good in this world, do NOT get into Android development. Start with Flutter or even iOS. On Flutter and build times are insanely fast and the hot reload is under 500ms constantly. It's a breath of fresh air and will save you a lot of headaches AND it builds for iOS flawlessly.

To the people who build Android, advocate it and work on it, sorry to swear, but fuck you! You have created a mess that we have to work with on a day-to-day basis only for us to get banned from the app store! You have sold us a lie that Android development is amazing with all the sweet treat names and conferences that look bubbly and fun. You have allowed to get it so bad that we can't target an API higher than 18 because some Android users are still using devices that support that!

End this misery. End our pain. End our suffering. Throw this abomination away like you do with some of your other projects and migrate your efforts over to Flutter. Please!

#NoToGoogleIO #AndroidSummitBoycott #FlutterDev #ReactNative

Look... I know I'm just a newbie. I started a year ago as a junior. Sure. No one wants to do code review, so I got chosen to do it. People don't like it when their code gets criticised. And you know what? I get it, I should probably be a bit nicer with my comments. I should not suggest I'll make a fork and split internal library into two streams if things continue this way. I should not ask questions that can be understood as me being passive-aggressive.

But holy fucking shit, you're a senior developer. Don't treat Java as a fucking scripting language. Don't have a method that has 600 lines of code, because you're repeating the code! You've already copy pasted this shit, and modified it slightly. Like, couldn't you have created some architecture around the code? How can a senior dev copy-paste code?

Oh and why the fuck did you create a new utility class for functionality I already provide? Look, I admit, yours is a lot better, ok? It has extra functionality. But why the fuck didn't you enhance my utility class? Why did you create a new one? Did you just not want to touch my code, or did you not see it right below your newly created class?

Am I the only one who fucking cares about maintainable code in this company? When I got hired, I was in tears by how frustrating a lot of the things were. No documentation anywhere, not even fucking comments. No processes in place. Want to do something? Source code is your documentation. Fuck you! I busted my ass of to force everyone to document every little bullshit, to re-factor their MRs that I reviewed, and I won't let even a senior fucking dev pollute the code base!

Fuuuuuck... Me...

Worst fight I've had with a co-worker?

Had my share of 'disagreements', but one that seemed like it could have gone to blows was a developer, 'T', that tried to man-splain me how ADO.Net worked with SQLServer.

<T walks into our work area>
T: "Your solution is going to cause a lot of problems in SQLServer"
Me: "No, its not, your solution is worse. For performance, its better to use ADO.Net connection pooling."
T: "NO! Every single transaction is atomic! SQLServer will prioritize the operation thread, making the whole transaction faster than what you're trying to do."
<T goes on and on about threads, made up nonsense about priority queues, on and on>
Me: "No it won't, unless you change something in the connection string, ADO.Net will utilize connection pooling and use the same SPID, even if you explicitly call Close() on the connection. You are just wasting code thinking that works."

T walks over, stands over me (he's about 6.5", 300+ pounds), maybe 6 inches away

T: "I've been doing .net development for over 10 years. I know what I'm doing!"

I turn my chair to face him, look up, cross my arms.

Me: "I know I'm kinda new to this, but let me show you something ..."

<I threw together a C# console app, simple connect, get some data, close the connection>

Me: "I'll fire up SQLProfiler and we can see the actual connection SPID and when sql server closes the SPID....see....the connection to SQLServer is still has an active SPID after I called Close. When I exit the application, SQLServer will drop the SPD....tada...see?"
T: "Wha...what is that...SQLProfiler? Is that some kind of hacking tool? DBAs should know about that!"
Me: "It's part of the SQLServer client tools, its on everyone's machine, including yours."
T: "Doesn't prove a damn thing! I'm going to do my own experiment and prove my solution works."
Me: "Look forward to seeing what you come up with ... and you haven't been doing .net for 10 years. I was part of the team that reviewed your resume when you were hired. You're going to have to try that on someone else."

About 10 seconds later I hear him from across the room slam his keyboard on his desk.

100% sure he would have kicked my ass, but that day I let him know his bully tactics worked on some, but wouldn't work on me.

When I was in college OOP was emerging. A lot of the professors were against teaching it as the core. Some younger professors were adamant about it, and also Java fanatics. So after the bell rang, they'd sometimes teach people that wanted to learn it. I stayed after and the professor said that object oriented programming treated things like reality.

My first thought to this was hold up, modeling reality is hard and complicated, why would you want to add that to your programming that's utter madness.

Then he started with a ball example and how some balls in reality are blue, and they can have a bounce action we can express with a method.

My first thought was that this seems a very niche example. It has very little to do with any problems I have yet solved and I felt thinking about it this way would complicate my programs rather than make them simpler.

I looked around the at remnants of my classmates and saw several sitting forward, their eyes lit up and I felt like I was in a cult meeting where the head is trying to make everyone enamored of their personality. Except he wasn't selling himself, he was selling an idea.

I patiently waited it out, wanting there to be something of value in the after the bell lesson. Something I could use to better my own programming ability. It never came.

This same professor would tell us all to read and buy gang of four it would change our lives. It was an expensive hard cover book with a ribbon attached for a bookmark. It was made to look important. I didn't have much money in college but I gave it a shot I bought the book. I remember wrinkling my nose often, reading at it. Feeling like I was still being sold something. But where was the proof. It was all an argument from authority and I didn't think the argument was very good.

I left college thinking the whole thing was silly and would surely go away with time. And then it grew, and grew. It started to be impossible to avoid it. So I'd just use it when I had to and that became more and more often.

I began to doubt myself. Perhaps I was wrong, surely all these people using and loving this paradigm could not be wrong. I took on a 3 year project to dive deep into OOP later in my career. I was already intimately aware of OOP having to have done so much of it. But I caught up on all the latest ideas and practiced them for a the first year. I thought if OOP is so good I should be able to be more productive in years 2 and 3.

It was the most miserable I had ever been as a programmer. Everything took forever to do. There was boilerplate code everywhere. You didn't so much solve problems as stuff abstract ideas that had nothing to do with the problem everywhere and THEN code the actual part of the code that does a task. Even though I was working with an interpreted language they had added a need to compile, for dependency injection. What's next taking the benefit of dynamic typing and forcing typing into it? Oh I see they managed to do that too. At this point why not just use C or C++. It's going to do everything you wanted if you add compiling and typing and do it way faster at run time.

I talked to the client extensively about everything. We both agreed the project was untenable. We moved everything over another 3 years. His business is doing better than ever before now by several metrics. And I can be productive again. My self doubt was over. OOP is a complicated mess that drags down the software industry, little better than snake oil and full of empty promises. Unfortunately it is all some people know.

Now there is a functional movement, a data oriented movement, and things are looking a little brighter. However, no one seems to care for procedural. Functional and procedural are not that different. Functional just tries to put more constraints on the developer. Data oriented is also a lot more sensible, and again pretty close to procedural a lot of the time. It's just odd to me this need to separate from procedural at all. Procedural was very honest. If you're a bad programmer you make bad code. If you're a good programmer you make good code. It seems a lot of this was meant to enforce bad programmers to make good code. I'll tell you what I think though. I think that has never worked. It's just hidden it away in some abstraction and made identifying it harder. Much like the code methodologies themselves do to the code.

Now I'm left with a choice, keep my own business going to work on what I love, shift gears and do what I hate for more money, or pivot careers entirely. I decided after all this to go into data science because what you all are doing to the software industry sickens me. And that's my story. It's one that makes a lot of people defensive or even passive aggressive, to those people I say, try more things. At least then you can be less defensive about your opinion.

A /thread.

I have to say something important. As the story progresses, the rage will keep fueling up and get more spicy. You should also feel your blood boil more. If not, that's because you're happy to be a slave.

This is a clusterfuck story. I'll come back and forth to some paragraphs to talk about more details and why everything, INCLUDING OUR DEVELOPER JOBS ARE A SCAM. we're getting USED as SLAVES because it's standardized AS NORMAL. IT IS EVERYTHING *BUT* NORMAL.

START:

As im watching the 2022 world cup i noticed something that has enraged me as a software engineer.

The camera has pointed to the crowd where there were old football players such as Rondinho, Kaka, old (fat) Ronaldo and other assholes i dont give a shit about.

These men are old (old for football) and therefore they dont play sports anymore.

These men don't do SHIT in their lives. They have retired at like 39 years old with MULTI MILLIONS OF DOLLARS IN THEIR BANK ACCOUNT.

And thats not all. despite of them not doing anything in life anymore, THEY ARE STILL EARNING MILLIONS AND MILLIONS OF DOLLARS PER MONTH. FOR WHAT?????

While i as a backend software engineer get used as a slave to do extreme and hard as SHIT jobs for slave salary.

500-600$ MAX PER MONTH is for junior BACKEND engineers! By the law of my country software businesses are not allowed to pay less than $500 for IT jobs. If thats for backend, imagine how much lower is for frontend? I'll tell you cause i used to be a frontend dev in 2016: $200-400 PER MONTH IS FOR FRONTEND DEVELOPERS.

A BACKEND SOFTWARE ENGINEER with at least 7-9 years of professional experience, is allowed to have $1000-2000 PER MONTH

In my country, if you want to have a salary of MORE THAN $3000/Month as SOFTWARE ENGINEER, you have to have a minimum of Master's Degree and in some cases a required PhD!!!!!!

Are you fucking kidding me?

Also. (Btw i have a BSc comp. sci. Degree from a valuable university) I have taken a SHIT ton of interviews. NOT ONE OF THEM HAVE ASKED ME IF I HAVE A DEGREE. NO ONE. All HRs and lead Devs have asked me about myself, what i want to learn and about my past dev experience, projects i worked on etc so they can approximate my knowledge complexity.

EVEN TOPTAL! Their HR NEVER asked me about my fycking degree because no one gives a SHIT about your fucking degree. Do you know how can you tell if someone has a degree? THEY'LL FUCKING TELL YOU THEY HAVE A DEGREE! LMAO! It was all a Fucking scam designed by the Matrix to enslave you and mentally break you. Besides wasting your Fucking time.

This means that companies put degree requirement in job post just to follow formal procedures, but in reality NO ONE GIVES A SHIT ABOUT IT. NOOBOODYYY.

ALSO: I GRADUATED AND I STILL DID NOT RECEIVE MY DEGREE PAPER BECAUSE THEY NEED AT LEAST 6 MONTHS TO MAKE IT. SOME PEOPLE EVEN WAITED 2 YEARS. A FRIEND OF MINE WHO GRADUATED IN FEBRUARY 2022, STILL DIDNT RECEIVE HIS DEGREE TODAY IN DECEMBER 2022. ALL THEY CAN DO IS PRINT YOU A PAPER TO CONFIRM THAT I DO HAVE A DEGREE AS PROOF TO COMPANIES WHO HIRE ME. WHAT THE FUCK ARE THEY MAKING FOR SO LONG, DIAMONDS???

are you fucking kidding me? You fucking bitch. The sole paper i can use to wipe my asshole with that they call a DEGREE, at the end I CANT EVEN HAVE IT???

Fuck You.

This system that values how much BULLSHIT you can memorize for short term, is called "EDUCATION", NOT "MEMORIZATION" System.

Think about it. Don't believe be? Are you one of those nerds with A+ grades who loves school and defends this education system? Here I'll fuck you with a single question: if i gave you a task to solve from linear algebra, or math analysis, probabilistics and statistics, physics, or theory, or a task to write ASM code, would you know how to do it? No you won't. Because you "learned" that months or years ago. You don't know shit. CHECK MATE. You can answer those questions by googling. Even the most experienced software engineers still use google. ALL of friends with A+ grades always answered "i dont know" or "i dont remember". HOW IF YOU PASSED IT WITH A+ 6 DAYS AGO? If so, WHY THE FUCK ARE WE WASTING YEARS OF AN ALREADY SHORT HUMAN LIFE TO TEMPORARILY MEMORIZE GARBAGE? WHY DONT WE LEARN THAT PROCESS THROUGH WORKING ON PRACTICAL PROJECTS??? WOULDNT YOU AGREE THATS A BETTER SOLUTION, YOU MOTHERFUCKER BITCH ASS SLAVE SUCKA???

Im can't even afford to buy my First fuckinf Car with this slave salary. Inflation is up so much that 1 bag of BASIC groceries from Walmart costs $100. IF BASIC GROCERIES ARE $100, HOW DO I LIVE WITH $500-600/MONTH IF I HAVE OTHER EXPENSES?

Now, back to slavery. Here's what i learned.

1800s: slaves are directly forced to work in exchange for food to survive.

2000s: slaves are indirectly forced to work in exchange for money as a MIDDLEMAN that can be used to buy food to survive.

????

This means: slavery has not gone anywhere. Slavery has just evolved. And you're fine with it.

Will post part 2 later.

Yes, come tell me there's a user experiencing an issue, but you don't know on which page or exactly what it was. I'll fix that right away.

Title: The problem with "good enough" code

Body:

I'm a software developer, and I've seen my fair share of "good enough" code. You know the kind of code I'm talking about: it works, but it's not pretty, and it's not very maintainable.

The problem with "good enough" code is that it's a slippery slope. Once you start writing "good enough" code, it's easy to fall into the trap of always taking the easy way out.

Before you know it, your code is a mess of hacks and workarounds. It's hard to understand, it's hard to maintain, and it's a nightmare to debug.

I've seen projects go down in flames because of "good enough" code. The code was so bad that it was impossible to fix, and the project had to be scrapped.

I'm not saying that you should never write "good enough" code. Sometimes, you just need to get something working, and you don't have the time or resources to do it perfectly.

But if you're going to write "good enough" code, you need to be aware of the risks. And you need to make sure that you're only writing "good enough" code for a short period of time.

Once you have a working prototype, you need to start refactoring your code and making it better. You need to make it more readable, more maintainable, and more testable.

If you don't, you'll eventually regret it. Your code will become a liability, and it will hold you back.

So next time you're tempted to write "good enough" code, think twice. It might save you some time in the short term, but it will cost you in the long run.

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

I can't help it sounding bitter..
If you work some amount of time in tech it's unavoidable that you automatically pick up skills that help you to deal with a lot of shit. Some stuff you pick up is useful beyond those problems that shouldn't even exist in the first place but lots of things you pick up over time are about fixing or at least somehow dealing or enduring stuff that shouldn't be like that in the first place.
Fine. Let's be honest, it's just reality that this is quite helpful.

But why are there, especially in the frontend, so many devs, that confuse this with progress or actual advancement in their craft. It's not. It's something that's probably useful but you get that for free once you manage to somehow get into the industry. Those skills accumulate over time, no matter what, as long as you manage to somehow constantly keep a job.
But improving in the craft you chose isn't about somehow being able to deal with things despite everything. That's fine but I feel like the huge costs of keeping things going despite some all the atrocities that arose form not even considering there could be anything to improve on as soon as your code runs. If you receive critic in a code review, the first thing coming back is some lame excuse or even a counter attack, when you just should say thank you and if you don't agree at all, maybe you need to invest more time to understand and if there's some critic that's actually not useful or base don wrong assumptions, still keep in mind it's coming from somebody that invested time to read your code gather some thoughts about it and write them down for you review. So be aware of the investment behind every review of your code.
Especially for the frontend getting something to run is a incredibly low bar and not at all where you can tell yourself you did code.
Some hard truth from frontend developer to frontend developer:
Everybody with two months of experience is able to build mostly anything expected on the job. No matter if junior or senior.
So why aren't you looking for ways to find where your code is isn't as good as it could be.

Whatever money you earn on top of your junior colleagues should make you feel obligated to understand that you need to invest time and the necessary humbleness and awareness of your own weaknesses or knowledge gaps.
Looking at code, that compiles, runs and even provides the complete functionality of the user story and still feeling the needs do be stuff you don't know how to do it at the moment.

I feel like we've gotten to a point, where there are so few skilled developer, that have worked at a place that told them certain things matter a lot Whatever makes a Senior a Senior is to a big part about the questions you ask yourself about the code you wrote if if's running without any problems at all.
It's quite easy to implement whatever functionality for everybody across all experience levels but one of your most important responsibilities. Wherever you are considered/payed above junior level, the work that makes you a senior is about learning where you have been wrong looking back at your code matters (like everything).

Sorry but I just didn't finde a way to write this down in a more positive and optimistic manner.

And while it might be easy to think I'm just enjoying to attack (former) colleaues thing that makes me sad the most is that this is not only about us, it's also about the countless juniors, that struggle to get a food in the door.
To me it's not about talent nor do I believe that people wouldn't be able to change.
Sometimes I'm incredibly disappointed in many frontend colleagues. It's not about your skill or anything. It's a matter of having the right attitude.
It's about Looking for things you need to work in (in your code). And investing time while always staying humble enough to learn and iterate on things. It's about looking at you
Ar code and looking for things you didn't solve properly.

Never forget, whenever there's a job listing that's fording those crazy amount of work experience in years, or somebody giving up after repeatedly getting rejected it might also be on the code you write and the attitude that 's keeping you looking for things that show how awesome you are instead of investing work into understanding where you lack certain skills, invest into getting to know about the things you currently don't know yet.
If you, like me, work in a European country and gathered some years of industry experience in your CV you will be payed a good amount of money compared to many hard working professions in other industries. And don't forget, you're also getting payed significantly more than the colleagues that just started at their first job.
No reason to feel guilty but maybe you should feel like forcing yourself to look for whatever aspect of your work is the weakest.

There's so many colleagues, especially in the frontend that just suck while they could be better just by gaining awareness that there code isn't perfect.

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?