A lot of programs, or critical parts of them, are really just state machines. A concept exercised especially in freshman/sophomore CS and EE courses. If you understand them well enough, you can make implicit, ad hoc state machines explicit. This leads to much cleaner and more maintainable code. This is an ad hoc state machine not far from what I've seen in real code:

  ok_to_change = var1 && !var2 && var3 < 10;
  if(ok_to_change && ...) ...
  else if(ok_to_change && ...) ...
  else if(!ok_to_change && ...) ...
  ...

ok_to_change was added after someone realized how much redundancy was in the tests. But the whole thing was a state machine and could've been expressed better as such. There are lots of ways to do it. You could make a more explicit state variable (or function that returns the current state from a set of variables), use lookup tables, or have functions that call each other to represent the current state of the system (mutual recursion is nice). But by making it an explicit part of the system design it usually leads to clearer, more concise, and more consistent code (IME).

A state machine is more about modelling and restricting the transitions between states of your program. This is a great way to make complex algorithms tractable and less bug prone.