The best thing you can do is immediately start using what you learned. My friend and cycling coach Tom Scotto frequently utters the phrase, “Practice doesn’t make perfect, practice makes permanent.” That advice applies to more than just cycling. You want to practice what you learned, whether it’s sports, tech, or music, so that it becomes a part of you.
The way I cement knowledge in my head is to find a project to work on. Think about what interests you, and the tech you want to use, and then Make An App for it. Just start writing. At first you’ll pretty much copy and paste from what what you learned. You’ll crib from online tutorials. That’s OK. You’ll understand that stuff better just by osmosis. Then as you start fleshing the app out you’ll have to learn new stuff. You’ll be using unfamiliar parts of the frameworks you’re already using. You’ll start learning new frameworks. Before you know it, you’ll be an expert.
What kind of projects can you do? The possibilities are endless. For me, they have to have some direct, personal meaning for me to keep working on them. Here are some of the projects that I worked on over the years that have led me to really learn some specific chunks of tech.
It might be a something associated with some interesting aspect of my job. One of my more useful little apps took a file from my heart rate monitor and calculated how much time was spent in different heart rate zones so I could better target my training.
I had the opportunity to learn XML parsing in general, and parsing Garmin’s TCX file format in particular. Once I got the raw data out of the file I wrote some analysis code and displayed the results in a simple tableview.
I showed it to a some folks in our winter training workshop, and eventually everyone wanted their own copy.
Another little app took a GPS track and generated a KML file that would make a Google Earth animation, extruding a line along the path and having the camera follow along.
This involved writing a small program to read the GPS track and construct the KML, along with tons of knobs that could be tweaked, like size and color of the line, animation rate, and so on. There was also some AppleEvent stuff to communicate with Google Earth, such as figuring out the current camera position. I used Python for the construction of the KML.
It might be a project for someone in the family. I’ve been writing embroidery design software for my wife off and on for the last several years. This particular application lets someone create stitching charts for figures composed entirely of Queen Stitches. You might think that’s a pretty niche target audience, and you’d be right! But it let her create nice looking charts for a kit she was selling. This was actually written pretty early in my Cocoa career, letting me figure out segmented controls, the Cocoa document architecture, Quartz drawing, and so on. Plus I learned a lot about something important to my wife.
It might be something that just directly interests you. I haven’t found any iPhone music dictionaries that actually contain the markings on the parts I’m looking at in rehearsal. I’ve downloaded a couple during rehearsals and they weren’t of any help, so I started making my own. I’ve been having fun implementing the behind-the-scenes data structures, as well as accumulating the dictionary contents from actual orchestral parts. At the same time, I’m learning some fancier table view API and implementing live searching.
The projects don’t have to be huge, boil-the ocean things. I could have written a huge comprehensive heart rate exercise tracker (and in fact I’ve sketched out the design for one). Or I could have written the end-all-be-all embroidery design software suite (also sketched one of those out), but I’ve found that many times big projects never get finished. All of these completed projects are pretty small, implemented in a couple of days or a few weeks.
Don’t worry about making these things perfect. Perfection is the enemy of progress. I’ve seen many programmers, young and old, give up on a promising project because they got stuck in one corner of the code, polishing it and making it perfect, fixing another One Last Bug, and then getting frustrated or getting bored.
My work style is: Get stuff up and running. Make it work. Having problems with one part of the project? Move on to another part. Don’t worry about leaving behind messy code, you can clean it up later. Sometimes ignoring a part of the code for a week or two can be good. You’ll have a fresh perspective when you come back to it.
For example, you can see some lameness in the music dictionary screenshot: no icons on the tab bar, the index bar on the right-hand-side is really messed up (what is that “C” below the “T”?), the app name and logo at the bottom of the tableview are embarrassingly terrible, there are better ways to show the definitions to pack in some more information or make it more readable. But it works well enough to actually use, and there’s still enough fun parts left to implement in the app to keep my interest up until I can come back and fix those problems later.
Of course, if you’re writing software professionally, you probably don’t want to adopt this workflow. But for personal apps, and apps used to cement your knowledge of Cocoa or CocoaTouch, it can’t be beat.
One last bit of advice: be sure to keep your code in some kind of source code control, such as subversion, git, mercurial, etc. Even better, store it on a hosting service like bitbucket or github. You can get private repositories if you don’t want the world looking over your shoulder. I’ll talk about source code control later, but you can think of it like a great big undo for your projects. You might find another programmer to work on you on your project, and having your Stuff in source code control makes it easier to collaborate with other folks. Also make sure you have an off-machine backup, in case you accidentally spill a two liter bottle of Dr Pepper into your laptop and it eats through your SSD.
This is how I’ve found the best way to put new found skills to use. If you don’t use them shortly after you learn them, you lose them. Hopefully this little catalog of programs I’ve written over the years gives you some ideas about the kinds of apps you can write yourself.
Got any cool projects you’ve done after reading one of our books or taking a course at the Big Nerd Ranch? Post ‘em in the comments here!