If you want developers to know about this stuff stop encouraging people to go to code bootcamps and start making SWE curricula more palatable and end this idea that college is a scam that teaches you nothing
They can easily be expressed as plain data structures of three layers that map the name of a state to possible inputs/events to the appropriate name of the subsequent state. Then you only need code / functions for each transition (from state, to state) to generate effects. This data driven pattern is very straight forward to implement and easy to reason about.
I learned it from hobby game programming, especially its application and usefulness. It comes up in lectures/books, sure, but generally people tend to vastly underestimate its applicability and instead smear state control all over their code, regardless of their education.
every example I've seen (probably toy examples from articles) felt like way too much abstraction had been applied over the problem.
This works best with languages that have first class support for data literals and maps (or equivalent), such as JS, Clojure, etc.
But if you care a ton about performance you can encode the same with say enums and switch statements or similar. It's just a bit more work and you can't change the machines on the fly or generate them from data, which is a very powerful pattern you can put on top of this. But in many cases that's not needed.
---
You first define a map of states, where each key is the name of the state and each value is a map from event names to state names.
Say you have an on off toggle (very simple example):
On => Toggle => Off
Off => Toggle => On
Where On/Off are state names and Toggle is an event name.
Then, you define a map from two states to a function. We call them transition functions. Like so:
[On Off] => func()...
[Off On] => func()...
Inside the functions you would put side-effects directly (such as activating a light or changing a color, sending an email etc.), or maybe just describe side effects so another part of your program can handle them (which can be useful with larger programs as it makes testing easier).
Lastly, you define a state machine function that runs your program like so:
func(state, event) => if event is handled: trigger transition function and return new state, else: return current state
In many cases you want to simply ignore events that aren't handled in the current state of your state machine (like described above).
Sometimes though, you want to buffer events that are currently not handled in a queue and handle them later; that's a niche use-case in order to manage async events in a specific order.
I was once chatting with a jr sw engineer that had recently graduated from a respectable state university with a CS degree about which database would be optimal for our upcoming project. He confided in me that he hadn’t taken the DB course in school because he heard bad things about the professor who taught it. I was absolutely blown away.
The moral of the story is that your shouldn’t assume that just because someone has a CS degree that they have knowledge of all the fundamental areas.
If it was the latter, then I doubt he could have answered that even if he had taken the db course at his college. And that's probably fine, I don't think the differences between specific db products counts as the sort of fundamental knowledge that should be taught at a university.
At least I know the CS degree has standards and academic rigor, with mathematics and some problem solving, which to me means they can think and adapt.
Once both groups get experience though they are pretty much the same resume wise. Then it is up to the interview process and probation period to shake them out
A non-CS grad is much less likely to have. They may not even have a concept that estimating algorithmic complexity is even possible. They may have zero understanding why a massively nested loop structure is slow.
The future of education will be the personal artificial mentor, such as GPT10+ will be able to provide, and then the question becomes: how do you generate internal motivation for the children/people to be interested in knowledge and power over nature instead of being mindlessly entertained by whatever the ad-driven feed displays.
Agreed, though. We need to stop pretending 12 weeks of JavaScript is at all equivalent to four years of rigorous theory and practice.