The first thing that I do on all of my projects is to always look for ways to avoid reinventing the wheel. This is not as easy as you might think! For every project you need to figure out what the requirements for the project are and then from those requirements you have to figure out which set of technologies are the "best" from your choices. Sometimes those choices are easy to make and sometimes they are very difficult!
One of the things we must do as programmers though is to constantly evaluate our requirements as we develop the project and look at what requirements are good requirements and which requirements are bad requirements! This is an important step because it is easy to generate a rather long list of artificial requirements that could cause you to ignore or throw out perfectly valid options.... At the same time however sometimes it is not practical to constantly change technologies and so you have to also learn when to just stick to what you have and suffer through bad choices.
The only real way to figure out if your requirements are valid is through experience... however there are still decisions you can make up front that might save you a lot of headache...
Here is a quick list:
A) Avoid making an engine for the sake of making an engine. The desire to make an engine is great but if you do not make a game in that engine there is no way you can figure out what features are needed to facilitate making a game... Scientific Ninja has a great article on this subject. Many times I read posts on the forums where a new user is out to make an engine from scratch and this choice can put a lot of artificial requirements on a project (and cost a lot of time to put).
B) Don't ignore free tools. If you can find a free and open source tool to help create content for your game then it is usually always a good investment of time to use that existing tool than devoting developing time to create your own tools...
C) Use C++ in the correct context! In my opinion you should use C++ for two reasons: You like the language and are comfortable with it,or you can't do your project in anything else. I realize this point might be controversial but I see a lot of new programmers deciding to use C++ because "everyone else" uses C++ and therefore they feel they should use C++ also... This can cause people to ignore other languages because they feel that C++ is the "only" choice for making a game. There are many other languages that might provide substantial increases in development time over C++ so it is important to consider a wide variety of languages and to pick the right language for the job. Sometimes the choice of language doesn't matter but I would personally recommend considering your options because a lot of times to really get the benefits of C++ you need to work hard on your code.....
D) DO NOT hard code values in your code. Magic numbers (And even strings sometimes) seem like a great idea at first... but if you ever want to change your code later it can become a gigantic pain to modify the code... Instead of magic numbers you should use constants or better yet try to load the data from an external file... Either flat file or XML will work (I personally prefer XML because it is easier to parse).
E) Take breaks... You really need to get up every so often and rest your eyes and your hands... Long programming sessions might seem productive and maybe they are to you, however long periods of sitting/staring at a computer monitor/typing can be detrimental to your health and if you have to stop development on a project for surgery you will find that the time savings are probably not worth ignoring breaks.
F) If stuck on a hard problem it is often better to come back to it later. Sometimes there have been bugs in my programs that have driven me crazy but I find that if I stop and do something else and come back to the code in a few hours/days then I can normally figure out the problems with a fresh perspective.
G) Do not program while exhausted. Sometimes you have no choice but to program while sleepy but most of the time this is an exercise in futility. You will usually not have the mental focus necessary to write good code if you can barely keep your eyes open.
H) Work on your project a little each day rather than trying to do everything in "spurts". I have to admit I used to do my best work in long days every 4th day and the other three days I didn't do much of anything! While this seems like a good idea... it can be damaging if you get stuck on a problem that requires thought... Breaking the work up allows you more time to process tasks. The best way to break your work up is to set small goals every day for yourself and set out to accomplish those goals by the end of the day. If you don't make your goal for the day then the following day scale back the task until you CAN complete something. Once you do then try to do a little bit more than you think you can do every day... The main thing is to always figure out your next step on your project and then to work on implementing that step... Essentially this will help you figure out how much time a task will take to program and it will help you with breaking down problems into small chunks.
Some of this advice might seem obvious and I am sure there are many other good pieces of advice that I have failed to mention... I hope however that you will find at least one decent tip in this journal entry that will inspire you to do more research on that topic. Please browse the wonderful article section here on the GameDev site if you do not already do so and read the advice there! I think the best piece of advice that I can give however is the following... and it is as true today as the day that it was written :
DON'T PANIC!
BTW, there's one aspect of your journal that's a bit annoying: the text goes waaaay past the width of the screen, so every line I have to scroll left and right. The width of my screen is 1440 friggin pixels!! It's not a crummy netbook or anything. Lately, I either copy the text to Word to read it, or don't read the entry at all... I don't want to be rude, but if you could please try to work that out, I'd really appreciate it :)