4 ms·

The article goes into detail on how to do this, but is very sparse on why. > You’ll learn something every time you do this. Learn what? Reading through code

The article goes into detail on how to do this, but is very sparse on why. > You’ll learn something every time you do this. Learn what? Reading through code to ensure that variables and functions have the best possible name is a great value-add but I remain unconvinced that you need to print out code to achieve this.

jboles 8y ago
It’s probably not necessary to print it out, but it’s a great way to establish the discipline for doing it in an IDE/editor. A company I used to work at did code reviews this way, we printing out pages of code and go through it in a meeting room with multiple reviewers. It could be overkill for binary deliverables, but when the deliverables included source code it really forced you to focus on it, having no other distractions. In an IDE you’d go-to-definition on a symbol, maybe get distracted, start reviewing some other file, a refactor here or there, and before you know it you’re down a rabbit hole and have lost context on what you were initially reviewing. On paper you have to mark it to come back to later, and continue the rest of the review.
KeepFlying 8y ago
Agreed. This really just sounded like a "Look at this new tool I found" type of article. Which is great, but I was disappointed that he didn't go over bugs that he found with this method and more specific value-adds that this helps provide. I do think there is merit to looking at code outside of an IDE (for the sake of keeping yourself focused on the task at hand), but that's what a typical code review provides. Maybe a process like this is good for looking at "bad" code and theorizing how to improve it. But even then a lot of my problems span multiple files and multiple modules (and I don't suspect I am alone in this) so it seems inefficient to print all of that out.
fpalmans 8y ago
I only print out code and read it when hunting for an elusive bug. This is a last resort effort and often successful. Also, going through big blocks of code on paper in stead of a screen is easier on the eyes.

jboles 8y ago

It’s probably not necessary to print it out, but it’s a great way to establish the discipline for doing it in an IDE/editor. A company I used to work at did code reviews this way, we printing out pages of code and go through it in a meeting room with multiple reviewers. It could be overkill for binary deliverables, but when the deliverables included source code it really forced you to focus on it, having no other distractions. In an IDE you’d go-to-definition on a symbol, maybe get distracted, start reviewing some other file, a refactor here or there, and before you know it you’re down a rabbit hole and have lost context on what you were initially reviewing. On paper you have to mark it to come back to later, and continue the rest of the review.

KeepFlying 8y ago

Agreed. This really just sounded like a "Look at this new tool I found" type of article. Which is great, but I was disappointed that he didn't go over bugs that he found with this method and more specific value-adds that this helps provide. I do think there is merit to looking at code outside of an IDE (for the sake of keeping yourself focused on the task at hand), but that's what a typical code review provides. Maybe a process like this is good for looking at "bad" code and theorizing how to improve it. But even then a lot of my problems span multiple files and multiple modules (and I don't suspect I am alone in this) so it seems inefficient to print all of that out.

fpalmans 8y ago

I only print out code and read it when hunting for an elusive bug. This is a last resort effort and often successful. Also, going through big blocks of code on paper in stead of a screen is easier on the eyes.