This is sort of something that I think needs to be better parsed out, as a lot of engineers hold this perspective and I don’t find it to be precise enough.
In college, I got a baseline familiarity with the mechanics of coding, ie “what are classes, functions, variables.” But eventually, once I graduated college and entered the workforce, a lot of my pedagogy for “writing good code” as it were came from reading about patterns of good code. SOLID, functional-style and favoring immutability. So the impetus for good code isn’t really time in the saddle as much as it is time in the forums/blogs/oreilly-books.
Then my focus shifted more towards understanding networking patterns and protocols and paradigms. Also book-learning driven. I’ll concede that at a micro level, finagling how to make the system stable did require time in the saddle.
But these days when I’m reading a PR, I’m doing static analysis which is primarily not about what has come out of my fingers but what has gone into my brain. I’m thinking about vulnerabilities I’ve read about, corner cases I can imagine.
I’d say once you’ve mastered the mechanics of whatever language you’re programming in, you could become equivalently capable by largely reading and thinking.