Corey Ogburn

In order to become a good developer you need to have experience. Some people will start off appearing to be better developers than other people in class or early projects at work, but when the projects get bigger and the tasks get harder, the experienced developers shine. The best way to get experience is to go from job to job taking on a variety of different kinds of projects, but this is too reliant on other people hiring you and the kind of projects they give you. The better alternative is "private research," your own personal projects. I mentioned this before but some of the problems that arise are Motivation and Inspiration. A bunch of Hello, World! applications would provide you with some experience I guess, but obviously not the diversity that it'd take to be a valuable developer and a good colleague. Remember, it's not just important for your boss to like your output, it's equally (if not more) important for your coworkers to appreciate your input. A good quote about this is "write your code as if the developer who works with it after you is a psychopath and knows where you live." It could not be more true.

Inspiration. It's hard to practice a particular concept without having a desired outcome, so you need a semi-functional idea in mind. Of course the application is specific to the concept you're wishing to learn so there's no indefinite list of small apps to develop in order to learn everything. Some good starters might be a small chat program to learn about ports and sockets, maybe a calculator to learn about how to retain control over the state of the application when the user has a wide variety of choice inputs (a calculator app can be harder than you might think, even for a simple add, subtract, multiply, and divide integer based calculator), or even something as simple as an address book to learn about file storage and searching large amounts of data. You need to be inspired by somebody's needs. Even if your app isn't the best one out there, by having a set of goals to hold your output against, you no longer have a reason to call it quits on a feature if it gets too hard. This ties into motivation. Different people are motivated differently. Some people are motivated by the rewarding feeling of an empty to-do list, very task oriented people. Some are motivated with rewards for meeting these tasks or finishing a project. Sometimes it's the monetary gain of the finished project that motivates you. Regardless how noble your motivation is or not, it usually takes some sort of drive at two different points during a project:

1. The beginning. Some projects seem daunting and it's not always obvious where to start. You need to use your own motivation technique to get past that hurdle. Abstract the project into each feature and start with the feature used my the most other features. A good foundation like that can make new features easier to add. Maybe all you need is the perfect design pattern, such as Model-View-Controller (MVC) or Model-View-ViewModel (MVVM), but read into them first, do not try and force a design pattern where it doesn't belong.
2. The ending of a project. I especially lose motivation on personal projects where I don't have a due date or I have no gain for the finished project. The pieces of the project are all pulling together and you already have it all planned out. Sometimes you just want to move on or take a break. Well, it's not impressive on a resume to say "My personal research includes X, Y, and Z" and the interviewing company asks you to present these incomplete projects as part of the interview. You have to be prepared. The task-oriented have less of a problem with ending a project, in fact, many task-oriented people I know have a harder time beginning a project but near completion speed up and finish ahead of time.

Advice, Misc motivation inspiration