How to Accelerate Your Programming Knowledge with Multiple Streams of Learning
By: Amy M Haddad
Financial gurus talk about having multiple streams of income. The idea is to have income from several sources, rather than relying on a single one. We ought to embody a similar principle when learning programming topics and building programming skills.
My recommendation is to apply an approach that I like to call “multiple streams of learning,” or MSL. It means to actively study a field or build a skill from multiple perspectives.
This is in contrast to the more common approach to learning, which I think of as a “siloed” approach to learning. It’s when you focus exclusively on a single form of learning, say a course or project, for example, and only that course or project.
MSL may seem obvious. But few people follow it. More often than not, people take the siloed approach to learning. They zero in on a single form of learning and let everything else fall to the wayside.
Some examples of familiar excuses include:
- Get feedback? There’s no time for it.
- Read technical books? Maybe sometime in the future.
- Meet with peers to discuss programming topics and ask questions? Perhaps in an ideal world.
- Read and study the code of others who’ve solved the same problem, and apply what you learn? Not now.
In this blog post I argue that MSL is the approach to use when it comes to learning and skill-building.
Multiple Streams of Learning in Action
A programmer I know is learning computer science. He’s enrolled in an online curriculum, which includes the standard lectures and assignments.
For most people, the learning would stop there. They’d focus entirely on the course, and only the course. They unconsciously opt for the siloed approach to learning.
Not this programmer. His coursework is one avenue for learning computer science—but definitely not the only one.
He spends a significant amount of time working on other related projects and problems. He and two classmates meet virtually once per week to talk about computer science topics and ask questions. He also meets virtually with a classmate to work through problems and get feedback. And, until recently, he led a reading group that discussed and analyzed technical books.
This programmer exemplifies MSL. He’s actively attacking computer science from multiple angles. This helps to foster connections, solidify concepts, and increase the learning rate.
So he’s learning the material, to be sure. But there’s something more.
He’s also seeing the field of computer science from many perspectives—the instructors, classmates, authors of technical books, and peers—instead of a single one. This plurality of viewpoints not only helps foster an open mind. But it also helps you pick up on the details: what’s overlooked or confusing in one context is made concrete in another.
This is MSL in action.
Born Out of Necessity
The idea of MSL was born out of necessity during my mid-twenties, when I decided to go to graduate school to study art history.
There was a challenge, however. I had no industry experience in the arts and, other than a few classes in college, I had very little knowledge of the field. I had a lot of work to do just to get into graduate school.
To get up to speed, I took some classes. But a significant part of my education took place outside of the classroom where I was actively engaged in the art world.
I became a docent at the local museum, where I gave tours about the museum’s art collection and current exhibitions; experienced art in the flesh (which is far better than seeing it on a slide projected on a flat wall); and learned the ins and outs of museum life.
I also became a research assistant for an art history professor. This experience helped to sharpen my researching and writing skills, and gave me an academic’s perspective of the art world. Then, there was the art history reading group, where about ten of my classmates (from the university where I took supplemental classes) engaged in intense conversations on dense theoretical texts.
Art was constantly on my mind in many different ways. As a result, my knowledge soared.
Of course, at the time, I didn’t have a name for my learning approach. I was just trying to learn as much as possible, and actively engaging in a variety of pursuits from multiple angles seemed like a way to do it.
So I continued this approach once I was enrolled in graduate school. This time I decided to launch a blog about the arts.
I took it as an opportunity to interview gallerists, curators, and artists, who were more than willing to talk and answer my questions. I attended art exhibitions by the dozens, and traveled to art studios. Then, I’d come back to my apartment and write a blog post.
Once again, my knowledge soared. This is how I learned about curating an art show and how artists work and think. It’s also how I got my start as a writer.
Fast forward a few years and I began another self-study pursuit: learning to program. You may think I began my journey with MSL.
But that’s not what happened.
Programming with Multiple Streams of Learning
I can’t explain why I didn’t begin learning to program with the approach that served me well in learning the art field. It simply escapes me.
Instead, I began my self-taught programming journey with the siloed approach to learning. It didn’t work.
Three months in, I did a complete reboot and restarted my programming journey from scratch. That’s because my first attempt was not effective, due to poor learning techniques and an inadequate learning strategy.
During round two of learning to program, I took time to learn how to learn, that way I had the strategies at hand to learn technical topics better. I also developed an overall learning strategy that involved MSL.
How to Make it a Reality
You can apply MSL to a particular field, like the programmer who’s learning computer science. You can also apply it to a concept or technology you’re trying to learn, or skill you’re trying to build.
Either way, the idea is the same: identify what you want to learn or get better at. Then, actively attack it from multiple angles.
When I first began to program, I followed the oft-cited advice for getting better at problem-solving: solve lots of problems. So I took the siloed approach toward problem-solving and only focused on solving as many problems as possible.
But repetition is only part of the story, as I came to find out. Repetition alone won’t get you there. You’ve got to be intentional about your practice, which I explain in my article about how to get better at problem-solving.
Now my problem-solving approach is multifaceted.
Undoubtedly, solving problems is essential in order to get better at problem-solving. You’ve got to do the thing you want to get better at.
But we can’t discount other forms of knowledge that can accelerate your learning, like getting feedback and studying the code of others who've solved the same problem.
MSL forces you to apply your knowledge in different ways. Solving a problem in Python and then JavaScript forces me to think differently—even if it’s the same problem. It’s a reason why I’m a huge advocate for solving math problems as well.
The challenge becomes making what are typically conceived of as passive forms of knowledge active.
Make It Active
A cornerstone of MSL is to make the streams of learning active, and for good reason: you’ll remember it better.
Take feedback, for example. I aim to get feedback in real-time (which can easily be done via video conferencing in today’s remote-working world), instead of relying on written comments from a pull request. This makes the process active.
Reading through comments is passive, whereas real-time conversations force you to be mentally engaged by thinking on the fly, asking follow-up questions, and responding to the information at hand.
Then, put what you learn into action.
I once got feedback from a programmer who said I needed to write better variable names. So I read about them in the book Code Complete, and made a “variable name” checklist. It hangs on the wall in front of my desk. Now there’s no excuse: writing variable names is constantly on my mind.
Or consider reading technical books. At first blush, this also sounds like a passive activity.
But there are ways to make it active. For one, “spot check” your learning: after you read a short section, stop and summarize to yourself what you just learned.
Another is to focus on one topic that you read about and apply it in your daily work. I type notes in Evernote for each technical book I read. To get better at writing tests, for example, I pull up my notes about test-driven development so I’m reminded to put my knowledge into action.
MSL is not a hack. It’s not a quick fix. Learning and building skills still take time and a lot of work.
But given my experience with both the siloed approach to learning and MSL, I can tell you first-hand that the latter is far superior of the two.
This is not only because MSL is more effective. But the variety also makes the learning process more enjoyable. And there’s something to be said for that. After all, learning to program isn’t a one-time thing. It’s a lifetime pursuit. Enjoy the journey.
← back to all posts