Imagine for a moment that learning programming is like climbing a mountain. The start of the climb is very steep, and most people end up falling back down. But a fair number of individuals get past this initial slope. They finish an online course or get half-way through an ebook or just generally mess around enough to get the basics down. And then they start to get bored. They don’t want to do another course. They didn’t start this journey just for the experience, despite what conventional wisdom might advise. They want to do something that’s actually useful or meaningful, something of their own creation. And so after ascending this initial learning curve they find not a second slope, but a chasm. This is the gap between what they had to do to learn the basics and what it takes to actually do something novel, to do their first programming project.
Jumping from something like a Codecademy course to a full-on solo project can be extremely intimidating. I mean, how can you possibly go from formatting strings and iterating through dictionaries to developing games or programming conversational sex-bots? It almost defies intuition that this would be possible. But as it turns out, the chasm is often narrower than it seems. Let’s see why.
Take my own first programming project as an example. I wanted to write a program that could compose music. At first glance, this seems pretty ambitious, and frankly I had a lot of doubts. “This sounds too complicated, I’m too busy for this, I’ve never done anything like this before, what do I know about composition anyways, do I really think I can make a computer do what only talented humans can, maybe I’ll just take another course, yeah that’s right I think I saw something on Coursera…”
Whoa, let’s stop right there. There were two big problems with this line of thinking. First, my sights were set way too high. I psyched myself out by thinking I had to make something impressive and world-class. Second, I assumed I had a good idea of how difficult the project was going to be, when the truth is that unless you’ve done similar projects in the past, you can’t really know how rough the going will get just from sitting in your armchair.
The solutions? First, I revised my expectations. “I don’t have to make something world-class, just something that makes unique, vaguely-musical noise on command.” Much better. My dreams of building a Chopin AI can wait. Second, instead of sitting there making more excuses, I identified what the first, easiest problem was that I could try to solve. The lowest-hanging fruit. So instead of worrying about the whole entire hairy project, I was able to focus on one specific, actionable thing: making my computer make noise. Here’s what I came up with (in Python 2 at the time):
import winsound freq = 440 # hertz dur = 500 # milliseconds winsound.Beep(freq,dur)
WOW! What an earth-shattering achievement (taken straight from StackOverflow), yes yes I know, no need to congratulate me. But honestly at the time it was a breakthrough. If I could make my computer make sounds with code, and if I could have success with the very first thing I tackled on this project, what’s to stop me from completing the rest? Don’t underestimate the importance of quick wins, especially at the outset.
So great, I could make beeps and boops at will, but it turned out that winsound wasn’t of much use for more complicated musical arrangements. Turning to Google and searching for something like “python music packages”, I soon found all kinds of promising packages. I probably tested out about 10 or 15 until I found one that seemed workable, but from there it was just a matter of methodically solving one specific problem after another until, lo and behold, I actually had a working program. Its compositions still have yet to go platinum (they sound like a mechanical nightmare), but it was still pretty cool to press a button and listen to a totally unique, never before-heard piece of music (even if it makes my ears bleed), especially with only a couple hundred lines of code!
So in my experience, this is the general process for beginner-to-intermediate solo projects, not necessarily in this order:
- Come up with an idea for a project
- Identify the first, most minimal problem you can solve
- Identify the relevant packages
- Complete your minimal initial step, likely making use of one or more of the packages you identified
- If you hit a barrier, make use of your resources (Google, StackOverflow, package or language documentation, Reddit, favorite programming book, programmer buddy, professor, local library, etc.) or reevaluate project scope or your choice of packages
- Iterate on this stepwise process, relentlessly focusing on and conquering one problem at a time
- Bask in the glory of your modest but functioning achievement
Now this is certainly a simplified and generic list. But that’s basically all there is to it, particularly at the beginner stages. There’s no quantum-mechanical equations to derive. No impenetrable Matrix-like screens of flowing 0’s and 1’s to interpret. Just like if you were drawing a picture, composing a piece of music, or solving a mystery, you just need to keep putting one piece of the puzzle together after another until it’s finished.
So assuming you have a working knowledge of most of the basics, don’t wait for another course or ebook to get started. You are going to learn far more blazing the trail on your own than you will with yet another guided tour. Manage your expectations, but don’t restrict your creativity. Expect a challenge, but remember, this is fun. Best of luck.
If you enjoyed this be sure to subscribe, and if you have a minute I’d love to hear in the comments what your first programming project is going to be (or already was). And feel free email me with any questions, I’m always happy to help.