Operating system security. The consensus seems to be that Users, Hackers, and Microsoft are responsible for the current crisis in "cyber security". Any mention of the need for a better underlying security model, such as capabilities, is dismissed as quickly as possible.
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.
Simplicity. There are absurd numbers of overengineered BS tech just because someone needed to put it on a CV or were just measuring dicks. There's also tons of extremely useful software that has zero design thinking in it, therefore even though the features are great, the usability isn't..
The context of what they are developing. I've been in teams where I seemed to have genuinely surprised people when suggesting to talk to the actual users and asking for some feedback on what for and how they are using the tools we developed (vs what the product owner thinks), or to have a chat with developers from "next door" teams.
Learning how things work, not just how to use them. You don't have to know in ins and outs of a compiler, but you should probably understand the structure of how Django works so you know what's going wrong when you're getting an error instead of blindly copy and pasting to google without even reading the error.
The craft of coding and pride in their work. Over the last 12 years I have worked with more people than not that hand off code that solves the problem, but is sloppy and not very readable. I've wondered if this is a byproduct of rushing to meet sprint deadlines.
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.
Literate programming. This is an idea that keeps being reinvented.
The names I have seen are:
Readme driven development. Documentation driven development. Executable documentation. And many more..
Leaning harder to use better programming languages and tools. So many devs I know would much rather be using something else, but just go along with using whatever is popular.
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.
Working in legacy code
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.
about their own mental and physical health. Essentially it's the only thing that matters in the long run.
Working on environmental issues. That includes myself. It's tough though, the companies I talked last job cycle don't seem to pay anywhere near well as other companies and didn't seem like great companies to work for (benefits, culture, beaurocracy) when interviewing with them.
What their code could actually be used for.
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.
Being good at making clear, useful and simple abstractions.
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.
Well maintained documentation, specs, the state of the project.
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.
The human element, or design and UX/UI & ergonomics. Don't code for 'the developer', code for your users.
As a user, security and user freedom of course.
Dependency hell
Ops
Each other
freedoms
Code dependencies, and how dangerous they can be.
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.