I also don't have a CS degree and am self-taught. And I very much agree with you that many CS concepts have quite a practical impact. Some of them more on the side of approach and selecting the right tech/solution, but some have a more hands-on practical use.

- State machines: completely agree. I use them especially in the context of user facing stuff, like GUIs, animations and so on. In fact I would even argue that they are _inherent_: Even if you don't recognize and specifically structure your code around them, they are still _there_ just smeared all over your logic.

- A&D I find ubiquitous are: sets, graphs, trees. Sets especially are underused and graphs are the most expressive data structures if you need them and can help you model complex, long lasting models.

- Relational algebra is likely one of the most important concepts. It is fundamental to the Swiss army knife of databases: SQL.

- Algorithmic complexity: I rarely use this formally, but it really helps to get a decent intuition for performance.

> Relational algebra

Seriously? Currently working through my second databases course, I still can't help translating all of the relational algebra nonsense into proto-SQL in order to make sense of it. I was already working on large-ish business applications and databases for a few years before the first course and I didn't even know RA existed. Now it just gets in the way.

Not to mention relational expressions or whatever that thing is called where you use the "exists" and "for every" operators, which I still haven't been able to apply in practice.

Coming also from a SE/Practical background, the only time I need to use those complex expression in a SQL query, is when someone screwed up the datamodel, or over-engineered it. In theory you can do many things with SQL, but none of those things perform better than a straight up select query, which is usually what you're after-- performance.

For me the experience was different. I also knew SQL before, but after learning RA I first was slightly disappointed that SQL wasn’t as clean. But conceptually they’re the same.

I think the interesting Aha moment was the realization that SQL is syntax on top of a mathematical concept. Before I was distracted by the practice of reading and writing stuff to disk with it, if that makes sense.

> State machines

Probably one of the most powerful tool out here. You can catch a lot of things simply by identifying which state transitions should be possible and which shouldn't exist

Can you please describe when you had to use formal queueing theory in your work?

I have struggled - and failed - to find a use case relevant to daily SWE work, since (a) the probability distribution for most customers waiting in a queue is not known and must be "guessed" or predicted ahead of time using historical data and (b) nearly all queue requirements are simple (i.e. minimize total waiting time) and the solutions just as simple (scale up your queue consumers!)

Mostly simple things: if you have a messaging queue used for logging, and you need to predict the change in its memory footprint given some change in a message format before rolling out/testing the format change, just use Little's law. Or you need to determine the smallest number of consumers that you can have online safely to maximize how quickly you can do maintenance without degrading logging.

You might think that something as simple as Little's Law is intuitive, but people who haven't learned it don't always find its conclusions obvious, and they are less likely to see when a problem can be framed as a queueing problem. The value is really in simple stuff like this, where having something in your mental toolkit makes the difference between a problem requiring a trivial application of something you know versus requiring thought and creativity.

A particular example I remember was a poorly architected system that was essentially two systems connected like queues in sequence. The first one was fast and lightweight, basically a gateway/hydrator for the second one, and could handle a very large backup with no ill effects. The second one was very slow and fell over quickly if too many items accumulated in the queue during a load spike. An easy short-term fix to make the system stable in production was to introduce artificial slowness in the first queue to buffer load spikes and prevent backups in the second queue. Little's Law points straight to this solution, but people who didn't have queueing theory in their mental toolkit had not considered fixing the system by slowing part of it down. It looked like a big leap of imagination for them, even if they found it intuitive to understand after it was pointed out.