Honestly, I'm done trying to flip the script and approach it as a "well maybe they truly need smarter people to read the code".
Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and 'context matters'. At best they form a way to talk about some things, often buzzwordy.
If companies are filtering based on whether you can regurgitate SOLID, DRY, etc., it becomes a self-fulfilling prophecy. At least some fanatics will treat those things as the solution to every problem and create something illegible to the majority of the population. You don't solve that by pushing the burden on the majority to adapt, you solve that by being a smarter strategist and stop letting fanatics do as they please. It's exactly as you say, write code with the commoner in mind, not the genius.
Writing code is part literature. Don't blame others if your writing is prose, obtuse and completely misses its target audience. Most people aren't born with great writing skills, start cultivating those instead of trying instant 'good code concept' solutions.
In my mind a fitting analogy to building software is like designing and building a machine or a physical tool in mechanical engineering: like a CNC machine, a laser cutter with an optical system for processing etc.
There are no rules in designing a machine except for: These are the requirements. First drafts will be analyzed and iterated on by simulation and prototyping (e.g. for mechanical resonances, thermal deformation) - an inexperienced engineering team will have to do a lot of testing and prototyping and failing, while a team who has some experience in building a machine in a specific domain will know what to look out for and what can be compromised on.
There are best practices but I feel they are always domain-specific (e.g. everyone wants to put their precise machine on a big block of mass to isolate it from the environment on a machine in a shop floor, while the best-practice for a similar application working on a plane is totally different).
Oh I definitely agree with writing code being a bit similar to writing prose. Along with that comes "naming is hard". It can take several iterations of renaming and restructuring things, taking a step back and thinking about how the program reads and how close that is to being easy to understand, without looking too much at the actual implementation and so on. And it does take practice, no question.
I would add though, that the opposite of DRY and SOLID are feared for good reason. Just imagine, if you had duplication everywhere, because the previous developer did not understand or did not take time to introduce fitting, suitable abstractions or indirections. So these principles are definitely worth something. I guess learning to apply them in the right moments is also something, that needs practice.
Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and 'context matters'. At best they form a way to talk about some things, often buzzwordy.
If companies are filtering based on whether you can regurgitate SOLID, DRY, etc., it becomes a self-fulfilling prophecy. At least some fanatics will treat those things as the solution to every problem and create something illegible to the majority of the population. You don't solve that by pushing the burden on the majority to adapt, you solve that by being a smarter strategist and stop letting fanatics do as they please. It's exactly as you say, write code with the commoner in mind, not the genius.
Writing code is part literature. Don't blame others if your writing is prose, obtuse and completely misses its target audience. Most people aren't born with great writing skills, start cultivating those instead of trying instant 'good code concept' solutions.