Depth, Breadth and Learning
I’ve recently been thinking about the importance of clearly defining your approach when learning new things. The hardest part of learning something new is probably trying to start, which may largely be because once you’ve committed to the act of deciding to learn something, you next have to decide: how?
There are a lot of strategies and research related to learning new things, including things like active learning and spaced repetition. But when it comes to developing expertise, one paradigm feels particularly relevant to my recent efforts to try and improve my ability to learn. That’s Depth and Breadth.
- Depth | I’m defining as time spent learning some particular specialization or working towards solving some particular problem.
- Breadth | I’m defining as time spent learning the fundamentals of work done in some domain or understanding the set of solutions to problems in a domain.
I wrote this to sort out my thoughts, categorize my historical efforts, and hopefully hear other thoughts and approaches.
Starting Out with Breadth
When I first started out in my journey to see how you can use computers to solve problems in 2023, I approached it with the goal of developing breadth. Since my goal was so broad, there were a variety of directions I could approach it from.
I decided to designate each month to gaining knowledge in an area of software engineering I was interested in: - January: Web Development Basics - February & March: Frontend and Backend Development - April: Database Systems - May: Machine Learning. This way, I was able to get a breadth of introductory experiences by following along with tutorials and binging course lectures. As a complete beginner, this massive influx of breadth was really helpful for going from knowing nothing about all of these topics to knowing something (and in my opinion, knowing something is infinitely better than knowing nothing, because then you have stuff to work with).
Broadly continuing this pursuit of knowledge has served me well as a start to many projects, but it is insufficient alone. As I started to work on bigger projects in research and for fun in these domains, I started to get a better sense of the true importance of breadth, beyond introductory experiences in a variety of domains.
For example, one thing I learned from my experience conducting research at MIT last summer is that sometimes the most valuable thing that you can bring to a project isn’t the ability to solve an engineering problem the fastest, but the ability to think broadly and creatively bridge ideas from different areas to change how you start thinking about the problem in the first place. This was a recurring theme from my mentors who I could tell drew from a variety of previous experiences to come up with creative ideas. This view differed from my original introduction to breadth as something required to get your foot in the door.
To me, that’s the beauty of breadth: the emergent capability to contextualize a problem and develop solutions that either haven’t been thought of, or solutions that frame the problem in a new light.
Having a breadth of knowledge and valuable experiences eventually builds a unique new vantage point for you, on which it’s easier to see what should exist but doesn’t and come up with cool ideas. That said, once you can come up with those new solutions, someone usually has to do the work of implementing your awesome solutions and in practice, that person is often you.
Going Deep
How efficiently could you teach a middle schooler algebra? Identify a bug in a Python function? Diagnose a medical condition or negotiate a multi-million-dollar contract? These things don’t just benefit from a breadth of experience, but from depth in particular. Knowledge from having worked in that exact domain and deeply understood the previous solutions and approaches makes it way easier to buckle down and complete the task.
I can think of plenty of other examples where depth is useful. To give another example from MIT, picture this: I was one week into the summer had just started trying to figure out what code I’d need to write to start answering my research question. After some more talking to my mentor about beginning to code things, they decided to boot up their code editor and have us talk through some implementation details while we pair-coded some ideas. Afterwards, the 40 lines of code they wrote in about twenty minutes was the base of the entire project I implemented. They didn’t have to ask what Python libraries to use, how to frame the research question, how to scope the function, which math concepts were relevant to the potential solutions, or why approaching our goal this way was best. I don’t know for sure, but my guess is that having a depth of experience from a career answering questions like this is how they were able to get me started so quickly.
Putting in your 10,000 hours is good for mastery, but won’t automatically produce innovation unless your practice reflects that desire. However, going to the lengths to combine mastery (depth) with purposeful exploration (breadth) is definitely a winning recipe for innovation.
The Weighted Balance
Clearly, breadth and depth are both important, so you should definitely optimize for them both when improving your knowledge base, right? I think that’s true (reach out to me if you know for sure!), but in practice, it’s been nontrivial prioritizing both endeavors in my day-to-day life.
Usually, when it’s time to work on a project, that’s what I do: I work on the project and continue working on the project. Eventually, after some sweat, I’ve either successfully or unsuccessfully completed the project. Either way, the project is completed, and part of the value I’ve attained from the endeavor is that I have learned how to finish the project.
However, in that model of approaching problems, there’s no room for learning about things that are not obviously (or directly) related to the project but would still improve my approach and completion of the project. After all, there will be future projects and future problems, and I should optimize for my ability to complete those too.
In practice, I’ve tried a couple of things to find this balance:
- In 2023, when I started from a breadth-first perspective of learning about the different things you can do with computers (e.g., web development, data engineering, machine learning), I followed a lot of tutorials and courses, but made sure to include large non-tutorial projects (like this website) as cornerstones to demonstrate my understanding. This helped me work towards depth.
- When I started from a depth-first perspective this past September and made a project tracking site to catalog my progress on research projects, I made sure to keep a broader list of topics and papers I came across so that I can work on all these related topics I find in the course of my project and document my progress on these breadth-related concepts in between project work as well.
While both of these approaches to prioritizing breadth and depth of knowledge work well in theory, one thing I’ve come to realize for me is that both approaches are difficult to maintain because of context switching. Context switching is generally difficult for humans because it requires us to break focus and shift gears. I hypothesize that context switching is particularly difficult when switching from breadth-focused to depth-focused endeavors, or vice versa, as they very often seem orthogonal.
- For example, if you are focusing on completing a table for a woodworking project using traditional joinery, then why would you stop making progress to improve your knowledge of computer-aided design and laser cutting?
- If you are using a Python library for data exploration on a small dataset and have found the functions that you need for your problem, why would you next decide to research the implementation of the other functions and capabilities of the library?
It’s easy to accept that in the long-term, working towards both of these tasks is helpful, but in the short-term, switching tasks feels backwards and impractical.
For right now, my main conclusion about this topic is that you don’t need to balance depth and breadth perfectly, but attempting to include both into your learning intentionally and recognizing that they might almost always initially seem contradictory is crucial.
There are three main things [1] that I’m going to try and focus on for improving my ability to gain both a breadth and depth of knowledge, so I can (colloquially speaking) get a deeper bag and be better at pulling from it.
- Prioritize blocking out my time proportionally for breadth-focused vs. depth-focused tasks, depending on what needs to get done that day. Use rituals when task-switching to build stronger associations between the switch, so it’s easier to keep focus and the overall goal in mind.
- Get into the habit of prioritizing both breadth-focused and depth-focused tasks in my routines, making it easier by keeping a list of breadth tasks and topics most relevant to my major project. I also plan to mentally weight particular direction each session, so that I know which one I want to work towards the most at any given time.
- Keeping track of my progress and reasons for doing breadth-focused tasks (e.g., writing down why I am diverting focus from a particular project to practice some semi-related concept or read some semi-related paper in a notebook or in my codebase and how this act may be useful in the future).
[1] Most of the three actionable thoughts are inspired by suggestions from Deep Work by Cal Newport and Atomic Habits by James Clear.
That’s the end of the first article, thanks for reading! If you liked it, check back in around a month from now for a new one.
want to be notified for the next blog?