Maintain it over time and changes. Writing "working" code isn't that hard, but we've all had the pains of bad code: * Hard to extend/modify * Confusing to un

Maintain it over time and changes. Writing "working" code isn't that hard, but we've all had the pains of bad code: * Hard to extend/modify * Confusing to understand * Full of exceptions and not-quite-repetitions That last point is what accumulates due to the first two. The best way to learn how not to do the first two is to actually maintain your own code over changes. That teaches you how to make code that you can return to with less confusion and how to code for changes. ( A lot of code patterns are extensible, but grow cumbersome if break a fundamental assumption ) Ultimately, once you learn to avoid universally "bad" practices, you are left with a lot of conditionally good/bad ones. The same practice that makes a solid, extensible structure for one use case is what gives you a monolithic inflexible mess in another EVEN WITH THE SAME CODE QUALITY. So I'd say focus on that: too often we feel like it if works and is "pretty" it's good, but that's not always the case. Some seeds bear fruit, others eventually give you weeds.