Maybe it's easy to overlook these things when you have a really deep computer science background, but coming to software engineering from a non-CS background (math degree) I found lots of valuable knowledge in CS. The most important parts for me would be:

- State machines. I run into a lot of state machines, especially incompletely specified ones. Not that everybody gets these wrong if they haven't studied state machines in a textbook and worked the exercises at the end of the chapter, but recognizing "oh, this is a state machine" gives me a mental framework, a notation, a vocabulary that other developers understand, and a better ability to understand when a problem is underspecified or inconsistent.

- Queueing theory and algorithmic complexity. These two usually come in handy from the perspective of spotting and avoiding stupid mistakes. It's true that people can do a pretty decent job from a handful of rules of thumb, but not everybody has that minimum knowledge, and sometimes a problem has a twist that an imprecise rule of thumb doesn't account for.

- Distributed systems. Just understanding the solution of a few problems in depth, and knowing from that how hard simple things really are, is incredibly valuable. Without that background, people can naively tackle extremely complex problems, bash their heads against them for years, and still underestimate the difficulty of the problems they've created for themselves by orders of magnitude.

In general, the rigor of doing theoretical problems, the discipline of actually proving things, creates habits that uncover lots of non-happy path possibilities.

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.

It sounds like you work in an industry that doesn't strictly require frequently delving into foundational theory in CS. I do believe it would be a mistake to conclude its useless, however, as there are many other industries that do need it, and people who are not in touch with the theory probably would not be competitive in those industries.

From your prespective how common are those types of roles in all industries as a whole?

There are interesting compiler roles but the vast majority who learn how to build a compiler never use it day to day work. Would you recommend spending more time building compilers to better compete for those few roles or would you recommend a different approach?

I use most of my CS skills almost daily.

I may not be writing compilers professionally, but on the surface, understanding parsing has gotten me out of more than a few tight corners. More abstractly, there are lessens to be learned in designing large applications; and appreciating the difference between a finite state machine and a deterministic turing machine, including the types of problems they can solve and how much of a pain in the ass one is to write compared to the other.

Challenges that benefit tremendously from just a bit of a dive into theory are all over the place. This has been true for me in my career as a software engineer whether I'm working at an energy company, federal research lab, tech startup, or networking services company. The key part is that it's not apparent (or apparently needed) unless you are familiar with the material.

I work in firmware, and 99.9% of the time the most exotic data structure we touch is a linked list

CS still comes in handy though, especially computer engineering to understand some of the workings of the hardware

Occasionally I'll use real CS knowledge when I'm building tools for work or working on games in my free time.

Full disclosure, I didn't actually study CS in school though.. I studied EE and then went and learned CS via Wikipedia when I needed it to find a better-paying coding job.

I have a degree in math and physics. I used it exactly once, in one aspect on one job. It was down below 0.0something% - need one or three more zeroes...

... until I took a job in X-ray imaging. We were working on a surgical X-ray (C arm) that could pinch-hit as a CT machine. And suddenly everything was 3D coordinate transforms and fourier transforms, plus X-ray physics, up to my eyeballs.

The theory stuff isn't useful... until it is. And when it is, it helps to have it.

This is true for the most part. But having the CS knowledge allows you to create much more efficient solutions once at scale.

I've personally revamped core parts of a product at previous companies to be over 1,000x more efficient just by applying some CS principles. This translates to $100K/mo+ in savings for a company that is at scale.

I have to ask though... Was it at scale?

I guess that's a relative term. But hosting bill was around $250K/mo from what I remember.

On the topic of useless subjects (on a personal level) I nominate chemistry. Never had to use it or depend on chemical knowledge, never had to write a chemical reaction or compute masses except as a student. So many years spent on chemistry instead of learning some other subject.

I also never use chemistry knowledge for anything, ever. But I find it quite interesting to know a little bit about how matter works, and how it combines into things that make up my body and (hey, let's go there) mind. I had to take an intro class in college to learn to appreciate all that, though; high school chemistry class was pretty dull and useless for me.

I find that hearing about how stuff works and how that directly relates to daily life is easy for me (and probably most people) to internalize and retain.

For example something that has stuck with me since high school was hearing that H20 expanding when it freezes into a solid is what makes ice skating possible. Pressure exerted by the skate blade forces the surface of the ice into a liquid state which makes it slippery.

Where educational curriculum tend to lose people is by overemphasizing the canon/trivia. Ironically that seems to be a result of needing to develop additional, obscure, test questions to deter students memorizing rote information or last years final exams.

In regards to computer science I think there is more to gain for students by learning the history and development of particular CS solutions and discoveries as they are more likely to encounter those situations in their careers than a particular need for a CS technique.

Play Omnifactory or any modpack with gregtech. It's not 100% realistic but you're doing practical chemistry all the time.

All this is true, but when I look at undergrad curricula for other engineering disciplines I don't see this stuff either. And the software engineering courses I did have in undergrad were terrible.

Software engineering needs to be learned on the job. I see lots of new grads that take classes in "Agile" and I cringe just knowing how instead they could be taking difficult courses in graph theory, theory of computation, abstract algebra, advanced algorithms, distributed systems, or any other number of advanced topics. As we get older it's easier to pick up tricks of the trade (various Git workflows, "agile", etc)... but it gets harder to sit down to do 3 hours of homework 4 days a week doing your pushdown automata or linear algebra exercises.

> but it gets harder to sit down to do 3 hours of homework 4 days a week doing your pushdown automata or linear algebra exercises.

38 year old studying astrodynamics for work. Can attest to the difficulty of this. No kids yet, that helps, but the wife and I are planning on starting a family soon so it'll get even harder with increased demands on my time.

I have no experience in the field and I would like to quickly get in it. I want to dive in with experience and I’m trying to figure out what things would get me there quicker if someone wanted to tutor me at work. What would you say are the things in your experience that are most useful to be able to contribute in a development team?

I'd say the ability to solve a real problem in the programming language of your choice is a minimum criteria to call yourself a programmer. Getting there would require a basic understanding of that language, data structures generally, many problems revolve around databases or REST APIs so learn how to use those, I'd also throw in version control and how to write unit tests.

Excellent, much appreciated