As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.
Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.
I even started to finish and deploy my personal projects. It's that effective for me.
Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.
Good on you for having success with your personal projects!
But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse.
This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects!