[blago]

> Proponents of small functions argue that you don't have to read more than the signature and name of a function to understand what it does;

Although this is often the case, the style of the program can change things significantly. Here are a few, not so uncommon, examples where it starts to break down:

1. When you’re crafting algorithms, you might try to keep code blocks brief, but coming up with precise, descriptive names for each 50-line snippet can be hard. Especially if the average developer might not even fully understand the textbook chapter behind it.

2. At some point you have to build higher than "removeLastElementFromArray"-type of functions. You are not going to get very far skimming domain-specific function names if don’t have any background in that area.

More examples exist, but these two illustrate the point.

[K0nserv]

Both examples stem from not understanding the problem well enough I think. My best work is done when I first write a throwaway spaghetti solution to the problem. Only through this endeavour do I understand the problem well enough to effectively decompose the solution.

[nuancebydefault]

You understand your final fine grained code after your 'spaghetti' intermezzo. Others and your future you, probably less so.