"Programs must be written for people to read, and only incidentally for machines to execute." - SICP
If you believe this (and I do), then it follows that reading fluently is absolutely critical. One cannot judge writing without being a good reader.
You don't learn to write novels without reading a whole lot of them first. And someone who hates to read is never going to be a great writer.
I disagree that any special tool support is needed. If you depend on any open source library or platform at all, just don't stop bug hunting at the API boundary. Go down inside and see what's really going on.
Absolutely agree with this. Starting at the base with small libraries in your language of choice and working your way up (similar to beginning with picture books and moving onto novels) is a fantastic way to both become more familiar with a coding language and also various coding styles as well.
When you come across pieces of code that may seem esoteric, doing a "rubber ducky" debug (talk through the code line by line with ann inanimate object) on it I find helps tremendously with both understanding what's going on along with the author's mental approach to the problem.
In the event they may just not be a great programmer you can still learning something from the way they approached the challenge.
Comments
"Programs must be written for people to read, and only incidentally for machines to execute." - SICP
If you believe this (and I do), then it follows that reading fluently is absolutely critical. One cannot judge writing without being a good reader.
You don't learn to write novels without reading a whole lot of them first. And someone who hates to read is never going to be a great writer.
I disagree that any special tool support is needed. If you depend on any open source library or platform at all, just don't stop bug hunting at the API boundary. Go down inside and see what's really going on.
Absolutely agree with this. Starting at the base with small libraries in your language of choice and working your way up (similar to beginning with picture books and moving onto novels) is a fantastic way to both become more familiar with a coding language and also various coding styles as well.
When you come across pieces of code that may seem esoteric, doing a "rubber ducky" debug (talk through the code line by line with ann inanimate object) on it I find helps tremendously with both understanding what's going on along with the author's mental approach to the problem.
In the event they may just not be a great programmer you can still learning something from the way they approached the challenge.
Plus one for the rubber duck analysis.
Of course anyone remote working has problems trying to do this in Starbucks.
Are you sure? Sometimes wonder if talking to inanimate objects is just standard behaviour in Starbucks...