> What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()?

depends on what the function does, most likely the best decomposition into functions isn't simply splitting the function in to n sequential parts

> I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing.

one thing usually consists of multiple other things

imho length should correlate negatively with cyclomatic complexity - it's ok if you write 300 locs if all you do is fill a map with trivial entries

There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible.

I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.