4 ms·

Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more

Most advice about programming is about writing code, but we rarely ever consciously consider how to improve at reading code. One way to do that is to read more code. If you read really good code, and I mean really read it, like a book, and absorb it, then you will improve so much. This kind of improvement is the most impactful, because you also spend most of your time as a programmer reading code than writing new code. Also, if you become good at reading code, then you don't need documentation.

sanderjd 3y ago
Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better, but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer.
- asimpletune 3y ago
  It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.
  - sanderjd 3y ago
    > it's limited in that you can't bring it all the places that you can bring your eyes. Why can't you? > Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can. This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in the first place, as this mismatch about assumed vs. actual runtime state is where most bugs emerge.
    - asimpletune 3y ago
      > Why can't you? Honestly not trying to be rude, but that would be because of how eyes work. The moment you do anything that goes beyond looking at code, is the moment you've met that limitation I described above. The other part you brought is totally valid, it's just all about tradeoffs. If you prefer using a debugger in situations where I would read the code, then more power to you. Actually, it's funny, because the original article talked about the One True Way (or whatever his exact wording was), and how we all go through a phase where we discover that for ourselves. I think this thread in a way has been an expression of that concept. Anyways, thanks for your thoughts, I'll remember this next time I'm struggling with the ol' brain debugger ;-)
      - sanderjd 3y ago
        What do you mean by "because of how eyes work"? When using a debugger, one's eyes mostly remain on the code... I feel like I must just be truly missing what you're trying to say here. I like your call-out of the "one true way" section. What I was thinking in that section is that my experience, having now traversed a number of "one true ways", is that: 1. Very nearly all tools and techniques are truly useful in some way in some circumstance, and 2. Not all "one true ways" are created equal; some tools and techniques are more useful than others and better stand the test of time. In my view, using a debugger to understand the runtime state while reading and exercising code (especially when it is unfamiliar) is one of those techniques that is broadly useful and never out of date. But that's not a totalizing view, it isn't the "one true way", obviously nobody only reads code while running it within a debugger, nor should they! But dismissing its utility for this use case of understanding code more deeply is, in my view, just odd.
- yowlingcat 3y ago
  > but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer. That's kind of the problem and why it's a crutch. If you get better at reading code and reasoning about it without needing to use a debugger, it'll make you even more productive for when you actually do need to reach for it. The opposite is not true. Being able to read code deeply in the setting of code review and point out structural issues without needing to execute that code or strap on a debugger is an enormous superpower, and one of the biggest skills that differentiates an early-career or mid-level engineer from a senior engineer in those that I've hired and managed. Over time, you do a lot more reading code than writing it if your codebase does its job successfully.
  - sanderjd 3y ago
    I don't think it's possible to put too fine a point on this because it seems to be a weirdly and stupefyingly common point of view among programmers: This perspective makes absolutely no sense. This is like saying that the exercises in mathematical textbooks are a crutch because you'll never be able to read formulas if you interact with the ones in the book via the exercises given. This is the exact opposite of the case! The exercises are there to force you to "step through" the technical details in the text, to actively build intuition for the dynamics. If there were a way to spin up a math debugger to literally step through the details as you work through the exercises, that would be amazing. Educators would kill for that capability! And we already have it, essentially for free. But then out of some kind of misplaced sense of purity, tons of people have concluded that it's bad to use this incredible capability. This is just bad pedagogy. Edit to add: I feel like I didn't state this plainly enough: The way to learn things from textbooks is not to just read a bunch of different text, it is to interact with the concepts covered by texts. That's why textbooks all have exercises, and why educational institutions always ask students to do those exercises (and more). The advice to "read a lot of code" is like saying "read a lot of textbooks". But that's not good enough. You need to run the code, ask questions of it, test assumptions out; this is just like doing exercises in a textbook, and a debugger is a superpower for doing that active interrogation, while reading the text.
    - 3y ago
9029 3y ago
Where to find really good code? Open source projects that have stood the test of time?
- asimpletune 3y ago
  Usually, the best code to read is something that you already need to understand. So, if there's a library you use at work, for example. Also, for every language there's a really important project written in that language, like SQLite if you want to learn C, or finagle if you want to learn Scala.

sanderjd 3y ago

Personally, I find it to be even better to step through code using a debugger. I think just reading down the text of a set of code files like a book has pretty limited utility. (Though better than not reading code at all!) It's like reading one of those choose-your-own-adventure books from start to end. Starting from an entry point and then digging into methods from there is better, but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer.

asimpletune 3y ago
It's true that a debugger is easier to use, but it's limited in that you can't bring it all the places that you can bring your eyes. Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can.
- sanderjd 3y ago
  > it's limited in that you can't bring it all the places that you can bring your eyes. Why can't you? > Also, as one improves at reading code a develops a mental debugger that can be brought anywhere your eyes can. This is definitely true, but that "mental debugger" is susceptible to incorrect assumptions about the runtime state at the point of execution. If this weren't the case, far fewer bugs would be written in the first place, as this mismatch about assumed vs. actual runtime state is where most bugs emerge.
  - asimpletune 3y ago
    > Why can't you? Honestly not trying to be rude, but that would be because of how eyes work. The moment you do anything that goes beyond looking at code, is the moment you've met that limitation I described above. The other part you brought is totally valid, it's just all about tradeoffs. If you prefer using a debugger in situations where I would read the code, then more power to you. Actually, it's funny, because the original article talked about the One True Way (or whatever his exact wording was), and how we all go through a phase where we discover that for ourselves. I think this thread in a way has been an expression of that concept. Anyways, thanks for your thoughts, I'll remember this next time I'm struggling with the ol' brain debugger ;-)
    - sanderjd 3y ago
      What do you mean by "because of how eyes work"? When using a debugger, one's eyes mostly remain on the code... I feel like I must just be truly missing what you're trying to say here. I like your call-out of the "one true way" section. What I was thinking in that section is that my experience, having now traversed a number of "one true ways", is that: 1. Very nearly all tools and techniques are truly useful in some way in some circumstance, and 2. Not all "one true ways" are created equal; some tools and techniques are more useful than others and better stand the test of time. In my view, using a debugger to understand the runtime state while reading and exercising code (especially when it is unfamiliar) is one of those techniques that is broadly useful and never out of date. But that's not a totalizing view, it isn't the "one true way", obviously nobody only reads code while running it within a debugger, nor should they! But dismissing its utility for this use case of understanding code more deeply is, in my view, just odd.
yowlingcat 3y ago
> but being able to inspect the runtime state and get a sense for the data layout makes the experience so much richer. That's kind of the problem and why it's a crutch. If you get better at reading code and reasoning about it without needing to use a debugger, it'll make you even more productive for when you actually do need to reach for it. The opposite is not true. Being able to read code deeply in the setting of code review and point out structural issues without needing to execute that code or strap on a debugger is an enormous superpower, and one of the biggest skills that differentiates an early-career or mid-level engineer from a senior engineer in those that I've hired and managed. Over time, you do a lot more reading code than writing it if your codebase does its job successfully.
- sanderjd 3y ago
  I don't think it's possible to put too fine a point on this because it seems to be a weirdly and stupefyingly common point of view among programmers: This perspective makes absolutely no sense. This is like saying that the exercises in mathematical textbooks are a crutch because you'll never be able to read formulas if you interact with the ones in the book via the exercises given. This is the exact opposite of the case! The exercises are there to force you to "step through" the technical details in the text, to actively build intuition for the dynamics. If there were a way to spin up a math debugger to literally step through the details as you work through the exercises, that would be amazing. Educators would kill for that capability! And we already have it, essentially for free. But then out of some kind of misplaced sense of purity, tons of people have concluded that it's bad to use this incredible capability. This is just bad pedagogy. Edit to add: I feel like I didn't state this plainly enough: The way to learn things from textbooks is not to just read a bunch of different text, it is to interact with the concepts covered by texts. That's why textbooks all have exercises, and why educational institutions always ask students to do those exercises (and more). The advice to "read a lot of code" is like saying "read a lot of textbooks". But that's not good enough. You need to run the code, ask questions of it, test assumptions out; this is just like doing exercises in a textbook, and a debugger is a superpower for doing that active interrogation, while reading the text.
  - 3y ago

9029 3y ago

Where to find really good code? Open source projects that have stood the test of time?

asimpletune 3y ago
Usually, the best code to read is something that you already need to understand. So, if there's a library you use at work, for example. Also, for every language there's a really important project written in that language, like SQLite if you want to learn C, or finagle if you want to learn Scala.