How does one “read the docs?”. Sometimes I ask how a senior dev figured something out, and they say “I read the documentation and it explained it.” And I’m like “okay, duh. but… there’s so much fucking documentation. I can’t possibly be expected to read it all?”
I have a pet hypothesis that there is some skill or ability like this which comprises a huge amount of variation in programming ability. Here is an experience I had many times while working with my professional programmer colleagues:
My coworker has a confusing bug and asks me to walk over and take a look at it.
They start trying to explain the bug from their perspective while clicking around doing stuff like building the program or paging through the code.
While they do that, I am reading everything on their screen while they talk, so then I notice some random thing in their codebase that doesn’t make sense to me and point out that thing, which is something they hadn’t realized, and that solves the bug.
Alternately:
I ask some question about the bug that involves figuring out how something works.
They put some search query into Google and it opens up a bunch of search results. They take about three seconds and click one of them that doesn’t look very useful to me. I say, “why don’t you go look at the sixth result which said it was a forum post from a person wondering the exact same thing?” They just didn’t read it.
Alternately:
They run the program and it starts producing about half a page of startup log output per second.
I interrupt them and say “why did it say X?” They say “where did it say that?” I say “about two pages up in the log.” One minute later, they have found the thing in the log that I read while the log was scrolling at half a page per second.
So there is some large difference in reading ability here that seems to be doing a huge amount of work, and I actually have no clue how I would even operate if I didn’t have that ability. It seems to me like I would just never know what was going on.
Sounds like pattern matching from training on many years worth of examples of what is “normal in similar situations” to filter that out when looking for surprising stuff—sometimes called “experience” and other times called “a fresh pair of eyes”… Or did you have this reading ability from the first day when you started to learn your first programming language / it never happens the other way round that you click on stuff for an hour and have to ask a colleague to come over and they would point out something in your blind spot?
I learned to program young enough that I don’t really remember the process, and I have about 25 years of experience, so I agree with the diagnosis.
I can certainly have a blind spot about logical reasoning related to a program, but I don’t recall having a “it says it right there” kind of blind spot.
I’ve had many similar experiences. Not confident, but I suspect a big part of this skill, at least for me, is something like “bucketing”—it’s easy to pick out the important line from a screen-full of console logs if I’m familiar with the 20[1] different types of console logs I expect to see in a given context and know that I can safely ignore almost all of them as either being console spam or irrelevant to the current issue. If you don’t have that basically-instant recognition, which must necessarily be faster than “reading speed”, the log output might as well be a black hole.
Becoming familiar with those 20 different types of console logs is some combination of general domain experience, project-specific experience, and native learning speed (for this kind of pattern matching).
Similar effect when reading code, and I suspect why some people care what seems like disproportionately much about coding standards/style/convention—if your codebase doesn’t follow a consistent style/set of conventions, you can end up paying a pretty large penalty by absence of that speedup.
I’m a mid debugger but I think I’m pretty good at skimming, with some insight into how I do it.
Have you ever searched a large bucket of legos looking for a specific piece? When I was a kid, I noticed that as I brushed the visual of the bucket with my attention, with the intent of looking for a specific piece, my attention would ‘catch’ on certain pieces. And usually, even when it wasn’t a hit, there was a clear reason why it made sense for my attention to catch there.
When I skim, it’s quite a similar process. I have an intention firmly in mind of what sort of thing I’m interested in. I then quickly brush the pages of text with my eyes, feeling for any sort of catch on my attention. And then glance to see if it feels relevant, and if not continue. With large documents, there’s a sort of intuitive thing I’ve learned where I’ll skip several pages or even sections if the current section is too “boring” (i.e. not enough catches), or parts where my intent subtly shifts (often followed by reversing direction of skim), in ways that make the process more efficient.
If you don’t have an intuitive handle for this ‘catch’ feeling already, try noticing the physical sensation of a saccade. If you can’t get any sort of semantic content from moving your eyes this quickly across text, try practicing speedreading?
(Incidentally, this attention catch feeling seems to be the same thing (or closely related to the thing) that Buddhists call an “attachment”?? Not sure what to do with that, but thought it was interesting.)
It’s subconscious so it’s hard to say but it’s clearly not “reading every word in order” and probably doesn’t involve reading every word. I think it’s a combination of being a fast but not exceptionally fast reader, plus a lot of domain knowledge so I can understand the stuff I am reading as fast as I read it, plus a ton of domain-specific skimming skill / pattern recognition to bring the interesting part to conscious attention.
Super interesting! I have some follow-up thoughts to this.
On the one hand, it seems that this is a case of “having” more working memory.
On the other hand, it might be a case of more experience allowing you to filter out irrelevant things and, allowing more working memory to focus on the things that matter.
A classical example of the latter point is when novices learn to play chess. In a typical training session, they will be presented with a position, and be asked to propose a move. They will take a moment, then propose a move that loses a queen in a totally obvious way, and when challenged, they will take a moment and confirm that “oh, yeah, that loses a queen”. Typically a novice is overwhelmed by the details of the position, perhaps still remembering how the pieces move, and have no sense of which moves are important and which moves should be ignored. As a result, they can’t do “basic” one-step lookahead to see what countermoves the opponent has. Their working memory is too overloaded with all of the possibilities on the board.
This gets resolved with practice, drills, and experience. Eventually the hind-brain simply “surfaces” the information “that square is controlled by an enemy bishop”, and in many cases will not even suggest the move that would hazard the queen, it won’t even get loaded into conscious attention.
EDIT: Building on this, it’s super interesting to watch Grandmasters like Hikaru Nakamura play games live on stream, and comment on their thought process. Yes, they calculate long lines, sometimes branching, but as they talk, partially distracted, they never consider bad moves, they’re always analyzing the top moves recommended by the computer.
One of the most useful things I did as a junior dev was to literally read the entire language spec for javascript. Searching for articles that explained anything I didn’t understand. I think this strategy of actually trying to read all the docs the way you’d read a textbook is underrated for tools you are going to be using often.
A relevant-feeling quotation from off at an angle, from Eric Raymond’s version of the Jargon File, section “Personality Characteristics”:
Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of ‘meaningless’ detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains. [During the production of the first book version of this document, for example, I learned most of the rather complex typesetting language TeX over about four working days, mainly by inhaling Knuth’s 477-page manual. My editor’s flabbergasted reaction to this genuinely surprised me, because years of associating with hackers have conditioned me to consider such performances routine and to be expected. —ESR]
I have a pet hypothesis that there is some skill or ability like this which comprises a huge amount of variation in programming ability. Here is an experience I had many times while working with my professional programmer colleagues:
My coworker has a confusing bug and asks me to walk over and take a look at it.
They start trying to explain the bug from their perspective while clicking around doing stuff like building the program or paging through the code.
While they do that, I am reading everything on their screen while they talk, so then I notice some random thing in their codebase that doesn’t make sense to me and point out that thing, which is something they hadn’t realized, and that solves the bug.
Alternately:
I ask some question about the bug that involves figuring out how something works.
They put some search query into Google and it opens up a bunch of search results. They take about three seconds and click one of them that doesn’t look very useful to me. I say, “why don’t you go look at the sixth result which said it was a forum post from a person wondering the exact same thing?” They just didn’t read it.
Alternately:
They run the program and it starts producing about half a page of startup log output per second.
I interrupt them and say “why did it say X?” They say “where did it say that?” I say “about two pages up in the log.” One minute later, they have found the thing in the log that I read while the log was scrolling at half a page per second.
So there is some large difference in reading ability here that seems to be doing a huge amount of work, and I actually have no clue how I would even operate if I didn’t have that ability. It seems to me like I would just never know what was going on.
Sounds like pattern matching from training on many years worth of examples of what is “normal in similar situations” to filter that out when looking for surprising stuff—sometimes called “experience” and other times called “a fresh pair of eyes”… Or did you have this reading ability from the first day when you started to learn your first programming language / it never happens the other way round that you click on stuff for an hour and have to ask a colleague to come over and they would point out something in your blind spot?
I learned to program young enough that I don’t really remember the process, and I have about 25 years of experience, so I agree with the diagnosis.
I can certainly have a blind spot about logical reasoning related to a program, but I don’t recall having a “it says it right there” kind of blind spot.
I’ve had many similar experiences. Not confident, but I suspect a big part of this skill, at least for me, is something like “bucketing”—it’s easy to pick out the important line from a screen-full of console logs if I’m familiar with the 20[1] different types of console logs I expect to see in a given context and know that I can safely ignore almost all of them as either being console spam or irrelevant to the current issue. If you don’t have that basically-instant recognition, which must necessarily be faster than “reading speed”, the log output might as well be a black hole.
Becoming familiar with those 20 different types of console logs is some combination of general domain experience, project-specific experience, and native learning speed (for this kind of pattern matching).
Similar effect when reading code, and I suspect why some people care what seems like disproportionately much about coding standards/style/convention—if your codebase doesn’t follow a consistent style/set of conventions, you can end up paying a pretty large penalty by absence of that speedup.
Made up number
I would describe myself as an expert-level debugger (which you sound like also), and all of this is describing experiences I have also had.
Do you literally read all the text on the screen, or do you have a way of efficiently skimming?
I’m a mid debugger but I think I’m pretty good at skimming, with some insight into how I do it.
Have you ever searched a large bucket of legos looking for a specific piece? When I was a kid, I noticed that as I brushed the visual of the bucket with my attention, with the intent of looking for a specific piece, my attention would ‘catch’ on certain pieces. And usually, even when it wasn’t a hit, there was a clear reason why it made sense for my attention to catch there.
When I skim, it’s quite a similar process. I have an intention firmly in mind of what sort of thing I’m interested in. I then quickly brush the pages of text with my eyes, feeling for any sort of catch on my attention. And then glance to see if it feels relevant, and if not continue. With large documents, there’s a sort of intuitive thing I’ve learned where I’ll skip several pages or even sections if the current section is too “boring” (i.e. not enough catches), or parts where my intent subtly shifts (often followed by reversing direction of skim), in ways that make the process more efficient.
If you don’t have an intuitive handle for this ‘catch’ feeling already, try noticing the physical sensation of a saccade. If you can’t get any sort of semantic content from moving your eyes this quickly across text, try practicing speedreading?
(Incidentally, this attention catch feeling seems to be the same thing (or closely related to the thing) that Buddhists call an “attachment”?? Not sure what to do with that, but thought it was interesting.)
It’s subconscious so it’s hard to say but it’s clearly not “reading every word in order” and probably doesn’t involve reading every word. I think it’s a combination of being a fast but not exceptionally fast reader, plus a lot of domain knowledge so I can understand the stuff I am reading as fast as I read it, plus a ton of domain-specific skimming skill / pattern recognition to bring the interesting part to conscious attention.
Super interesting! I have some follow-up thoughts to this.
On the one hand, it seems that this is a case of “having” more working memory.
On the other hand, it might be a case of more experience allowing you to filter out irrelevant things and, allowing more working memory to focus on the things that matter.
A classical example of the latter point is when novices learn to play chess. In a typical training session, they will be presented with a position, and be asked to propose a move. They will take a moment, then propose a move that loses a queen in a totally obvious way, and when challenged, they will take a moment and confirm that “oh, yeah, that loses a queen”. Typically a novice is overwhelmed by the details of the position, perhaps still remembering how the pieces move, and have no sense of which moves are important and which moves should be ignored. As a result, they can’t do “basic” one-step lookahead to see what countermoves the opponent has. Their working memory is too overloaded with all of the possibilities on the board.
This gets resolved with practice, drills, and experience. Eventually the hind-brain simply “surfaces” the information “that square is controlled by an enemy bishop”, and in many cases will not even suggest the move that would hazard the queen, it won’t even get loaded into conscious attention.
EDIT: Building on this, it’s super interesting to watch Grandmasters like Hikaru Nakamura play games live on stream, and comment on their thought process. Yes, they calculate long lines, sometimes branching, but as they talk, partially distracted, they never consider bad moves, they’re always analyzing the top moves recommended by the computer.
One of the most useful things I did as a junior dev was to literally read the entire language spec for javascript. Searching for articles that explained anything I didn’t understand. I think this strategy of actually trying to read all the docs the way you’d read a textbook is underrated for tools you are going to be using often.
A relevant-feeling quotation from off at an angle, from Eric Raymond’s version of the Jargon File, section “Personality Characteristics”: