I think the author doesn't understand the small-function-philosophy (at least not the same way I do). Let me clarify how I see it: - Build a ton of small funct

I think the author doesn't understand the small-function-philosophy (at least not the same way I do). Let me clarify how I see it: - Build a ton of small functions that are reusable across any project. You are essentially making useful concepts. (i.e. a library). Bottom-up. - Once you have those, a business problem often will only be about 3 or 4 of those powerful, reusable functions. So something like sending out a newsletter might end up being: function sendNewsletter(letter) { database.getAllUserRowsAsIterator().forEach((row) => { sendmail(x.address, letter); } } Now if we want the whole newsletter not to fail if there's a single exception, we can make another reusable construct "count exceptions" that's a wrapper function that catches all exceptions and builds a hashmap. If you want this to work in a larger project, this requires having reliably unit-tested code and doc-blocks so that other people can reuse your abstractions, and then having roughly comparable coding skill to you.