Lots of good points in the previous posts. I'll second the point of designing ahead of the code. Don't implement any features you don't really need, and know what you do need before you start implementing stuff A 100% detailed design upfront would be nice, but not usually possible. But you at least need an overall game design, and a decent amount of full detailed stuff plotted out before you get coding.
For example, you might have a few levels planned out for a side scroller, with various platform and enemy types in them. Once you code all that up, you have all those components to mix and match in new, not-pre-planned levels, and maybe think of ideas for some more things to add. But you need those first levels designed before you start coding, or you risk falling into the trap of "engine" coding, which often results in lots of those unnecessary features
Also, use a coding style appropriate to the complexity of the game. Full C++/OO/RAII/smart pointer style is great for most things, but maybe a little overboard for Pac Man. If your game is similar to something done on SNES or earlier, chances are it was written in assembly with little if any heap allocation (usually using statically allocated pools for things that are dynamic in nature, but have a maximum number that can be on screen at a given time), and probably wouldn't run into many difficulties coding it in C.
And when commenting code, don't go overboard. Usually it will do to give a quick plain-English overview of what a function is trying to accomplish, or a block of code in longer functions. Only comment line by line if you're doing something particularly confusing, such as highly optimized code.
Quality content creation is time consuming. Background graphics, animations, sound effects, music, level design. But don't involve other people in your project until you have the design worked out well enough that a) they'll have something moving around on screen soon, and b) you're relatively confident that the project is not going to fizzle out due to excessive complexity or simply not being as much fun to play as you thought it would.
Be aware that 50% of the production time is finishing the last 10% of the game. If it doesn't look "almost done", you've got a long way to go But sometimes the transition from looking like a bunch of separate components into being a cohesive whole game can happen pretty much overnight.