You've learnt to code, but now what? You may have some basic skills, but you're not sure what to do with them. Here's how to choose and get started on your first real project.
Choosing Your First Project: Start Simple
Chances are you learned to code because you had a few ideas of things you wanted to accomplish, so it's time to pull up that list of development dreams and see what might be feasible. While you can take on a rather complex and time-consuming project for your first -- and you'll definitely learn a lot -- you probably don't have a lot of time to devote and might find yourself giving up out of frustration too easily. I feel the best thing to start with, when you're in the learning phase, is something you actually want to do that you can accomplish pretty quickly. That way you're rewarded with something you made that actually works the way you'd always hoped in a very short amount of time. You can use that triumph as motivation for the next project, which can be a lot bigger.
Figuring Out What's Simple and What's Not What you need to do with each of your ideas is break them down into as many little pieces as possible. In most cases, when companies are developing big pieces of software, they still break down development tasks into tiny digestible chunks and assign them to various members of the team. Those team members then write that specific code and move on to the next task until they're done. Little bits and pieces are created until the software is formed. This is a simplistic, high-level picture of how things work but it's no different from the approach you should be taking to your first and subsequent projects. You don't have an entire development team, but you're still going to need to tackle bits and pieces to form the whole. Large, sweeping tasks don't work in any situation and especially not with software development. Breaking everything down into simple steps is what will tell you if a project is too big or too small to start with. It'll show you what you need to learn in order to accomplish it and the pieces of code you'll actually need to write. Let's look at a couple of examples.
Say you're interested in making a calendar application and the requirements are to have a day, week and month view as well as add, edit and remove specific items. While this isn't exactly a difficult project in the grand scheme of things, it is more complex than it sounds. In month view alone, you'll have to calculate which day boxes are part of the current month on display and which boxes are greyed out because they're part of the previous or next month. You'll also have to figure out how different date items will look, measure how long each item is, truncate the name if it's too long to fit in a box, and so on. What might seem simple can actually require quite a bit of logic so it's important to break down each and every step you can think of so you can decide if it's feasible for you or not.
The same goes for a game like pong. If your maths skills are pretty good, you could create a Pong game pretty easily in about 30 minutes or less. The project you pick should be easy enough that it won't require you to spend a ton of time to finish it, but also plays to your strengths. (You should also avoid making things like Pong and make something new and unique as that is generally more rewarding and motivating when all is said and done.)
Completing Your First Project: Never Stop Learning
Being a developer means you're always learning. New projects mean learning new skills, or at least better ways to accomplish tasks you've already figured out in the past. Your first project is always the most daunting because you're starting out with the least knowledge you're going to have, but as you continue on with subsequent projects you'll learn that pretty much everything you do is going to involve venturing out into the unknown. That's a good thing, but it might take a little adjustment.
Keep Your Reference Materials at the Ready
If you're feeling overwhelmed by even a small project, take your first task and figure out what you need to learn. That should give you an idea of the sort of reference materials you're going to want to keep handy as you work your way through the entire project. What you'll need will vary, but it's very common for integrated development environments (IDEs) to have built-in reference you can check. This is the case for software like Panic Coda (which is a really awesome option on the Mac, by the way), Adobe Dreamweaver, and even Apple Xcode. If you don't have built-in reference, however, you can generally find online resources that detail every class, function, method, and more for your given language. The PHP Manual is one excellent example.
This type of reference materials will need depending on your skill level, too. The online code manuals you'll find are generally pretty dense, and if you still have more basic skills you need to learn to complete the project you've chosen you'll probably want to keep books and tutorials at the ready as well. If you don't have any resources yet, consider the project you're making. Getting specific can help you get a better book, set of video lessons, or whatever you need. For example, if you're making an animation-heavy Adobe AIR app using ActionScript 3, you'll want a book on animating with ActionScript. If you're making a game for your iPhone, get a book on developing your first game. This probably seems pretty obvious, but it can be easy to choose a more generic book on a particular language or task that won't include enough of what you want. It's not bad to have that kind of book as well, but when you're learning you're going to want as many specific examples and explanations as you can get.
Avoid Frustration by Taking It Slow and Getting Help
If you're not used to thinking like a developer -- and chances are you aren't if you're reading this -- you're probably going to get frustrated more than a few times while coding your first project. That's OK, and it happens, but you don't want to get to a point where you feel like giving up because it's too hard. Make sure you give yourself a realistic schedule. An hour a day is a good amount of time to get quite a bit done. It may feel like things are coming along slowly, but that's primarily the case in the beginning. Once you see things coming together and starting to look like a (web) application, your excitement will take you the rest of the way.
The biggest frustration in the development process, however, is bug fixing. No matter how careful you are, you'll will screw up quite a few times and introduce bugs in your app. Fixing these right away is generally ideal, but sometimes you will need to step away from the computer and just look at the code tomorrow. A fresh perspective can make the difference. Another option, however, is having a code buddy. Your code buddy doesn't necessarily have to work on the project with you, but ideally they'll know how to code as well as you and won't mind hanging out from time to time while you work. When you have a bug you can simply ask them to take a look at what you've done and see if anything looks strange to them. Often times it's just a typo you're not seeing but they'll see in an instant. If you don't have a buddy who knows how to code however, the alternative is calling up any friend at all and explaining the problem to them. Explain to them what you're trying to do in terms they'll understand, and try to relay the problem you've encountered in an equally simple manner. Encourage them to make suggestions even though they'll insist they couldn't possibly know. This process can often spark something in your mind and help you figure out what you're doing wrong.
Overall you just have to stay diligent, read up on what you want to do, and fail a lot until you learn the skills you need to finish your project. Developing software can be tough when you start out, but once you get the hang of it you'll find it fun and rewarding. The first project can be the toughest, but if you take measures to simplify everything and keep yourself on task you will be done before you know it.