> When amateurs [play tennis], they don’t edge each other out by being slightly more skillful. Instead, it’s a contest of who makes the fewest huge, gaping blunders.
I actually find this idea relevant to so many areas in life. Most of us are just about average in most of the things. It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. I feel like doing so just gives you the most bang for your buck, and therefore should often take precedence over slightly improving more general abilities (through a lot of hard work, usually).
I'm not sure how generally important this point is: perhaps it matters more for contest-style fields than more open-ended ones. The guy who can't "invert a binary tree" for his Google interview also made Homebrew.
Big nasty for loops get replaced by big nasty filter/map/reduce calls. Filter/map/reduce may be less error prone than for loops, but if it would be a big and nasty for loop, it will still be big and nasty.
Worse, "nasty" to me means more than just "what was inside the loop is large". It means that the loop itself was nasty, that is, it wasn't just a straightforward iteration over a collection, or a loop with fixed bounds. That means that it's harder to just replace it with a filter/map/reduce.
I think that for loops can be hard for beginning to intermediate programmers, but with experience, they get easier. I don't remember exactly how many times I've messed up a for loop in the last decade, but the number is either 0 or 1. It's not 2. "Once in a decade" isn't exactly the source of large-scale bugs that people often claim for loops are.
Note well, though: This is not my first decade as a programmer. The number was much higher my first decade. Filter/map/reduce may be easier to learn. You may in fact get to "one bug per decade" faster with them.
You seem to be comparing a well-written, large for-loop (that has complexities dictated by true constraints, rather than programmer skill) with a poorly written functional chain. This isn't quite fair.
The functional style nudges the programmer to think in the smallest semantic steps of transformation, in a way that the for-loop doesn't. Of course the programmer can ignore the nugde and write the same messy for-loop using functional constructs, and a good programmer can equally well write a big for-loop in a very manageable and easy to read style.
But for an unexperienced programmer seeking general advice, I feel that recommending the functional style (with an additional urge to "listen" to what the style is trying to get you to do) is a pretty safe bet.
With amateur athletes it’s a balance of both. You have to put in the hours. You can film your gait or your stroke all you want but you have to practice first.
A lot of your practice is trying to cement the last four things you learned. You put in the hours and periodically you check in about improving your technique again. If you feel stuck in a plateau it’s probably time.
> When amateurs [play tennis], they don’t edge each other out by being slightly more skillful. Instead, it’s a contest of who makes the fewest huge, gaping blunders.
I actually find this idea relevant to so many areas in life. Most of us are just about average in most of the things. It is frequent that hunting down the most critical "huge mistakes" is the easiest way to improve dramatically in a certain field. I feel like doing so just gives you the most bang for your buck, and therefore should often take precedence over slightly improving more general abilities (through a lot of hard work, usually).