Got it, thanks. But it seemed from your original post that you tend to write state machines a lot more than the usual engineer does, would that be correct? Would you use this in a crud rest API for example?
When writing code, the amount of structure depends on the amount of code.
More and more complex code requires more structure.
Structure takes time and effort, so we write the minimum amount of structure which is appropriate for the code (where code often grows over time, and then by that growth becomes unmanagable, and then we need more structure, which may require a rewrite to move from the existing structure to a new, fuller structure).
So with methods for organizing code, we go something like, in order of less to more structure,
A state machine is a form of structure, separate from how we organize code, and moderately high cost. I don't often use one, because most of the code I write doesn't need to be particularly rigorous - but for example I did write a mailing list, and that really is used, so it really did have to be correct, so I wrote out the state machine and implemented based on the state machine.
State machines also help with testing. You can keep track of which states you have tested and which events from each state you have tested.
I've never written a REST API in my life, so I can't tell you if I would use a state machine for that :-)
