One way to make more progress is to keep a to-do list and/or a bug tracker. It's much easier to make progress if you don't find yourself distracted every time you see an imperfection in the game - you can just log it in the tracker and get back to the main task at hand.

when I finally landed a professional job programming a few years ago, I found it pretty easy to put the perfectionism aside

Secondly, at least for me, at work, problems I solve are not my problems, and I won't use the solution either. That gives me much more distance for judging progress and use of time/resources.

I agree with most of the responses above, including those that tried to help you with what you asked, and those that told you don't worry about it too much.

But I want to add this perspective:

* If you enjoy "finding the best way" and this is a hobby ... don't ignore the fact that this may be the part of it that keeps you going. I actually spend over 50% of my effort on "improving" stuff that is already "good enough" .. because that's what I like and this isn't a job (like the other poster, at work I ship code where "perfection" is not a goal, just "high quality") - but for my hobby I don't achieve perfection, but I pursue it.

* If your tendency to spend most of your time circling and circling in pursuit of your perfection is stopping the other half of your enjoyment (ie making actual working / interesting product). Then either use the techniques to keep on track mentioned by many posters (like daily lists, etc) or separate yourself into 2 explicit modes: work mode, polish mode. This version is where you tell do things like have a list ... and you make yourself spend "x" amount of time moving forward on the list (or something like "i'm gonna knock out item 1 and 4 first") ... then you let yourself work on unnecessary improvements for X amount of time ... then "back to work"

Its a technique I use on my architecture and designs at work. Cause while at work I can easily get code "good enough" designs themselves are harder to judge ... so I force myself to first get a design advanced forward to a certain point, then I let myself explore alternatives and improvements for a certain amount to time, before forcing myself to pick and move forward again.

Always keep in mind that throw-away code just has as much room in professional programming as well documented, well written code meant for re-use and longterm use.

If you create something that is meant to last the next 10 years, where many other people will have to touch the code besides you, and/or part of it will be re-used to kickstart your next project, then the time taken to refactor the ugly parts, and document everything as well as you can is probably well spent from a longterm perspective (WHEN you should spend that time is still up to your own judgement. You probably shouldn't try to write the perfect code in one session, else you will spend the time you should spend on getting a first draft of the code working on making a tenth of that perfect).

EDIT: And that is also just a means to an end, to make sure others have an easy time working with your code, the re-used code is as high quality as it can be to start from a solid base, and in general, because the code is now WORTH the additional time you waste on it.

If you create some rough prototype, write throw-away code. Tell YOURSELF that it is throw-away code. This is meant as a means to an end, which is to make the prototype work. Which in itself is a means to an end, which is to prove the feasability of a game design, or a technical solution, nothing more or less.

Both the prototype and the code that make it tick are not meant to be copy and pasted into a production ready game, if anything, these should ONLY be used as a starting point. Best just copy the idea and rewrite from scratch.

The upside to that is: you can hack away as quick and dirty as you want when creating the prototype code. IF you ever create a full game from that prototype, you are going to rewrite from scratch anyway. And in the likely case the prototype stays just a prototype... well, you didn't waste time on beautiful code.

There is everything in between. Always keep in mind what the goal of the code is, who will need to touch it besides you, and if you might want to re-use it.

ONLY refactor and beautify code that you KNOW you will re-use, others will touch besides you (then documentation and comments are more important than the most elegant solution), that you might keep for a long time, or that you want to show when applying for a job (now you want both documentation and comments, and the most elegant solution).

In all other cases, nobody is going to blame you for going for a suboptimal solution, or for not investing the time into code that is just not worth it.

As long as the code works and performs as well as it should, of course. But I guess that isn't the reason why you feel this urge to make your code look prettier :)

My approach is the following:

- Practice making testable code

- Limit the time to decide on an architecture for a problem. Timeboxed, and try hard to not come back (unless you have figured out that the previous architecture wouldn't solve it)

- Program using KISS, using only what I'm sure that I'll need.

- Code is now simple and easy to change.

Most of perfectionism comes from "I believe that I'll need that later", "This might become too slow", "I can make this more flexible for uses I can't think of right now", and, lastly, "I don't want to need to come back to this later". All of these disappear when you try to solve only what you need right now.

Examples:

- No need to create a factory if in the predictable future the object is too simple to construct

- No need to create complex error handling systems, flags, exceptions and the likes if the code only care about success/failure (you can append the details to an error text file or console)

- No need to create complex messaging systems when lambdas, delegates, events, coroutines (or whatever your language of choice has) can solve the problem for you.

In the end, code changes when the design changes. "Perfect" or "KISS" code with both likely be scramble to the ground and rebuilt quite often.

As a beginner with more or less the same issues, I can give you the same advice I received about that, it's simple, have only a few words and have been proven (at least for me) to be effective:

Do games Jam!

The Ludum Dare, #1GAM, etc... Just any "competition" that can catch your interest, why? Here are few reasons:

• First you have a real time constraint, so you are forced to make choice about when to stop tweaking your code if you want to finish you entry in time.
• You will have an opportunity to see others using the same tools as you and how they work with it.
• Ideally, each finished Jam will give you a completed and working game that will help you to feel more accomplished for having released one/some/plenty of games.
• Between the Jam, you will have time to still work, polish and improve your tools, skills and eventually engine.
• Each of those Jam done will serve as a step that you may to use to monitor your progression.

To help you you just have to add one rule to the ones of the differents Jam, one that is sometime listed in them, one finished, you can give you a few day, even a week to work on your project again, but just for fixing gameplay issues. After that, you have to consider it done, never working on it again, and pass to another of your project.

I don't know why I have not seen this option proposed here before, maybe it's not so interesting and I don't actually see why? But when I think about it, that seem like a good choice, that I myself need to follow more often to help me advance.

As a beginner with more or less the same issues, I can give you the same advice I received about that, it's simple, have only a few words and have been proven (at least for me) to be effective:

Do games Jam!

The Ludum Dare, #1GAM, etc... Just any "competition" that can catch your interest, why? Here are few reasons:

• First you have a real time constraint, so you are forced to make choice about when to stop tweaking your code if you want to finish you entry in time.
• You will have an opportunity to see others using the same tools as you and how they work with it.
• Ideally, each finished Jam will give you a completed and working game that will help you to feel more accomplished for having released one/some/plenty of games.
• Between the Jam, you will have time to still work, polish and improve your tools, skills and eventually engine.
• Each of those Jam done will serve as a step that you may to use to monitor your progression.

To help you you just have to add one rule to the ones of the differents Jam, one that is sometime listed in them, one finished, you can give you a few day, even a week to work on your project again, but just for fixing gameplay issues. After that, you have to consider it done, never working on it again, and pass to another of your project.

I don't know why I have not seen this option proposed here before, maybe it's not so interesting and I don't actually see why? But when I think about it, that seem like a good choice, that I myself need to follow more often to help me advance.

Dude, terribly sorry, didn't meant to vote you down... mouse was in the wrong position, and the touchpad registered a tap when there was none. Doh!

If anyone is reading this, and didn't want to upvote _Kane anyway give him a +1? The forum does not let me go back on my -1 sadly.

Again, sorry about it.

Ahem, back on topic if I am posting anyway... read up on KISS as mentioned by Kirlim. That is basically the development "paradigm" you should follow.