I started learning to program in January 2016. Prior to that, I had a rough idea of some required concepts and things like basic terminal scripts, but I’d never written an actual program. I had made a few stabs at learning before, but these attempts usually ended somewhere during the first few tutorials. Now that I’ve actually stuck at it, I thought it would be good to reflect on the past year, and examine what was different this time. This is something that will be useful to me going forward, but might also be helpful to someone in the position I was in a year ago.
As near as I can tell, the main difference this time has been the presence of a clear goal. I’ve always been driven by specific goals. I learned to play piano because I wanted to play Beethoven and Chopin. I started composing music because I wanted to hear something I’d written. I learned to take and edit pictures and videos largely to facilitate jokes among my friends (not the most useful goal, but a goal nonetheless, which subsequently has led to some work I’m really proud of.1). Goals were always the mind-viruses that motivated me to keep practising until I could do what I wanted, even if that meant long stretches into the wee hours.
Programming, on the other hand, was just something I wanted to be able to do. It’s a skill that always appealed to me, and I imagined the creative possibilities that it would open up, but simply wanting the skill doesn’t lend itself well to how I learn. In short, I thought “I really want to write an interesting app, I just need to learn the skills to do it”, and ignored the fact that I hadn’t yet thought up what this ‘interesting app’ would be.
What changed was that towards the end of 2015, I had an idea for a music game (well, an idea relating to music, the easiest execution of which would be a game), and I really wanted to create it. So, I finally had the goal I needed.
Since I’m a macOS and iOS user, and I was starting from scratch, Swift seemed like the path of least resistance to accomplishing my goal. I began with Apple’s Start Developing iOS Apps (Swift) tutorial. I ran through it and tried to absorb as much as I could, stopping to research when I hit an unknown term, or a concept which eluded me. These would probably have been potential stopping points in the past, but with a goal in mind I powered through. Once I’d gotten a gist of Swift, and had a basic understanding of UIKit, I decided it was time to start my own project — Tapt.
Faced with a blank slate, I did something obvious, which I don’t often do; I planned ahead. I needed to start with something simple, that I had a reasonable hope of being able to program. I distilled Tapt to its absolute essence; the problems I needed to solve in order to make a basic version of it were:
1) Create a button which, when pressed, plays a note.
2) Record a series of taps.
3) Compare this input to the ‘correct’ data.
While most projects should probably begin with this type of breakdown, the more salient point I’m trying to communicate here is that I actually had a clear idea. Rather than having a vague inclination to make a music game, then feeling around for ways to execute it, I had a crystallised idea which I just needed to elucidate. There was no struggle to actually flesh out the idea, I just had to spend time running through its exact details.
There’s nothing wrong with feeling around to decide the precise nature of an idea, but again here I’m talking about choosing the path of least resistance. The fact that I had already a clear idea in mind meant I could quickly determine the problems that needed to be solved, focus on the programming, and keep moving on with Tapt.
I persevered and kept learning what I needed to learn to make the next component of the app. I had a very rough version of it up and running after a couple of days, and by the time I had these core elements figured out, I felt I’d gotten past the steepest part of the initial learning curve. At this point I started moving onto things that did require some feeling around: working on the details of the UI, refining the algorithm for detecting rhythms, and other more subjective elements of the app. Because I no longer needed to research every step, I could allocate more focus to experimentation and figuring things out. Since then, I’ve kept a goal-oriented approach in mind. Rather than abstractly trying to learn a new concept, I’ve spent time thinking of a goal that required me to know it, and then worked towards that goal. Using this approach, Tapt went from its most basic incarnation to the 1.0 version I shipped, in about 4 months of evenings-and-weekends work.
This has proven to be a really successful strategy for me, and has kept my motivation high for vastly longer than other approaches I had tried in the past. A really clear goal, which doesn’t have to be original or groundbreaking, just something which is crystallised in your mind, is a powerful motivating force. Much or all of this may seem obvious, but hopefully it’s food for thought for others in my position, whether that be in relation to coding, or any other activity.
Tapt is free on the App Store, click here to check it out.