Learning by Listing
counting the tigers in the tall grass
Asking the right questions is hard when you’re trying to explore a complex topic for the first time. There’s no way to know what you don’t know. But there are ways to improve the odds of discovering what you don’t know. This post is about one of my favorites: making lists.
A conversational pattern
When I’m learning something new, I often have a conversation that follows a particular pattern:
Me: I’m new. How does this thing work?
Expert: <simple and seemingly comprehensive explanation>
Me: Thanks! But I’ve noticed <edge case>, which seems to break with that explanation.
Expert: Oh, well that can happen because of <concept that is new to me and was never mentioned in their simple explanation>.
The trouble is that people asking questions have a hard time knowing whether they’ve gotten an answer encompassing every relevant detail, and busy experts have a hard time knowing whether they are over-explaining.
An example
Here’s a more specific example of that conversation:
New hire: How does my computer know which server is google.com?
Expert: DNS! It’s a service on the internet that tells computers which IP address goes to which server name.
New hire: Cool! But we had this lab at school that didn’t have internet access, and when I was using it I could talk to other computers in the lab with names like LAB-PC-1. So if DNS is on the internet then how does that work?
Expert: Oh, well that’s probably NetBIOS name resolution, which is an old protocol for smaller networks that does the same job as DNS but in a different way.
rumsfeld_matrix.gif
This is an issue of unknown unknowns. The new hire is new to the subject, so they have no way of knowing whether a given explanation is comprehensive, or if they’re even asking the right questions. And experts don’t want to burden new people with unnecessary detail, so they will try to summarize. Therefore new people will often get explanations that cover 80% of the subject matter but leave out details that could help them know the remaining 20% exists.
If the new hire never noticed the edge case with their school’s computer lab, they could spend months or years not knowing about NetBIOS. They would get confused whenever they encountered its behavior. And the expert didn’t mention hosts files or locally-hosted DNS servers, which are even more important to know about!
Learning is hard, what do?
I think there are two ways people get past this problem on their own.
First, the accidental way. You go about your business and bump into edge cases. You ask experts about the edge cases, one at a time. After you do this for however many years, maybe you have bumped into all of the edge cases there are to bump into, and maybe you feel confident that you know everything there is to know.
Second, the fast way. You start by finding sources of truth. You use them to enumerate the moving parts in the system you’re trying to learn about. Then you ask experts to explain how each part works.
Textbooks (or, you should read the Network+ book)
I love textbooks because they put you on track to learn the fast way. Textbook authors have the time, space, and motivation to be comprehensive. Textbooks tend to be much better for initial discovery than most other methods. Even if you only read the table of contents, that alone can be worth the investment in buying the book, if it gives you a list of all the puzzle pieces you need to put together. Let’s consider a different way our example could have played out.
New hire: How does my computer know which server is google.com? Can you recommend any good textbooks about it?
Expert: DNS! Here, take my copy of the Network+ book. There’s a chapter on this.
New hire: I just skimmed the table of contents. The DNS chapter also talks about NetBIOS and hosts files. What’s the deal with those?
Expert: Those are other ways a computer can figure out which name resolves to which IP address. I didn’t mention them earlier because they aren’t relevant to what our team does on a day-to-day basis. But they can still come into play if you have to diagnose weird behavior.
The difference is that the new hire, using the textbook, proactively found a list of the ways their computer might resolve a name to an IP address. Even though they still have no idea how any of it works, they can start asking the right questions.
Tools (or, show me how to use a metal detector)
Sometimes textbooks aren’t appropriate; this is often the case when you are trying to discover real-world objects rather than abstract concepts. In these situations, you can often get better answers from experts by asking them to give you a tool that will list all of the moving parts, rather than asking them for the moving parts directly.
New hire: What are all of the servers we are running on this network? (accidentally fails to clarify that they’re asking about all servers, not just their own team’s servers)
Expert: Oh, just clusters supporting Service A and Service B. (accidentally omits the hosts a different team is running on the same network)
vs.
New hire: What’s a tool or method I could use to find all of the hosts on this network?
Expert: You could ping sweep it with nmap, or you could query the company’s Active Directory for everyone’s hosts and filter by IP prefix. (either of these methods will probably list the other team’s hosts, and the new hire will then be able to ask about them)
Limitations and surprises
Sometimes this method of learning isn’t practical. If you’re trying to learn the command line, you might start by asking how you can list every shell command your computer knows. On my Mac, compgen -c lists 3,989 different commands. There is no way I’m going to learn every command in that list. But it’s still a valuable exploration of the problem space, because now I know it’s a waste of time to try to comprehensively learn all of those commands.
When I first started learning to code, I thought of built-in functions as an uncountably large set of magic spells that wizards would pull out of their hats in StackOverflow comment sections. But sometimes you can be surprised at how small a list is. Python only has 71 built-ins, which is not a large number of things to memorize. When I was six years old I had memorized the names, types, and movesets of all 151 original Pokemon. So I view learning Python’s built-ins as a reasonable goal, if I want to get better at Python.
Tactics for learning faster
When you’re trying to learn something new, assume that individual experts will over-summarize or forget details during conversations. Try to find the boundaries of the problem space by enumerating its components. Read textbooks, or at least their tables of contents. Shed light on unknown unknowns by asking experts how they would discover what is in the problem space, not just what they think is in the problem space.