Learn to code in 90 days! Then what? Here are five goals for your first year.

Regardless of what path to programming you take, there are many things -- too complex and nebulous to explain concretely -- that stand between those who want to become great programmers and those who, by unanimous agreement, are. You can't just tell a newbie programmer, "Go learn about these 56 things and then you will become that rock star the tech world has been waiting for!" Though, I'm sure that book is just around the corner.As I've written about before, I believe the Learn to Code movement has both its merits and drawbacks. For every well-meaning organization eager to produce its next set of skilled developers, there is another one looking to make the cheap buck on a few videos. Besides that, I believe becoming a great coder takes a long, long time no matter how thorough your training.But, that's not what most people want to hear. That's not the nature of the fast-paced society that most of us live in. We require the silver bullet. We want the corner-cuts that take us from novice to expert as fast as possible. Learn this language, forget that. Learn this technique, skip that. Read this book, not that. Parts of the Learn to Code movement would have you believe that programming is a cookbook -- a recipe set of how to "cook up" an application based on tried-and-true components.I disagree. If you want to be really good at building and designing software for the long haul, you need to experience it from every angle. From the trenches. As the apprentice. As the shot-caller. Naked, by yourself. Together, with a supportive team. What you find is that there is a surprising amount of trial and error -- and what succeeds for some fails for others.For instance, a recent hot debate has been about the usefulness of test-driven development (TDD). David Heinemeier Hannson ("DHH") makes the case that TDD forces you to complicate your software design simply for the support of tests, and the tradeoff of designing more readable code for more testable code is not one he's willing to make. On the other hand, TDD advocates like Uncle Bob Martin ("Uncle Bob") attest that TDD ultimately produces better and more secure software. The tradeoff is one he adamantly takes.These are two of the most well-respected programmers in the world. They even have their own nicknames! But, how have two highly respected coders come to such opposite conclusions?Because over many years (David began creating Ruby on Rails in 2003; Uncle Bob has been a software professional since 1970), both have experienced what it's like to code one way versus another. Their opinions are self-vetted by feeling the pains of doing it one way versus the other. Both are empirically right. And, both might even change their opinion again depending on what kind of software they write in the future.Long-term growth in our industry comes from experiencing all the angles. Only then can you truly formulate your own opinions about how to build software. The fast-forward approach of many coding schools is a great start -- but just that. It will probably get you to a certain proficiency of coding that would otherwise take a few years. But, it cannot fully teach you to formulate your own approach to development in such a short amount of time.So then, what next? I couldn't end this blog post without offering up some elixir -- a roadmap to becoming a great programmer. So, for the new programmer matriculating from a startup school, here are five milestones to hit during your first year in the industry:

Find a job working within a small, experienced team.

Ideally, find a company where you'll be working on a small development team of 3-5 people. Get to know what it's like to learn from others, find your mentors, understand pace and process, and eventually make your own decisions. Get a chance to see what other programmers value and don't. You will need this experience to understand how people work. You will realize that working well with other programmers is at least as important as writing code.

Seek out one very old legacy project to work on.

They'll probably put the newbie on one anyways. I am a firm believer that working with legacy code is crucial for your growth as a developer. It forces you to make pragmatic decisions, not just ideal ones. Maintaining legacy code is all about considering time and cost tradeoffs. You will need this experience throughout your career, because all code loses some resiliency over time. All code becomes legacy code.

Pick up a contract job.

If you have the energy and the willing client, you could do this in tandem with your day job. You'll likely need to estimate costs and timing. You'll find out how hard it is to accurately estimate for a software project. You will find out that what you think is important may not be what your client thinks. This experience will accelerate your understanding of how and why people value software.

Make every next project different from the current one.

Perhaps the next project requires new technology. Or, it's a different staff of developers. Or, it's an internal application instead of one intended for a client. Or, it will be used by a different audience. Look for opportunities to work on a project that has a fundamental difference from the previous one. This experience will train you to challenge the opinions you currently have about software. And, you'll learn that constant reassessment of your beliefs never ends -- that's just the nature of our craft.

Teach someone.

Find someone to mentor. Teaching not only feels good, but often gives you a fuller understanding of what you understand. It helps you combat the Curse of Knowledge, the bias that leads experts to find it difficult to think about problems from the perspective of a novice. Teaching will also help validate your opinions as you progress throughout your career.