- For parsing, the difference between context free languages and regular languages. This has helped in a number of projects (usually at the clean up end).

- Boolean algebra has helped me greatly simplify hard to understand nested conditionals.

- Understanding data structures lets me pick the right ones for the problem.

- Algorithm analysis has let me take program runtimes from minutes or hours on modest data sets down to seconds or minutes.

- Discrete math topics helped me prove a problem that a coworker had spent a few weeks on was technically impossible.

- Again for parsing, understanding the ideas of parsing let me make a number of parsers over the years using a variety of mechanisms. The critical part, though, was understanding what was being parsed and how to parse so the code was clear. I replaced convoluted code with hardcoded values and assumptions about what would be in each part (line, or binary blob) with something more flexible and less hacky.

- Knowing how C stores data (stack versus heap) let me fix a lot of code from some engineer colleagues that would work, sometimes, but not reliably because they didn't understand how memory works.

Personally, I see it come up in more vague areas during my Web Development. It's more along the lines of, "based off my understanding of X, I can assume this bit of JavaScript code works like this under the hood". Understanding how memory works traditionally keeps me "memory-conscience", but this may be redundant when working with JavaScript. When writing complicated operations I can use things I've learned previously to improve efficiency. To put it nicely, I'm not balancing binary trees and sorting my arrays with JavaScript. However, it was helpful when learning how the VDom works.

In other industries...

I started my Software Development journey with C, then moved into Game Development in C++ as my first job. Game Development DEFINITELY requires a lot of CompSci info (that I lacked). Hash Maps, Pathfinding, Matrix math, physics calculations, Linked Lists; all the works. We were also using a proprietary Game Engine so maybe with other Engines CompSci isn't as needed, I haven't worked in different engines.

People can go on all day about this. The most major one for me is protocol engineering - there's a whole world out there on this. Others would be model based design and its formal verification. Also several problems in state synchronization in distributed systems.

In many of these cases, the team I joined had a code base in place that "kind of" did the solution, but was not grounded in any conceptual model - despite phenomenal code quality, peer reviews, etc. Recasting it as an implementation of a well-studied formal model generally yielded a codebase that was one-tenth the size of the original, and with far fewer defects. As I said in the parent comment, if you aren't familiar with this kind of stuff, you don't know about it, so you don't use it, so you find other (suboptimal) ways to do it.

What are resources you reference the most in this kind of work?

I use category theory quite frequently when doing functional programming. Unfortunately it is not taught in CS programs AFAIK. I rarely implement any tree kind of algorithms other than a simple tree visitor.

An understanding of time/space complexity (Big O Notation) is also relevant to evaluating approaches. A senior level developer will use this to make high level choices.

I also use compiler theory when writing parsers and simple DSL languages.

Honestly, never really had to deal much with red-black trees or linked list algorithms.

1. Unix was cutting edge OS theory and gave birth to the microcomputer industry.

2. AWS was cutting edge distributed systems theory and gave birth to cloud computing.

3. Renaissance Technology was cutting edge algorithms theory and gave birth to quantitative hedge funds.

Some people innovate for a living.

Never heard RenTec described that way, the only information that seems to be out there is that they use much simpler algorithmic techniques than people imagine, mainly just linear regression. Whatever unique insight they have, it's more likely to be based on pure mathematics than cutting edge algorithms theory. Also, they were not the first quant fund.

Unix was cutting edge OS theory? I mean, it was Bell Labs, and they were probably the premiere research facility in the world at the time, but my impression is that the trick on Unix was how small they were able to squeeze it, not that it was pushing theoretical boundaries.

Can you point me to any aspects of Unix that were theoretically new?

What we take for granted today was once brand new and hard won.

True. But what was new in Unix? What specifically?

Multitasking

Didn't Multics have that? I mean, Multics never went anywhere, but the theory wasn't new to Unix, was it?

Back then, Multics was designed to run on expensive and specialized proprietary hardware where as Unix could run on a variety of cheap computers.

One can say the philosophy behind Unix was new. I'm sure that's why modular and micro kernel designs caught on.

Please go pick up any of the Martin Fowler books. All are rooted in computer science fundamentals. Let’s not pretend software engineering isn’t rooted in computer science. That’s a categorically false assertion.

A moderate complexity task such as writing a JPEG codec requires understanding of Huffman coding, discrete cosine transform and a number of other minor concepts.

Right now am working on a physically distributed, synchornized system. It has some signal processing code: cross-correlation, FFT. The process planner builds spanning trees out of the layout graph to execute the tasks.

Tons: Cryptography, operating systems concepts including multi-threading, distributed systems, network communication, mobile and embedded systems which are basic backbones of all the things you use today. You know that's where majority of the tech companies are innovating on, right?

I have definitely worked on systems that tried to do parallelism without any real understanding of underlying primitives or theory. They were not ideal.

Dealing with unicode bugs taught me a lot about computer science academic theory. It helped to understand memory addresses and how encoding works.

I tend to use it quite regularly. I've had to diagnose many performance issues with our large code base. Understanding compilers, data structures, networking, OS internals, etc, have all been quite helpful. Even if it's simply finding a starting point for tackling the problem.

Sometimes it's trivial, replacing a for-each loop with something that's log(n) or O(1). Sometimes a little more complicated, like refactoring some code and realizing the original implementer was trying to do BFS but.. wrote something else. And the rarer cases are having to really dive in and trace some odd contention issues. All of these touch on what I learned in college at some level. Sometimes knowing something exists is helpful for looking up later and can save lots of time.

I do wonder if it's less about "requiring" the education and more about someone seeking out the kind of work that uses the education. I know many people in my company are the opposite of me, and definitely do not care to go much deeper than implementing things until they work.

I wish the whole industry would at least get to that latter level. I see a fair amount of “jiggle it until it’s no longer obviously broken”.

Relevant comment from a few days ago about Linus Torvald’s code handling of linked lists and the theory behind it:

https://news.ycombinator.com/item?id=25327683

Knowing the properties of a data structure and how it works under the hood is incredibly valuable when deciding if it's a good answer to the problem at hand. If you don't know why hashing is important or what it gets you, you might not understand why a hashmap is a very powerful tool. You might choose some other structure or hand-roll something involving manually managing multiple arrays, and down the line run into what feel like intractable performance problems.

That's just one example, pulled from people I've worked with. An understanding of fundamentals is required to do a real evaluation for yourself.

Currently writing software for electrical engineers. One example that comes to mind is graph theory. I use it frequently to answer questions about the data I'm looking at.

Imagine an electrical distribution network where there are 3 phases (A/B/C) and an overhead line can contain any combination of those phases. These networks can be modeled as a graph with nodes connected by links. The links do not have a direction, but they do have a phase. If you want to know what the phasing is at any point in the network, the way to figure that out is to use graph algorithms.

Boolean algebra, relational algebra, sets and graphs, reductions, runtime analysis, gossip and epidemic protocols, satisfiably, verification, turing machines, push down automata, etc.

it's a small thing, but I find it pretty useful to be comfortable with the basic boolean identities. makes it much easier to rearrange if conditions for readability without stressing that you might be changing behavior.

Dictionaries for O(1) lookups, b-tree indexes for fast SQL queries, interval trees in genomics analysis software.

If this was an interview I'd say dictionaries aren't O(1) but one popular implementation of this collection is.