For anytime you are learning something new, you can basically just fill in the blank to the statement “[whatever it is you’re trying to learn] a little bit every day.” Learning to code is no exception. Coding regularly, preferably a little bit every day, will play a huge role in your degree of progress.
But in contrast to, say, learning a language or how to play an instrument, you can’t really do the same workouts or songs day in and day out. Instead, you need a path to follow, and then commit yourself to take at least a step or two every day.
Tutorials are a good initial path, but not for long. You’ll want a path you can follow over an extended period, and you will soon want to start applying what you’re learning in a new context, since you won’t really learn all the stuff you read in books and tutorials until you are forced to re-apply it and really think about you’ve learned.
For an aspiring coder, I see three basic steps in working on a real-life project: picking a project, getting started, and figuring out what to do next.
Picking a project
Assuming you’re a total beginner, the first few projects you pick can be pretty much any relatively simple challenge. I recommend, for example, building an app for creating todo lists.
Maybe try re-creating just one or two of the most core pieces of functionality of an app like this.
What’s most important is that it is not something you just worked through in a tutorial. Beyond that, it can be any very basic piece of functionality. As you are likely to discover, even seemingly simple applications have the potential to quickly become ridiculously complex. Learning to keep things simple is just one more benefit of working on an actual project.
Once you’ve got a little experience under your belt, you should pick something that is closer to your heart, ie some idea you’ve had for while, or something related to an interest or hobby you have. In my case, the project I have been working on is ChirpyBox, a social suggestion box, which I’ve been working on for the last several months.
Working on this project has forced me to think more holistically about what I’m coding, such as the larger product vision, possible revenue models, and what might be the simplest, smallest version of the product I could build and launch that would still be considered a whole product. This big-picture perspective of what you’re building is something you’re not likely to take when working on a tutorial.
One of the hardest parts of making software, or any design endeavor for that matter, is figuring out how to get started. Do I just dive in and start coding? But what would I code first? Should I be writing up all kinds of detailed documents describing what the product will look like? Do I need to create bunch of wireframes? etc.
If you are doing this to learn to code, you’ll likely want to do a little of this up-front work but not too much. Do a quick write-up on the purpose of the thing you’re building, who might be using it, and a basic scenario or two describing them using it. Then mock up a few screens of a basic user flow.
Here’s an early flow I created for the ChirpyBox product.
Very soon after I started working on coding these views, I had several insights, such as maybe to display the suggestion that was just posted in the confirmation screen, and also asking myself if the idea of using a passcode really is the way to go. (Since this early iteration, I’ve moved away from the passcode concept.)
This is one reason you want to spend a little time on the up-front stuff but not too much, as you are likely to have many of your key insights while you are coding.
Figuring out what to do next
In contrast to working on a tutorial, where you are basically following a pre-defined path, you have to forge your own path when working on your own project. It is easy to start to feel overwhelmed by all the various moving parts. Should I work on this feature next, or that one? Are those features even relevant if I decide to take the product in this other direction?
To stay organized, I strongly recommend using a planning tool like Trello to manage your various features and tasks. Now, it may seem strange to have a planning tool when you’re the only person working on a project. However, you’ll be amazed at the number of things there are to do when creating an app, from coming up with a feature list, to considering logistical issue, to dealing with technical roadblocks, and on and on.
Just as importantly, if you are like me, and can only spend a little time every day or two on this, you often lose track of where you left off and what you were working on. So a tool like Trello will help remind you of your status.
Here’s what my Trello board looked like recently:
I’ve got one column for the laundry list of features I’d like to include “some day,” and then another column for tasks I need to work on, roughly prioritized. The doing column is only for stuff I’m working on now, and then the done column, of course, is for stuff I’ve completed.
It’s very basic and light-weight, which is great, since priorities and design directions are changing constantly, just as they would in a real-life project.
For me, working on ChirpyBox, has and continues to be a great learning experience. If you are learning to code and don’t already have a real project you’re working on, then don’t delay and start thinking of one today!