In a program, there's a lot to optimize for - minimize depth of call stack. It's easy to lose track in a deep call stack. - minimize function overhead

In a program, there's a lot to optimize for - minimize depth of call stack. It's easy to lose track in a deep call stack. - minimize function overhead - names that have to be invented - function calls and arguments that have to be written (and read again). - many small functions: "ravioli code" where it's really hard to distinguish functions by their "function" - minimize/localize state - if it's easy to separate significant state into a function, do it. (Not making a statement about objects. They are long-lived and their state doesn't go away after the first call). - DRY - Multiple identical or similar code blocks are an opportunity to make a function. We can roughly categorize into essentially (conceptually) and accidentally similar code, and the latter case is not an indication for a new function. - obvious thread of control - simple code has the nice property that it's easy to understand by following or mapping out sequentially. By contrast, highly abstracted or callback-heavy code is hard to understand at a global level. - consistency - ... helps understanding, but can also cause an implementation to be 5 or 10 times longer if applied dogmatically. It's good to read all these articles ("avoid state", "avoid long functions", "avoid objects", "avoid functional programming", "avoid abstraction") and to deeply understand them. Which probably means making all the mistakes on one's own. In the end it's important to know in which situations a particular style works well, and to not be dogmatic when choosing a style. I would say a good program tends to have both large and small functions, and the large functions tend to be at the top of the abstraction stack.