If you've ever ended up in the unlucky position of maintaining a poorly maintained codebase, you may know why experienced programmers generally advocate for smaller units of code.
The amount of code (or design) a human being can keep in active memory is limited, thus, if a unit of code is allowed to grow until the mental limit of the average team member is exceeded, code just gets /piled/ on top of what already existed. The capacity for suffering through this is sometimes astounding and a single unit of code can spiral into thousands of lines of features piled on top of each other with no knowledge of the assumptions and patterns that were once present in the rest of the code.
Of course, the solution is to break it down into smaller units a single mind can pick up and understand.
And to create lean, non-ambiguous interfaces between these units. Internal micro APIs if you will.
The art of finding the ideal "fault lines" for interfaces within your code comes with experience.
How do you tell when a unit of code becomes too large and should be broken down?
As always, complex code metrics and analysis techniques could be consulted, but I found that a very basic metric that can easily be looked up by even the most novice programmer largely coincides with this: line count.
The sweet point for me is around 500 lines.
Of course, some languages are more terse, some are chatty, some programmer use more comments, some less, but 500 lines has proven to be a good cutoff point.