Just graduated school/college/private programming class. You're a full fledged programmer now! All you need is experience. That aside you're ready to create the most optimized, fast and awesome code ever!

Classes about programming could be quite awesome - they teach you how to optimize code to run fast and to use less memory. But classes usually fail to emphasize on how the time and place of those optimizations is usually more important than the optimizations themselves. You don't need to optimize everything. Even though you want your code to be perfect and to run as fast as possible - it is not worth it.

The user doesn't really care if your code follows conventions or if it is optimized or anything - he just wants to play a game smoothly and without bugs. So our primal urge hints us to focus on those two things - "smoothly" and "without bugs". That's fundamentally wrong - we need to focus on the most important thing the user wants - a *Game*, not epic code which runs with 230 fps on your iPhone 2. So you should actually ignore your primal urges and actually focus on creating a game.

Development takes time. Optimizations take from that time and usually they don't have any marginal effects on the final product. Instead of wasting 2 weeks on fixing the 2 frames drop in FPS when that flashy button gets clicked once in the whole game - why not implement the merchants selling items or whatever feature the game is missing.

Programmers easily forget how precious their time is, and start wasting it on optimizations which aren't really needed. A lot of time is wasted on over-architecturing code, on making simple things complex, just for the sake of 2 milliseconds in the 5 second loading of the game. This slows the process and makes it a lot harder.

Imagine writing a messy k-tree just to make things faster, then making a couple of changes because the game required them, making the whole thing run, and then going back to the same piece of code couple of weeks or months later. You have to understand all of that and work with it. It is hard.

KISS! Do not overcomplicate stuff. Don't lose precious time on deciding whether you should spawn your enemies off a k-tree or a list. Pick the simplest option. You will appreciate that later - it will be easier to understand, easier to work with, easier to debug. Easier is good. And the awesome thing? Easy is fast to write. That's good too.

So after I've repeated the same thing a couple of times now, I'll get to the another point of this article - Prototyping. It is important. I didn't get it when I first started making games, but it is vital to the process. A good prototype could lead to a good game, a bad prototype could lead to redesign and getting to a good prototype or to throwing the whole thing away. Lack of prototype may expose major design flaws and major problems on a very late stage of the project.

The faster you get the planned idea to a raw prototype, the better. With this you can easily show what the game will be about to anyone, artists could get a better feel of it, programmers could see if there are actually optimizations needed, designers could see how the game plays. The game design will be evaluated and improved. All good reasons.

Getting prototypes done helps on entirely different ground - meeting goals and deadlines. Make a goal and a deadline for your prototype. Then finish it. You've got a milestone in your development for every prototype, a concrete set of goals accomplished. That's big.

Programmers tend to stuck on some piece of code, simply because it isn't rewarding to write internal systems with negligible effect on the actual game for couple of weeks. And programming is just an instance of a creative process - artist, composers and designers suffer from the same thing. It is daunting to feel stuck. But looking at the previous milestones will make the difference and boost the spirits and motivation of everyone.

So to sum things up : 

Rule #1 - Do not optimize.
Rule #2 - Do not overcomplicate.
Rule #3 - Prototype.