Programming as a Beginner and the Little Book of Talent
A few months back, Josh Cheek tweeted about the Little Book of Talent. Intrigued, and given what I know about Josh’s taste, I ordered three copies. Needless to say, Josh’s recommendation was right. You can devour the whole book in a short sitting, but the lessons deserve some time for reflection to sink in.
I’m not going to mention each of the skills Coyle covers, but there are a few that I thought were particularly useful when thinking about learning software development. For the rest, go buy the book. Go ahead, do it.
Programming is a Soft Skill, Sort Of
Coyle differentiates between Hard Skills (those that require repeatable precision, like shooting free throws in basketball) and Soft Skills (which require creativity and pattern recognition).
As the author mentions, most tasks break down into both types of skills. Learning a new IDE or development flow is a hard skill, whereas writing software itself is probably a hard skill. I feel the need for that qualifier because I think there’s also a third part to programming which is out of scope for The Little Book of Talent — knowledge. As a new developer — or an experienced developer on a new stack — you need to address all three of these areas.
Possibly the most interesting thing in the book is how you practice the different types of skills. The author argues that for soft skills, you should practice by exploring within a challenging environment. For hard skills, by contrast, you should focus on nailing the execution of each piece with perfect precision.
So, when you use vim tutor, you’re learning the hard skill of operating that editor. When you do Ruby Koans, you’re learning knowledge, or maybe some kind of hard skill? But in neither case are you learning the soft skill of software development. I’ve been trying to figure out why most online courseware for learning software development falls flat, and I think it’s because of this confusion of purpose.
On the other hand, I think exercism.io gets this part right: the challenges offer enough room for experimentation, which is great. When I developed LevelUpRails, it was with the same goal in mind: challenges that give you enough room to get yourself into trouble.
Frustration is Part of the Process
When you work on your development skills, you’re going to suck for a while. I’m sorry, I wish I knew how to get over that part more quickly, but it’s a necessary step in becoming competent. Coyle argues that we should embrace that part of the process, and I think this is reasonable.
The better resources I’ve seen for learning are challenging, because programming is challenging. Every day as I program I feel some of that same frustration that I see in newer learners, so I empathize with how crappy it feels sometimes.
I think this is another reason why there are ineffective programming courses that are very popular. The pattern I hate most, which I see all the time, is the sort of fill-in-the-blank keyword game that makes you feel like you’re programming, but leaves you entirely unequipped to write software. By reducing the difficulty until people can comfortably glide through each challenge, the authors are removing the opportunity for real learning.
I think perhaps that those kinds of courses are useful for acquiring Knowledge; about the Rails API, or how we structure programs. But they aren’t presented or sold to learners as such, and that’s a shame.
To Learn More Deeply, Teach
Finally, as you follow your path to learning better code, remember to take some time to teach others. Don’t fret that you’re not yet an expert. Everyone has to learn the very basics, and after a few weeks of concerted practice you can teach those skills to others. Not only will it reinforce your own learning and make you a better developer, it’s really satisfying.
