So I find "perfectionism" lately hindering me in my game dev endeavors. Sometimes, I often spend too much time reworking a working solution if feel it is inadequate or if I'm aware of a better way to do it. I get carried away trying to learn the "best" way to do something instead of rolling with the punches and learning as I go along (which is probably a better approach). I also get carried away with language specific detail (is this implemented in the most "pythonic" way, for example). Basically, it boils down to a fear of doing things the "wrong" way. Is there any advice you would give to get over this mindset when it comes to developing a game? I only ask because I find my current approach a hinderance to me actually finishing a project. Thanks!

Stop periodically and ask yourself if you've gotten any closer to something you can ship/release.

I don't mean that the code itself is pretty and awesome and well-documented and hardened for peer review. I mean does your stuff work.

If someone could sit down and play your game, you're mostly done. If you're not getting closer to that goal, reevaluate your moment-to-moment choices.

Ultimately it's just a matter of discipline. You alone can develop the habit of focusing on getting things done instead of getting things perfect.

Give yourself permission to be you. Get over it. There was probably a time when I was where you are at. But there is no "right" way to code. I spent a lot of years trying to learn the "right" way to code games and such. It doesn't exist. There is only this way or that way. Sometimes there's a more efficient way (which should be appreciated). But at the end of the day the people who play your game couldn't care less how you coded it. All they care about is whether it is fun or not including whether it crashes or otherwise acts buggy (low frame rate for example). How you code it is only valuable when it serves those goals or makes it easy to debug (or for other people to read if other people are working on your project). Sounds like you already know your answer. But at the end of the day, you have to be you and if that's the way you code, then that's the way you code. Being concerned about finding "the best way" just means you're a good programmer, but you already know you need to let that go sometimes in order to get things done. So listen to yourself.

Set yourself realistic goals for each day you're working on the project. Write a little todo list. Whenever you finish a point on the list: strike it out. This an important aspect because it boosts the feeling that you actually achieved something (therefore I recommend to do the daily todo list on a paper or whiteboard).

In the beginning you'll probably notice that you tend to put too much stuff on the list. Maybe you'll not even finish a single point in a satisfying way if you over engineer or rework too much. Don't worry, that's part of the process. You'll become better at this because you'll feel good when you strike out something and you'll feel bad if you don't manage to do all the stuff on your list.

Of course it's important that you actually put stuff on your list which helps you to progress.

Stuff like "refactor x", "rework y", "improve z" should only appear on your list if it's absolutely crucial (e.g. if it's a base system and you need to build a lot of stuff on top of it next). In most cases such improvements are not even required. They can be done later when the actual game is "done"/playable as an optimization.

Always keep in mind: Perfect, highly optimized and cleanly engineered code is more or less useless if you never finish the game which uses it.

Set yourself realistic goals for each day you're working on the project. Write a little todo list. Whenever you finish a point on the list: strike it out. This an important aspect because it boosts the feeling that you actually achieved something (therefore I recommend to do the daily todo list on a paper or whiteboard).

This is great advise. To keep yourself from going back to code chunks to perfect, great a list of acheivable goals that your code must do. This will get you to a working state as well as (magically) give you test cases. What I recommend is something similar to "agile user stories". They essential state a feature that your product must have, then there is a list of what must be done in order to mark that feature achieved. This will help you not only get away from perfectionism, but also write code that meets what you need and nothing more.

Its odd but bugs in our own code annoy us much more than i.e a AAA game we play. For example, knowing my application has some memory corruption or leak somewhere would really irritate me. However so long as I could run i.e Morrowind for at least a couple of hours at a time, I didnt really care. I even saw the crash to desktop bugs as "charming" haha.

Self critique can certainly help you improve but know that other people rarely care unless they literally cannot play your game.

Its odd but bugs in our own code annoy us much more

Not at all, we strive for high quality results, and we know our code down to the last bit, including all the little corner cases that might arise if you start thinking about it.

This is very much why I can't be bothered to play games where I know the source code in detail, as there is nothing to explore anymore.

My approach to avoid perfectionism is to consider all code temporary. It's not perfect, but it does the job sufficiently currently, so it will do for now. There is other code that needs me more than this code, so let's do that first.

Yep. Ive also come increasingly aware of this problem I have, as it leaves me feeling I've not achieved much at the end of the day. Then feeling nothing's gonna get finished then so on and so on.

One nice way is to design a interface/API for some underlaying library or tools in such a way that you can optimize the hell out of it... later.

Just make the interface really nice. The backend code can be the most horrible piece of shit as long as at works reasonable enough for now.

I know the feeling of dissatisfaction upon the codes, the feeling of "is this right? would it be a problem later?".
I usually remember that it's not about the code I'm doing, but the result. So I'll focus on the result. When things get slower or tangled, that's when I try to solve it.
If it's about architecture, it has to be designed/thought up first and not during coding (whether it's the whole program or features), until I hit a real problem because of it.

When I'm done, and the code that I worried about is actually not a problem, I'll confidently write it again in later time without hesitation.
This is where colleagues can really help. For example in a project, you and I may face different code problem at the same time, but may have each other's problem in the future.
We can correct this together without trying to solve it ourselves so we don't wander around asking ourselves whether this is okay or not.
It could be just a simple confident booster to keep moving on sometimes.