I struck a nerve with yesterday's post among some readers. To be fair, there wasn't much nuance in my argument.
Yesterday, I said that running & tweaking the code is usually more effective than reading the code.
But that assumes you run the code in a curious way & follow what your different tests are doing as they move through the logic.
Running the code is a great way to learn how the code works, but only if you couple it with breakpoints, debug logs, and testing expected outcomes.
When you read the code, you're trying to keep a picture in your mind of what it will do. When you run the code, that picture builds iteratively. You see in real time what the values are.
But obviously, there's room in the middle. You can mindlessly run the code until it spits out the thing you want & never learn anything about how it works.
You can also spend all day reading the code but still not know where your bug is or what you need to change.
Certainly, if you want to understand the code you'll need both - running and reading. But I still think running is more important.
Many developers spend a lot of time reading code, when a few simple test runs would quickly demonstrate how it works.
There's a dichotomy I've noticed among developers.
When a test is failing or something is going wrong, some developers prefer to read the code to try to figure out what's happening.
Other developers prefer to change something & run the code again to figure out how it works.
In my personal experience, I find that the "runners" are much more effective than the "readers."