I was pondering on why Control flow is named as it is when I realized that "control" is part of the phrase. Most programmers agree on the common definition, which is the order in which the computer executes instructions. However, I find the word "control" is interesting because there's one intrinsic meaning behind it. The chance of writing the control flow itself means being in control and vice versa.
As an example, when a program runs on your device, you practically hand over control over a small slice of memory and CPU time of your device to the program, and by proxy, to the past version of the programmer. Within that small slice of space and time, the program has control over everything.
Modular programming makes it easy for programmers to categorize and separate parts of their program into modules, functions, or structs. Later, it promotes code reuse and sharing. Now it is part of the programming culture to the point that third-party code can make up more than 50% of a program's source code.
Typically, during a function call, the caller waits until the function returns a value. But notice that it also returns control. Also, there's a chance that a function can just run perpetually. You can only trust that it will return before calling it.
Remember that modular programming serves as a responsibility delegation. Control passing is only the side effect of the categorization and separation techniques, not its end goal. The need to trust is the cost.
On a bigger scale, this responsibility delegation can take different forms e.g. transaction, hierarchical organization, or b2b. Let's take an example where a company provides a service to do another's bidding. The delegator buys a service from the delegatee. The bigger the delegated responsibility, the more control is lost. This happens naturally for the same reason that micromanaging the delegatee rarely works.
Paradoxically, the more impactful the responsibility, the less desirable the total loss of control over it. To keep the delegatee in check, there should be strategically put control take-back. The skill to do this is a form of art. Too much control in the wrong place makes it hard for the delegatee to work. Too little control risks the delegatee to arrive at a completely different result from the desired one. Look back into how the programmer of modern programs does not have the most control; despite that, their little but strategically placed control is enough to maintain the quality of the whole program.
Different problem domain involves different resource control management. Time and space are only fundamental in programming. In the real world, many different resources need to be paid attention to, for example, materials resources, use of force, and contracts. Control of these items is interchangeable, yet must be done in a balanced way. For example, a disagreement happens during the trade of food, a form of material resources; one party breaches the contract which turns the deal into a lawsuit; a guilty verdict is reached, but the losing party manages to avoid paying the fine or doing time in the prison because it turns out to have stronger physical force and influence than the authority does.
Feeling free lies in having control, but also the absence of forces that keep one from exercising it. Many developers complain about code being too smart. I argue that that is not about smartness at all because there's one outstanding symptom for the opposite: people love GPT, one of the most complex and opaque computation constructs at present. Pay attention! The real enemy is the lack of control over complex constructs, not the complexity itself.
Freedom is a double-edged sword. Without rules, "You can do whatever you want, but if I don't like it I'm free to do whatever I can stop you". This conflict-rich configuration eventually settles into a more civilized one by imposing limits to everyone's control, often involving an authority. Reduced control can mean the reverse of freedom.
Back to programming, most third-party libraries expose a limited computation surface, a reduced version of the available features by the device and platforms. Its primary goal is to keep programmers focused on the problem. Its other goal however is to guard them from making errors. This is a freedom from errors, a negative liberty that prevents one from misdirecting their energy toward a false goal.
As a side point, negative liberties such as freedom from errors and distractions can be valuable despite sometimes not being seen as one because it tends to come with the absence of options or matter.
Last, while control is about changing things, the exercise of one is triggered mostly externally. A supplier fixes a product because the consumer complains about it; a camera operator stops recording because the director says cut; phones are plugged in after begging the owner that it is out of juice. Optimize for obvious signals and signs because those are as important as control itself.