Complicated things are the product of a system of simple things. To do complex things well, you need to be able to do the simple things without consciously thinking about them. Expertise is what happens when a large mass of related things become easy so you don't think about them, so you can think about complex things made from the easy things.
For software, it's often about decomposing problems vs infrastructure to work on them. There's a great xkcd about that. Someone asks for an app that can take photos and tell if they're in a national park (easy)... but also tell if the photo is of a bird (incredibly hard). Lack of expertise is why people don't understand this. They don't recognize that they are two entirely separate problems, jumbled together as if they were one problem.
An area of expertise for me is playing guitar. Now, melodies are for the most part made of scales and arpeggios. So playing scales/arpeggios efficiently can be isolated from "music". And they're tied intensely to physical technique. So for instance, playing two notes per string is physically much different from playing three notes per string. By isolating scales and arpeggios into small chunks and practicing them independently, we can then easily integrate those chunks to form streams of melody, without having to do conscious thinking, because when playing music, conscious thinking is the enemy. It destroys rhythmic flow. But with a collection of instinct-level arpeggios and scales in my hands, I can just play, with my mind focused on emotions, ideas, and musical shapes, rather than which finger needs to land on which string to hit which note.
Programming is a lot like that. Once you've learned effective data structures, control flow, conditional behavior, etc, you shouldn't have to think about it much while you're coding, so you can focus on the problem, not the act of writing code. Or as I like to say, "That's not programming, that's just typing". And then you learn things like unit testing and TDD so you can free yourself even more from the line-level anxieties of the code.
For software, it's often about decomposing problems vs infrastructure to work on them. There's a great xkcd about that. Someone asks for an app that can take photos and tell if they're in a national park (easy)... but also tell if the photo is of a bird (incredibly hard). Lack of expertise is why people don't understand this. They don't recognize that they are two entirely separate problems, jumbled together as if they were one problem.
An area of expertise for me is playing guitar. Now, melodies are for the most part made of scales and arpeggios. So playing scales/arpeggios efficiently can be isolated from "music". And they're tied intensely to physical technique. So for instance, playing two notes per string is physically much different from playing three notes per string. By isolating scales and arpeggios into small chunks and practicing them independently, we can then easily integrate those chunks to form streams of melody, without having to do conscious thinking, because when playing music, conscious thinking is the enemy. It destroys rhythmic flow. But with a collection of instinct-level arpeggios and scales in my hands, I can just play, with my mind focused on emotions, ideas, and musical shapes, rather than which finger needs to land on which string to hit which note.
Programming is a lot like that. Once you've learned effective data structures, control flow, conditional behavior, etc, you shouldn't have to think about it much while you're coding, so you can focus on the problem, not the act of writing code. Or as I like to say, "That's not programming, that's just typing". And then you learn things like unit testing and TDD so you can free yourself even more from the line-level anxieties of the code.