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

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

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.

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

Love this analogy for programming...

It also reminds me that English and Public Speaking are very important skills I picked up in college which are easily neglected in a DIY program.

What English skills did you acquire at uni? My English has always been quite good and I don't feel like formally studying English has helped me that much.

Perhaps I've just forgotten about how much I've actually learnt though.

A lot of people are not good at English, though. Especially public speaking.

Yes, definitely. That's why I'm curious about the specifics of what they learned rather than just "English".

My writing has been pretty decent since high school, but I did pick up some public speaking skills in college.

If you have great English/ Public speaking skills this isn't so important. But I know a lot of people have really mediocre communications skills.

Being on a student newspaper probably gave me some of the most valuable skills that I acquired in school.

I believe that could also be the case because of the amount of practice your colleagues could have had during college.

It's not knowing what you don't know. Sure, you can stumble into things, reinventing the wheel from time to time, but life gets a lot easier when you know what wheels are going in. I'm put in mind of Konrad Zuse finding out that Boolean algebra was a thing while he was wrestling with the mechanisms needed to make his first machines - just knowing that there was an established formalism and a calculus for binary made a huge difference in how and how quickly his work progressed. If he'd also learned about recurrence relationships, Z2 nd Z3 would probably have been Turing-complete by design rather than merely in potential restrospectively.

Practice isn't enough. Deliberate practice that pushes your boundaries with feedback is the critical part. That's much easier to get in a school, or a professional environment if you have a good mentor, which constantly pressures you to go deeper into the field and try new things than solo practice. Working on your own it's tempting to reach a level of comfort and not go further, or to reach a point where your skill level seems "good enough".