And there's an adage updated with modern understanding "Perfect practice makes perfect" . It's not just repetitions but ensuring you train the patterns you wish to do automatically next time.

Excellent code is slow to write, the first 10 times, but eventually it's just as fast as junky code.

You should keep in mind that code quality is mostly subjective.

You can create a PR that coworker 1 loves because it hides the complexity and then have coworker 2 come in and say that it's complete garbage, because while the complexity is hidden, it still has to be understood in this context, only increasing the difficulty of working with the project

I.e using a state-machine vs a switch/case to determine a status attribute.

Both viewpoints are valid. Some code is objectively terrible, but most discussions on code quality are massively overblown

There are also those who view obscure and quasi-obfuscated ways of solving a problem as "elegant" as opposed to more straightforward and easy-to-read ones. Usually found near the ones ranting about superfluous code comments.

Or making/sharing LinkedIn posts showing the uber-obscure or complicated "Senior Developer Solution" next to the more straightforward and easy-to-read "Junior Developer Solution."

See the recent threads about Heaviside and Category Theory for interesting perspectives on practice informing theory (Heaviside) and theory informing practice (Category Theory naturally).