After reading a David Robinson blog post last week, I’ve been reflecting on how programmers find out what they don’t know. This is related to some common problems that new people have coming up with reproducible examples for stack overflow, or figuring out how to find information that they lack. It seems like when you’re new to a field, one of the main problems is describing the gap in your knowledge precisely enough to get a useful answer from other users or the documentation. For instance if you’ve been writing code for a little while, you can identify that some behaviour is unexpected and also precisely describe the expectation that’s not being met. These are two different skills and for new people the latter is pretty difficult because they don’t have solid enough intuition to describe their expectations precisely.
I think as people learn to program one of the main skills that they learn is how to identify their knowledge gaps, describe those gaps, and be able to tell when those gaps have been filled. My question is what are some teachable ways that you can help people develop that skill?
So far I’ve thought of four things which I’ve found personally important:
A big part of learning is to use the same terms that the community uses for those things. For instance if you’re an excel user coming to R you probably use terms like “cells” or “formulas”. You might be able to precisely describe your problem using your old vocabulary, but that doesn’t help you find the answer in the field you’re trying to learn. So finding people to help translate your old knowledge into the new language is very important.
Stepping back to find anti-patterns
Sometimes people have expectations which are based on using software in an odd way. I run across a fair number of questions where someone is trying to find out how to do some really tricky data manipulation, but what’s really going on is that they went down the wrong path a few steps earlier and turned a simple problem into a complex one. This seems to be related to people using a mental model that they’re familiar with ina environment which is built around a different mental model. So asking questions like “what are you trying to do big picture” or “how does this problem fit into the analysis” are more helpful than giving an answer to the specific problem. What you want to know is often not what you need to know.
Learning things that everybody knows but nobody writes down
I think there’s a trend that the more people have a problem the more resources there are about how to fix that problem. The result of this is that if you don’t know the thing that “everybody” in a field knows you will have a terrible time trying to figure out the problem. In my case when I was learning R I ran across lots of people saying “or in the command line …. “ but I didn’t really know what the command line is or how to get there. Recognizing when something is common but undocumented helps a lot with the frustration of not finding helpful resources.
Focus on making new mistakes. I find that beginning programmers have a tendency to try the same thing over and over rather than trying different thing and seeing if the error they’re experiencing continues. One thing I’ve learned to do is actually write down the actions I’ve tried so that I can at least make new mistakes. This is a big step towards reproducibility because even if your actions don’t make a lot of sense to you, they can really help a more experienced person understand the context of your problem.