How do you decide when to split code into functions?

It's completely normal to write a first working version as one large function and refactor it afterward. In fact, doing that helps you see why an overly long function becomes difficult to understand. Split it into functions when the sections represent meaningful subtasks, make the main flow easier to read, or are likely to be reused. There aren't rigid rules, so avoid creating tiny functions that add more confusion than clarity.

A useful goal is for main to describe the overall algorithm at a high level. For example, it might call buildList(), sortList(), and printList() in sequence. Someone reading main can then understand the program without examining every implementation detail, while each helper function handles one part of the work. Functions also prevent you from copying the same logic whenever you need that operation again.

Think of functions as tools with clear inputs and outputs. For every major step, ask what data it needs and what result it produces. A function can be useful even if it is called only once when it gives a complicated section a meaningful name and keeps the surrounding code readable. Start by extracting repeated or clearly separate operations; with practice, you'll get better at spotting boundaries while designing the solution.

Your plain-English approach is solid. Once you have the steps, look for natural responsibilities such as reading input, processing it, and displaying the result. Those can often become separate functions. Repeated code is another strong signal that it belongs in a function. Each function should generally do one focused job and have a name that explains that job.