cogent free knowledge

Personal blog of Joel Clermont, a Milwaukee PHP, Ruby and .NET developer

Who Is Responsbile for Your Learning

Are you expecting too much from an author, speaker or teacher? Take charge of your own learning instead. Consider some tips from a recent “Learning how to Learn” newsletter.

Effective learning is not passive

My goal with this newsletter is to provide an idea, tip or strategy that you can immediately put into practice to become a more effective learner. In order to benefit, though, you need to both read the information and then try it out on your own. Even if it seems silly, obvious, irrelevant, just try it. Reading should take no more than 5 - 10 minutes. I will keep each article brief and focused and give you a link to more information if your curiosity is piqued.

This idea of trying something out is the focus of our first installment. So often, we approach learning as a passive process. We may not explicitly think about it that way, but the assumption is there. In fact, it was likely planted there as a child. Think of how you were taught in school: A teacher lectured, maybe assigned some additional material to read on your own, and then you were given homework to demonstrate that you learned the day’s lesson. Your job was to pay attention, ask a question if something was unclear, then go off on your own and try to reproduce what you learned by completing an assignment.

Now think about how you approach learning today as a professional. You buy a book, attend a workshop or conference, watch a video. Many times, that’s it. There isn’t even any homework to try to prove to yourself that you learned something. In this approach, just simply taking in information, whether it’s by reading or listening, feels like an accomplishment. I finished that book! I heard some awesome talks at a conference! I have new knowledge! But do you? Perhaps you were exposed to some new ideas, but did you really understand them? Have you applied them to your own projects or problems?

This is where many end up feeling frustrated. They invested their time and money, but they don’t really feel any further ahead than before. Unfortunately, I’m going to break some bad news: The solution is to actually make yourself more frustrated. You need to flip the whole process of learning on its head and view it as an activity that you are driving, not the author or speaker or teacher.

There is a growing movement among college professors, especially in the field of mathematics, called Inquiry Based Learning. Instead of lecturing or assigning reading, they start by presenting some very basic facts or definitions, and then propose problems for the students to solve. Here’s the tricky part: they never explicitly showed the student how to solve the type of problem before. Initially, many students find this bewildering and frustrating. How can they possibly solve something they haven’t yet been taught to solve? But, as they persevere and explore the topic through trial and error and discuss it with fellow students, they do eventually reach the solution. Perhaps it takes them several classes, or even a couple weeks, but once they’ve found the solution, it has a much more profound impact on them. Studies have shown that you are more likely to remember something you discover in this way than something merely taught by rote in a lecture or book.

Isn’t that what we, as software developers, want? We want to truly gain new concepts, new ways of thinking, new methods of solving problems. We don’t just want to memorize solutions in hopes that we can apply them to a real-world problem some day. Here’s the catch though: very few software books are written in this style (see below for an exception). Instead, it’s a more traditional written recitation of facts and information. But, by shifting our mental model of how learning takes place, we can still apply these same concepts as we learn.

Don’t learn too much at once. Focus on one idea or concept before moving on. In a typical book, this will often be far less than a single chapter.

Try it out as soon as possible. Don’t cut and paste code, instead try to reimplement it yourself from memory. If you can’t remember, don’t immediately go back to the book or search the Internet. Stick with it, try and fail, experiment, make it work.

Challenge the author’s statements. Try to prove them wrong. Extend their ideas. In what situations does it work and it what situations does the solution break down?

Concepts, not solutions. The goal is to improve your ability to solve problems, not to merely solve a contrived set of problems presented in the book. What is the core idea being taught? Can you restate it? Can you defend it?

Yes, this approach is a lot more work, but that is the point. You are teaching yourself. You are exploring ideas on your own, thereby really mastering them. In the end, you will have actually learned something and not just feel like you should have learned something.

For more information on the concept of Inquiry Based Learning, check out this video: Creativity in Mathematics: Inquiry-Based Learning and the Moore Method. If you can get past the cheesy music and the fact that it’s focused on mathematics, you’ll see the benefit of this approach to learning.

Okay, so you read the whole article. Remember that is ONLY step one. Now go, try this out!

P.S. One notable example of a book taught in the spirit of inquiry-based learning is The Little Schemer (and others in that family). Even if you never plan on writing Scheme/Lisp, I highly recommend working through this book. It will give you new ways of thinking about software, ideas that transcend a specific language.

If you enjoyed this article, and want more tips on effective learning for software developers, take 30 seconds and subscribe to my newsletter below.

Become more effective at learning. Subscribe to my newsletter and start improving your skills!

* indicates required
Email Format

Comments