One thing you must learn is how to break your project into smaller libraries, to avoid doing rounds to deal with "the same, but a bit different".
On a previous life, to understand how a system behaved, I added a ton of metrics: how fast things were going in, how fast things were going out, how many things were in the middle, how many the job processed... Not doing it so makes me feel... naked.
Let say you need more performance on your application. You may be tempted to look at your code and think "How can I keep this same logic and still remove a few cycles, so things seem to go faster?" Well, if you want performance, you need to change your logic.
A lot of projects assume that you'll put things with the same functionality in the same place, no matter what data they deal with. This makes things harder to break apart later.
When working with source control tools, keep one change per commit. Avoid bundling more than one change in a single commit just to "save time".
"This is my stupid application that I just want to learn something" is not even a good excuse to not use a version control system.
I heard a lot of people complaining that code editors are bad 'cause it's hard to attach a debugger. I'd claim that this vision is wrong.
A lot of languages/libraries/frameworks add a way to make things shorter, reducing the number of things you need to type.
But, later, that will bite you and you'll have to remove the shortcut and do the long things.
Two things in one: First of all, when using logging, use it to log events, not for user interfaces; second, log events in a machine readable way, not necessarily an human readable format.
Sure that IDE will help you with a ton of autocomplete stuff and let you easily build your project, but do you understand what's going on?