1. Get a visual prototype going as early as possible - even if its screen mockups. Your interpretation of what the client wants and what they tell you they want are often completely different, and many times they don't really know at all. Once they can see something, then requirements get a lot better.
2. Once you have a better idea on what you will be building, work out in your head how you will build it. Think about all the parts and do the bits that you haven't done before, or don't know how to do and build them FIRST. This will avoid showstoppers down the road - you may not be experienced enough to know if it's something you can't / shouldn't do, or if extra help / libraries are needed to complete the job.
So once you have a clear idea on what you are building, and have done test functions to do the hard bits - then it's time to turn on the music and build the rest.
2: Keep your toolchain and build process independent from the operating system and editors.
3: Don't use IDEs.
4: Have a one command automated build and run as soon as you write a basic skeleton of your project.
an IDE adds complexity when the main goal should be to learn to program. An IDE has a bunch of features you need to learn and understand when learning to program by itself is hard enough.
You don't have to use all the power but letting for example Visual Studio handle the project references and build for a .NET project will allow a beginner to focus on coding. Not to mention all the tutorials will assume they use Visual Studio.
I finally settled on Python after jumping around quite a bit and am still learning.
They introduce unnecessary complexity and tend to make users too dependent on them, while hiding actual functionality behind colorful buttons. There's a reason most productivity-focused programs are terminal or text-mode programs.
An IDE-dependent toolchain is a sure sign of an immature project and, likely, rookie developers.