When do you focus on making your code maintainable?

My team and I have been discussing an interesting question: when in your process do you focus on making code maintainable?

For context, this started with a discussion about how developers (particularly junior developers) can get better at writing maintainable code.

My company, Curricular, creates challenges for up-and-coming developers to practice their skills, including code reviews. We see lots of portfolio projects and capstone projects from bootcamps. Almost every project that we review has issues that impact maintainability, like vague variable/class/method names, or violations of principles like DRY or separation of concerns.

Obviously, when starting out, maintenance isn't as high a priority as just getting something to work, or meeting a deadline for school/bootcamp. But part of making the leap to professional developer is shipping code that you and/or others can work with in the future.

We've been dissecting our own processes to share when code starts to become more maintainable. For some, it's only through refactoring - at first it's really about getting things to work and then rewriting to optimize / subtract. For others, it starts when defining the problem - they're thinking about extensibility and future use cases right away.

My feeling is that a lot of this comes with practice. The more practice you get, and the more feedback you get from code reviews, the better your code becomes earlier in the process. But the same is true with refactoring - the more you do it, the better you get at it.

What techniques do you use to keep your code maintainable? And how much of your code's maintainability comes through refactoring vs. through your ingrained practices?