I made a conscious choice to write 'non work' code every day. It's now a habit (thanks largely to Github's contributions graph... I've got to get a little green square every day!). Sometimes it's just 5 minutes to refactor something or update a README, sometimes it's 5 hours to work on a project, but the result is the same - I spend more time writing code. This has introduced me to frameworks, libraries, patterns and algorithms that I wouldn't have been exposed to otherwise, and it's <i>definitely</i> making me a better developer.
as well as the comments below, I would add<p>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.<p>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.<p>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.
1: Keep everything as simple as possible.<p>2: Keep your toolchain and build process independent from the operating system and editors.<p>3: Don't use IDEs.<p>4: Have a one command automated build and run as soon as you write a basic skeleton of your project.
Read other people's working code. Figure out what they're doing and why and why you like or dislike it. Add their unique qualities to your own repertoire.