The art of writing code that doesn't build on top of a jenga tower of shit has been lost. It turns every software engineer into a code monkey that, instead of crafting good code, is simply trying to keep the jenga tower from collapsing. Yes, it's faster when getting an MVP up and running, but the quality of apps (and their speed) has gone down drastically over the last 10 years.
...to the point where I no longer enjoy software development, and am actively trying to quit the field.
In the past, our hardware was too dumb, and we didn't have persistent networking, so we could get away with things that are obviously stupid in today's context.
No current OS can be made secure, and remain usable. It doesn't have to be this way. We can have safe and secure general purpose computing. If we don't push in that direction, the government is going to regulate things down to the bit level, and it still won't be safe.
Learning to do proper debugging. Again, 3 orgs in 12 years, and it seems like the debugging skills of those coming into the industry are getting worse. Personal observation, so take it for what it is, but it seems like even developers 2 or 3 years into the industry still don't know how to use debugging tools or have a "system" for troubleshooting and investigating an issue.
The names I have seen are:
Readme driven development. Documentation driven development. Executable documentation. And many more..
This takes effort in both convincing and in putting in the extra work to make it work smoothly because it isn't a beaten path, but if the choice isn't superficial it will more than pay for itself.
Even when you don't dictate the specific language used, you can still strongly influence the style of program composition so that it has less mutable state or distantly-coupled behaviour and the like so that it works like a better language than if you didn't.
Legacy code (ie any code users actually use ;) ) is the life and blood of actual value delivery. Warts and all... your life in legacy code is truly navigating the dance between paying off technical debt and delivering new features in a codebase currently serving a userbase. Doing that dance is hard, but fun and rewarding.
I was so surprised when a really talented dev at my company went to Facebook because of their solid perks. I mean, I get it, but at the same time this person seemingly gave no thought to how evil their new company was.
Although not the only way being good at this, mathematical thinking helps. What information can I discard, what's important, what isn't important?
The problem is you can get them so badly wrong.
It’s tough to have to dig through a legacy project to figure out its state, what it does versus what the docs say it should do.