It is incredibly difficult to foresee what changes you’ll have to make to your codebase as the project grows. Complexity of adding new features scales poorly, but the difficulty of simplifying or god forbid removing existing functionalities poses a problem that is predominantly orders of magnitude larger.
The best way to prepare your system for the upheavals that are yet to come therefore is to focus on making code easily deletable. The code that you shed is the code you no longer maintain.
I always started out by making things all neat and tidy. That can be anything from taking care of properly naming variables, de-nesting for-loops, splitting up functions into smaller chunks, reorganizing file structure etc. However, the more you strive for aesthetics the closer you get to understanding concepts such as modularisation, encapsulation, single responsibility principle and many others. These become something to live by, because when done right they help you keep code simple and organized and that is key to project’s longevity.
Naturally, the higher level of abstraction you can act on, the bigger are the benefits for the system as a whole. It is when you can make positive change on a large scale the adaptability of your system truly shines.
Looking back now at the past decade of my career in software development it's always been the same thing that kept me going. Making code look nice, extensible, robust, performant and finding ways to build my understanding of programming is the thing I care about the most.
For the longest time code quality has been my drive. Eventhough it helped me produce good code, it also came with a significant cost. Spending valuable time on neverending refactors and meticulously planning out changes resulted in many features being delayed, postponed and personal projects abandoned. It took me years to beat this habit and if I am being completely honest with myself I sometimes still struggle with it. I can't help it. It's the thing that brings me joy in programming. I feel I'm constantly juggling between producing good quality results versus delivering fast and I still have ways to go with the latter.
I would like to be okay with writing hacky-looking piece of garbage that "just works". Or even something that falls into the spectrum between the 2 extremes. I know of a lot of engineers that just produce results, because they don't care how they get there and I envy them. I would like understand what gives them the drive to overachieve and meet all these tight dealines. It sure as shit ain't code quality.
I have yet to make peace with it, but I have my own methods of dealing with it. a) I got better at not caring about bad code and b) I got better at producing quality code faster. At some point I had a slight shift in perspective when I found art and mastery in other aspects of development; such as client satisfaction, interpersonal skills, mentoring, documentation etc. Having new interests to focus on have made those technical compromises a whole lot easier to handle, which brings me to my final point.
Life is short and we have little control over it. We all have our vices and it is up to decide whether we want to live with them or work through them. It takes effort. You're always better off failing than never trying at all.