I’d say overall, don’t be too hard on yourself.
First all, there’s not really consensus on what is considered “maintainable“ (or even “good”) code out there. I can give you a definition that I like, but ask ten other people and you might get ten other answers.
My suggestions
- learn about refactoring. make sure you understand the difference between changing the structure of the code VS the behavior of the program, and develop the habit of only ever doing one at a time. Then, it’s just a loop between extending the program’s behavior (e.g. adding a new feature) and then improving code itself. Each step of this loop could be on the scale of minutes (or less!) or entire sessions. Experiment with it.
- “invest in the design of the system every day” ala Extreme Programming. Pay attention to when areas become annoying or frustrating to you. Make a quick note on your list, finish what you’re doing, and consider investing in making that less difficult. Even a little.
- learn about TDD even if you don’t use it often or ever. Test-Driven Development: By Example is still my favorite resource here. One of the best skills you’ll learn is how to zero in on the right size steps to take. some code you might have to write one tiny piece at a time, other code you might be able to write larger chunks in one shot.
The question is, why did you drop it? Why did you lose interest? Because the going got too rough? Or you got excited about a different idea instead? You’re dropping your Go projects as well, it might just be a question of attention span, focus, or discipline in general. You might need to do a little introspection here and be honest with yourself.
One thing you might try is making a commitment to yourself that a certain project is the only project that you will work on until a certain date. For example, a month from now. Mark it on your calendar. Start a document where any time you get an idea for a new project, you add it to the list and leave it there until the time has come where you can decide to start a new project or continue to invest in your current one for another chunk of time.
Another approach is the same project list, but you’re not allowed to start on any project until it’s been on your list at least a certain amount of time. For example, 50 days. If you’re still fired up about it, go for it.
Having teammates that are more experienced than you is a great way to learn things but can be a double edged sword. Working on your own has its own benefits, mainly that you can just make whatever changes you want. Change how something is designed. Not happy with it a week or two later? No problem, change it again.
Lastly, not every project needs to be for the long haul. If you’re just writing a project to play with an idea, that’s totally different than creating a product you want people to pay you for, which is different than an open source project that you expect others to contribute to and want to maintain over time, which is different than a script or tool you want to make to automate some personal pain point, which is different from …
Hope this helps!