Year two of this blog has come to an end. Let’s review the topics and posts from 2016.
Can you learn anything you want by reading a book? A blog post by Scott Young last week got me thinking about claims that some subjects are unteachable. Here are some examples:
Claim: Some knowledge and skills can only be learned using an apprenticeship approach.
- Scott contrasts two learning techniques. One is the standard school model that we’re all familiar with: a student reads textbooks, attends lectures, and turns in assignments. The other model has more in common with apprenticeship: a student finds an expert practitioner, observes what they do, and tries to replicate it.
Claim: You have to figure out your own path to success. You can’t learn the path from someone else.
- In his book Linchpin, Seth Godin writes: “Telling people leadership is important is one thing. Showing them step by step precisely how to be a leader is impossible.”
Claim: It’s not always possible to teach someone to be a top performer, despite the best efforts of teacher and student. Factors other than practice time explain why some people perform better than others.
- In her contribution to the deliberate practice debate, psychological scientist Brooke Macnamara published a meta-analysis arguing that practice doesn’t have a large impact on the performance differences between expert performers.
In the Peak book, the authors describe the following learning challenge in a section called “Getting Past Plateaus”:
When you first start learning something new, it is normal to see rapid — or at least steady — improvement, and when that improvement stops, it is natural to believe you’ve hit some sort of implacable [immovable] limit. So you stop trying to move forward, and you settle down to life on that plateau. This is the major reason that people in every area stop improving.
The concept of the learning plateau is one way to describe how people approach learning, work, and self-improvement. With a new skill, there’s an initial period of excitement driven by how easy it is to make progress. Then a plateau arrives, and you have to decide whether to push through it or stick with your current skill level. And even if you push through it, you can look forward to another plateau where you’ll get to make the same decision again.
For most skills in life, there’s no need to push through plateau after plateau. It’s not worth the effort to become an expert in driving a car unless that’s your hobby or profession. But for the field that you specialize in, you probably do want to keep getting better. So what’s the secret to avoiding or conquering a learning plateau? The authors of Peak have something to say about that as well:
Any reasonably complex skill will involve a variety of components, some of which you will be better at than others. Thus, when you reach a point at which you are having difficulty getting better, it will be just one or two of the components of that skill, not all of them, that are holding you back.
According to this approach, the way to resist the plateau effect is to break down your target skill into its constituent parts, and be prepared to target those parts individually. In the book, the authors use typing speed as an example. Everyone who learns to type eventually reaches a speed plateau. Physical constraints mean you can’t keep increasing your typing speed forever. But you may plateau at a speed that is below your physical limits, or at least is slower than you want.
One idea for increasing your typing speed is just to push yourself to type faster whenever you get the chance. But according to the authors, there’s a more effective way. Rather than trying to type faster 100% of the time, try typing faster for just 15-20 minutes per day. During that time, document the mistakes you make. It’s likely that some letters or letter combinations will trip you up more than others. Once you identify them, you can more efficiently target those components, rather than trying to get better at the skill all at once.
Typing happens to be one component of the skill known as competitive programming. If your typing skills are slower than average, or if you’re competing at a high level in timed contests, working on your typing speed might be worthwhile. But for most competitive programming enthusiasts, working on other skills is more likely to produce results. What are those other skills?
Psychologist and deliberate practice pioneer K. Anders Ericsson has been studying and writing about deliberate practice for decades, and his landmark 1993 paper provides an accessible introduction to the topic. This year, he published his first book-length exploration of deliberate practice for a general audience. Peak: Secrets from the New Science of Expertise explains the idea of deliberate practice from the ground up, and provides examples of how people have used it in different fields. I started this blog with the goal of studying and explaining deliberate practice techniques for software developers. This week and next, I’ll be applying the ideas from the book to that end. As usual, I’ll be drawing my examples from competitive programming practice.
The topic for this week: Mental representations.
I love the idea of books. Years ago, I used to browse in bookstores. I bought paper copies of some of the books I looked at, and read some of the books I bought. Once Amazon came along, I clicked around their suggested items list for ideas. These days, I keep an Amazon wish list of Kindle books. When I’m reading online and someone recommends a book that looks interesting, I add it to the list. Often I can download it from my local public library. Sometimes I’ll buy a copy if a book is too popular to get from the library, or if I just decide that I want to have it around.
I find that always having an ebook on my phone is the best way to read more books. When I have some spare time, instead of clicking around the usual sites, I can read a few pages of a book. When I’m done with it, I download another one. Since the books are electronic, I don’t have books lying around taking up space and waiting to be read.
In some ways, it’s a better time to be a reader of books than it has ever been. But books still aren’t perfect. Here are a few complaints about (nonfiction) books.
Last week, Quora hosted a session with Barbara Oakley, one of the two instructors for Learning How to Learn, “the world’s largest online course.” During the Quora session, people asked her questions about learning techniques, public speaking, online courses, and other topics. I took the Learning How to Learn class when it was first offered on Coursera, and found it to be a good survey of current learning research, combined with plenty of advice on how to apply it. So when Oakley’s session popped up on Quora, it caught my eye.
It’s worth taking the whole course on Coursera, but the Quora session offers a concentrated summary of a few key ideas. I thought it would be interesting to apply some of Oakley’s advice from the session to the type of learning that goes on here at Red-Green-Code.
One year ago, I started writing here on the topic of deliberate practice techniques for software developers. This is my 52nd weekly post for 2015. With the year coming to an end, let’s review the story so far.
Here are two approaches you could take to learn something new:
Passive review: Consume an explanation of the topic you’re trying to learn. For example, read a textbook chapter, watch a video lecture, or read an online article on the topic.
It shouldn’t be hard to guess which of these approaches is more effective at reinforcing what you know about a topic. Although you have to consume new information at least once through a lecture or other means, continuing to passively consume the same information repeatedly doesn’t help you learn it much better. The brain seems to take retrieval more seriously than storage: neural connections are strongly reinforced when information is actively used, but information that merely arrives through the senses receives a comparatively weak boost.
When I was working on my undergraduate degree in Computing and Software Systems, I took a class in software engineering. The purpose of this class was to introduce us to the range of real-world processes that professionals use to develop software, processes that didn’t often come up in our academic work. That goal turned out to be a tall order for a three-month class, given the scope it tried to cover. It might have been more effective to pick one process and use it for a group project. Nevertheless, one exercise I remember from the class is matching software development processes to types of projects.
Here’s the type of question I’m talking about, from a University of New Brunswick class assignment:
Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:
a) A system to control anti-lock braking in a car
b) A virtual reality system to support software maintenance
c) A university accounting system that replaces an existing system
d) An interactive travel planning system that helps users plan a journey with the lowest environment impact