[Jtsummers]

> It's like I could spell but didn't know the first thing about grammar.

That's a great analogy and I think often missed by many people. Spelling and arithmetic seem obvious as limitations in more complex fields (where communication and mathematics are involved). No one would say: "I can spell 'journalist' so I should be the editor-in-chief of the Washington Post." or "I can add 2 and 2 so you should hire me as an electrical engineer." (certainly not once they've grown up a bit, at least)

You have to advance to grammar, geometry, algebra, and more to find success in those fields.

But with programming, many people seem to stop at the point where they can program, and don't realize how much more there is to it (or not until much later). Programming is just the spelling/arithmetic level. Being able to design systems, select between different data structures and algorithms, understanding what a state machine is and how to structure your program using that concept, etc. These are the algebra and calculus of the field.

[ZephyrBlu]

> understanding what a state machine is and how to structure your program using that concept

I don't really understand this when people say it. My first instinct is that you're talking about keeping functions as pure as possible.

The other thing I think of is simply understanding all (Or most) of the possible states in your program, which seems like common sense.

[Jtsummers]

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).

[Tarq0n]

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.