Surface Learning vs. Deep Learning
By William Hertling
My software development team has been growing by leaps and bounds lately, and the engineers we’ve brought on have varying degrees of experience with software development in general, and with Ruby/Rails in particular.
Watching everyone go through the process of picking up Rails, I was struck by how differently people learn.
Some needed to thoroughly understand how and why something worked before they could integrate it into their thinking. This initially seems like an advantage, because, over the long run, having a deeper knowledge of how something works will lead to more intelligent and strategic approaches to solving coding problems.
Personally, I like to find the smartest way to do something with the least amount of work, so I value in-depth knowledge that can be used to improve effectiveness.
But it turns out that I don’t learn software that way. Instead, I tend to use the other approach that I observed: copying known working solutions with what appears to be minimal regard for how and why they work. In short, I google to find out how other people did something, then cut and paste their solution into my code. (Right now, half of you reading this are groaning, and the other half are thinking, “I do that too!”)
This cut and paste approach seems like it would yield only a cursory understanding of programming, with none of the depth needed to solve more sophisticated problems.
However, imitation or mimicry is the first of three steps of learning:
- Imitation
- Integration
- Innovation
During the imitation stage, the learner is acquiring basic knowledge. The second stage of learning is integration or improvisation. In this stage, the learner can begin to apply the basic techniques they’ve learned in a variety of scenarios. The last stage is innovation, where the learner has mastered the topic to the point where they can create genuinely new solutions.
Let’s call the people who uses these two approaches deep learners versus surface learners. The deep learners have a solid understanding of everything they learn, and how it relates to everything else. The penalty they pay for this is slower initial learning and productivity.
The surface learners, on the other hand, will often be highly productive in the beginning, at the cost of making mistakes or having inefficient or just plain weird solutions. Over time, they will become familiar with the basic techniques, and then begin to experiment or innovate with them.
Is one of these approaches better than the other?
The Pottery Class and Doing versus Studying
In my MBA program fifteen years ago, business school founder Gifford Pinchot told a story during a talk about innovation. It turns out that the oft-repeated story comes from Art & Fear: Observations On the Perils (and Rewards) of Artmaking:
A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pounds of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
This idea, that learning by doing beats learning by studying, is one of the core principles behind modern startup approaches, agile software, and even how writing is taught to young children.
I suspect it’s true for learning software development too.
One way surface learning helps is by prioritizing which areas get focus. If there are ten topics to learn about, the deep learner who needs to understand everything in great detail spends an equal amount of time on all ten topics. But some of these may be relatively unimportant topics that don’t require deep knowledge, or topics that are used consistently in the same way such that there’s little value to having deep knowledge about them.
By comparison, the surface learner picks up techniques from many different areas, and naturally spends more time in those areas that are used more often or have greater complexity. So they might use seven topics without ever diving deep into them, while mastering the other three topics to great depth. This approach is similar to the efficiency gain of lazy evaluation: Don’t do work you don’t need to do.
In addition, the surface learner gains exposure to techniques they aren’t aware of, because each new Google search will bring up new ways to solve problems. But the deep learner, once they believe they know how to solve a problem, may gravitate toward using the same solution over and over.
Finally, the surface learner is training themselves to become experts at scanning and pattern matching to find solutions. I might open a half dozen pages, scan all of them for a couple of seconds each, before settling on one or two to look at in more detail. Within half a minute, I’ve picked a solution. This can be disconcerting to deep learners, who want to fully grok each solution.
New Developers
A quick aside: This doesn’t mean we can just throw brand new engineers into the shark tank of development. Developers who are new to a language should learn on a scratch pet project, rather than real-world code. This might seem at odds with what I’ve written, because it appears to emphasize learning over doing. But the problem is that real-world projects are often so complex that every other line of code is an exception to the rule. “Well, normally we would do X, but because of really complex reasons, we have to do Y and Z.” Every line of code becomes a puzzle that must be studied to be understood.
Experienced developers who are familiar with the intricacies of the code will have internalized and abstracted away these exceptions in their own mental model of the software, but new developers only see all the complexity. New developers need to be able to do at their own level. That means giving them projects they are capable of contributing to.
Conclusion
In summary, surface learning and deep learning both have benefits. Since there are many different learning modalities and styles, we can’t say that one is always better, or that all people should use one approach. But people who gravitate toward deep learning could benefit from trying more surface learning techniques, and incorporating what works for them.
Even if surface learning isn’t appropriate to you, hopefully this gives some perspective on how surface learners work. Although we might appear lazy and lacking interest in how things work, the reality is that we’ve just shifted that learning to a different part of our process.
P.S. I’m certain I’ve overlooked benefits to deep learning, and welcome comments or rebuttal posts that explore the deep learning approach. -- Will
William Hertling is a Ruby on Rails developer at HP working on 3D printing software. By night, he’s the best-selling author of five techothrillers, including Kill Process and Avogadro Corp. His work has been called “chilling and compelling” by Wired, and a “must read” by Brad Feld, managing director at Foundry Group.