In my last post, I showed that while there’s a whole lot of stuff to learn about being a programmer, you can prioritize what to study next by comparing what you know now with two things:

• What you need to know to help your next project;

• What you want to know to advance your career or to improve your craft in the long term.

What’s your approach?

Now that you know what you need to learn next, the natural question to ask is _how _should you learn it? A quote attributed to Confucius says:

Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand.

Undoubtedly, some of you reading that quote will feel some affinity: you need to dive in and play with things before you fully feel like you understand them.

That’s not true for everyone, though. Some people prefer to build a mental model in their head before diving in, to understand the theory before putting it into practice. Others are happiest when they can dive in, but rather than experimenting they want to have a problem to solve. While some people would like to build something from scratch, others like to take existing code and modify it, seeing the effects that their adaptations produce.

Knowing which of these approaches works best for you can help you to decide what materials and context you need in order to get the most out of your study. Personally, I’m one of those people who prefers to understand the theory first: I learn more if I know what the problem looks like and then try to associate the solution to that model. I’m a visual learner, too, and get a lot out of diagrams and simulations: the fact that I use phrases like “looks like” and “model” in this post are little hints that show (there I go again) that this is the case.

As an aside, maybe that’s why I find the practice of test-driven development so appealing. The red-green-refactor cycle lets me describe what I know about a problem before thinking about how I should solve it.

I get to choose from a whole range of media—books, blog posts, conference presentations, podcasts and more—that will explain things in a way that suits my style of learning.

Let’s look at a specific example: say I want to learn a new part of Apple’s iOS APIs. To understand the theory and the problem that’s being solved, I would probably start by looking in the guides section of their documentation. If you learn better by experimentation, you’d be more likely to head to the sample code first. Those of you who prefer to find out what’s possible before applying it will enjoy reading the reference documentation instead.

Learning at big nerd ranch

I find it pretty amazing that Big Nerd Ranch caters to all of these different approaches to learning. The books, which form the core of the training material, cover the concepts for people like me. They also include walk-through implementations so that you can see how these things are done, as well as challenges for those of you who enjoy going off-piste and exploring on your own.

And of course it’s not just about the books: in our bootcamps, the instructors (myself included) are there to discuss the theory, the practice, our experiences of what works and what doesn’t work. To accommodate different learning styles, we use text presentations, images and even song and dance routines.

In our classes, talking to the people seated next to you isn’t considered cheating, but encouraged. When you’re facing a problem, explaining it to a peer not only helps you organize your thoughts, it also allows you and your peer to share what you understand. We even include a bit of a hike every day at our Ranches, offering time to discuss what you’ve learned with your fellow students and to reflect on the day’s teaching.

So what way do you learn best? We’ve got you covered.

Image courtesy of Andrew Jones.