I think though that quality code lends itself to being able to change easily when requirements are incomplete or misunderstood. So a good developer can build something, knowing that the requirements are going to change (that one manager on every project who insists on one specification every developer advises against that gets locked in and then 6 months later, nope, false alarm). You can build your code as if that specification is always going to be there, or you can build it so that when everyone sees reason it's easy to pivot. The trick is knowing how to do that without much, if any, extra effort. And that's what experience is for.