I think it depends a lot on what you are doing. For game dev, there is really nothing else but C++. Also most bad code can be good code if someone is intelligent about it, and use good names and comments. Also if they know how to search through the code and trace things. For massive group projects I can kind of see your point. Being ina. Rush makes it very difficult to write good code, something that is laid out well, is interfacable and modular which makes it easier to understand. I personally try to write all my code to where it's mostly an API to anyone else wanting to use it. Something where they don't necessarily have to dig through tons of esoteric and confusing code, but I like to have everything wrapped in nice little function calls, that handle all the edge cases within and have a little description.

I understand rushing makes this hard but that's more so a failure of the team leadership prioritizing the wrong things. If you are going to write code that's going to be used for 20 years, it's actually a much better use of your time to just write really clean and easy to understand and adapt code up front, and save yourself so much time in the future. The only time other people should really have to dig beyond the API layer of your code is when they need to debug or modify the functionality of your code. So to me it seems like you want to write the most abstract and stable and simple interfaces code when working on long term projects with multiple people, even if it takes 4x as long, and for little personal projects and stuff that will only be compiled once, you may just want to through 100k lines of code in a file and compile it and then forget about it.

Other things I do is wrap things and simplify things myself. I create my own libraries which I know that you as a professional programmer hate to hear, but I do believe in the power of simplicity and abstract compression if you really want readable code. Libraries have to be maintained if they are to be used in production, but inlining some of your own code into every project you do is very useful and doesn't rely on external libraries and can greatly simplify the code you need to write. I wrapped many C std lib stuff in my own code for this reason. It cuts my code in half often times, makes the code very readable and descriptive, and I can just add it to all my projects as a header instead of link libraries and stuff. Idk. Maybe sometimes you just have to weigh the upfront development time and cost with later reliability and simplicity, which I'm sure you do, but your managers might be wise to consider that as well. Having bad code isn't just bad for developers, it makes people using your product dislike the products. There are many reasons to just take the time to write better code and use better techniques at the cost of time, and to truly be successful you have to look beyond the next quarterly report and stock price and do everything in view of the long term. Efficiencies are often small by themselves and not worth it, but overtime efficiencies and good habits snowball into massive permanent buffs.

Idk I feel for you corporate software devs. I like coding but I can't imagine coding stuff all day that I'm not interested in and dealing with corporate code and libraries all day. I never really got into tech as a job for various reasons but one of the big ones is that I can't handle the stress of debugging other people's stuff for days on end. I can't deal with crunch culture. I get worse jobs in many ways but at least I'm not stressed all the time. Sometimes heavy mental loads are just too much and I have tol stop programming for the day or the rest of the day. I don't like the idea of being forced to think at a job, but I do jobs that many other people wouldn't like and it doesn't bother me.