I find performance / architecture stuff in general to be useful to know, along with having an intuition for orders of magnitude. Too much needless complexity exists in enterprise CRUD web apps for a 1.01x speedup.

We have a huge project in Spring Boot that crawls along, and a newer one in Dropwizard that's so fast we could support 1000x our current traffic. Funny because they both use Hibernate and JAX-RS to do roughly the same thing

I finally gave up and returned to the slow method but cached the results. Now we just warm the cache at night when usage is low.

Put it together in a day. Wish I had just gone this route from the beginning.

Our product basically allows users to build a whole bunch of assets (specifically, LOB wrappers, workflows and forms). These may depend on each other (e.g. a workflow displays a form, which displays data from LOB). If you want to redeploy those to a new environment in the correct order, that's a graph problem: topological sort (and you need to find cyclic dependencies, i.e. strongly-connected-components).

You cache users from upstream identity providers (such as Google or Azure AD) primarily because those providers can be horribly slow. You want to determine if a user is [recursively] part of a group, keeping in mind that some providers (Azure AD) allow for cyclic group memberships. Another graph problem: reachability. You want to take that same graph and cache it on nodes that query frequently. There's a paper for that[1] (pre-order and post-order numbering).

Lately, everything seems to be a graph problem - but I may just be wearing graph-tinted lenses. If you've never bumped into graph theory, there's probably a system somewhere that's a lot more complex than it needs to be.

[1]: https://eprint.iacr.org/2012/352.pdf

Seconded. Having at least a working knowledge of graph theory is essential for anyone, even CRUD app developers. You don't need to know how to implement a DFS blindfolded with one eye closed. But you do need to be able to recognize when you are facing a graph problem and what libraries to apply. The alternative you end up with is some really nasty O(n^2) or even O(n!) type code.

Off the top of my head, I can only think of two that have been universally useful in all of them, and they have been very useful too. Graph theory comes straight to mind, and the only thing that might rival it is automata theory (including formal languages).

Graph theory and automata theory often prove to be useful even in problems that aren't conventionally thought of as graph problems or automata problems, but once you get a good grasp on them, you start to recognize patterns in problems (or sub-problems) that naturally lend themselves to elegant solutions if the problem is re-framed from the perspective of the appropriate theory. I've wound up on several projects where the requirements seemed really complex and gnarly at first glance, but we would be able to create successful, maintainable, extensible systems whose architectures essentially consisted of a chain of ETL ⇒ {graph,automaton}+ ⇔ UI — basically the same shape as the conventional compiler pipeline but applied to data, and sometimes interactive.

Graphs are extremely versatile as data structures, with well-studied properties, subtypes, and algorithms. Automata are similarly versatile as models of processes, and similarly well-studied.

The two are easily combined. One project in particular would take in a set of rules from the user, construct an automaton out of it, feed data through it, which would generate yet another automaton that doubled as a digraph. This autographaton modeled the control flow of the former automaton during execution, amenable to graph algorithms (search, flow, sort, pattern matching, etc.), arbitrarily modifiable by the user, and executable to generate an arbitrary amount of mock data that had the same characteristics (as defined by the input rules) as the data that it characterized. It was designed to aid in the analysis and simulation of network traffic, but it wound up being general enough that people in other parts of the company started using it for other things, too (that I knew of at the time I left the company: I/O loads, software testing, and automated bug report arbitrage using core dumps).

You could probably write such a program without any understanding of the theories involved, but I think that knowing the theories had some definite benefits. The theories led the program to be structured in a clean, elegant, modular, and straightforward way. They helped the program be general yet powerful and useful. Importantly, they helped the program to operate in such a way (and to present such an interface) that was intuitive for the tasks—and the people—it was designed for. I absolutely credit the solid theoretical foundations with the success of the program, and I've gone on to design programs with similar foundations yet intended for different sorts of tasks—and people—that have also been rather successful, though, admittedly, perhaps not so generically applicable.

Software Engineering - hated it while in school, thought it was overkill. Then spent time on a hundred man year project - super important.

Programming Languages - having recently moved from Java to Ruby, this class was the bridge to make that transition smooth, having understood the theory of languages first.

Others have said database and data modeling.

Scientific Computing - was implementing some crazy PhD modeling from Matlab and actually had to think about float vs double, summation/multiplication techniques of large sets and their compounding errors, solving techniques (like least squares).

Basically, every software job that i’ve had that wasn’t building a website required my degree.

That said, the Single Responsibility Principle and Separation of Concerns (the "S" in SOLID) are things that I find important to adhere to. The trick with many CS ideas is to apply from them from first principles.

Example: Instead of some rule like "Your functions should never be more than N lines long." you should instead, ask yourself if the function is trying to do too many things i.e. deviating from the Single Responsibility principle.

Also, during the original design, I tapped into theory of functional programming in coming up with a highly functional architecture (even though the 'functions' are actually abstract processes on a virtual machine).

I'm a big proponent of theoretical CS!

1) A CS degree is a lot more than a few classes of CS, not even counting math and other content.

2) I think when people here are saying "degree" it's really just a short cut for saying "taking some concentrated time to study important theoretical concepts that are useful to know as you go about real life software development". In other words, you could do the same thing without college. It's just harder to juggle multiple things and not have the structured path. Even this is not perfect because it's still unfortunately a resume signal, but that's a separate problem.

3) Coming out of college with little professional or practical experience has nothing to do with the value of leveraging what was learned in college as you go about obtaining that experience. You're company may not want people without practical experience, that doesn't mean they're against having a theoretical grounding also, these are two separate criteria for them to desire or not desire.

4) This has nothing to do with ego. As I say the previous reference made was an unfortunate choice, but doesn't generalize to all people who take this path.

I find myself agreeing with most of the commenters here. Even for simple things like algorithmic complexity, I’ve watched colleagues choose data structures and algorithms with no regard for simple attributes that would make a big difference as soon as code gets out of the toy stage.

Why is it so hard to appreciate the importance of this?

The idea of seeing a doctor who never went to medical school would send us running scared. Hiring a developer with no formal computer science training? No problem, they’re smart, they’ll just pick it up as they go.

Of course, there's more justification in more rigorously vetting someone's credentials and abilities who is building a bridge or performing surgery (although software development work has absolutely caused loss of life).

However the question posed here is the value added by a solid theoretical grounding, and I believe it's not too different in terms of pure skills benefit.

I bet I could wing it in a lot of professions whether it be developer or surgeon, the main difference being more people would die in the latter example. Considering only the benefit to a person's abilities of more rigorous training, I see no reason why skills would not increase similarly.

Still learning.

There are other simple things, logic and circuits get you familiar with many things. How to take any language expression and change each term to invert it or manipulate parts of it quickly and knowing exactly what will happen.

Compiler theory is helpful not much because many people end up designing languages but for other reasons. For example DSLs (small domain specific languages) are used all the time for different purposes.

Learning about formal proofs of correctness. Again even though it's not widely done just being aware of it helps you understand the limitations and what's possible with the reliability of software.

Some grasp of discrete math is required to work with lots of things like 3d graphics.

Physics is a supplement that would just exclude you from a fair amount of jobs without some level of knowledge.

No one is mastering all these things at an undergrad level. I'm sure I've forgotten tons of it. But just the exposure, knowing its there helps, and when you need to actually use it it's easier to jump back in and ramp up or go deeper.

Distributed Systems theory. Especially the complexity of failure detection in distributed systems. Slow vs failed.

Networking. 99 out of 100 developers do not have sufficient understand of networking.

Many operating systems concepts. Virtual Memory Management. Scheduling. Intel x86 architecture and how CPUs actually work.

Relational Algebra.

Multiversion concurrency control.

Defense in depth. Information Assurance in general.

AST. Parsing in general.

For really tricky cases, I'll use a Karnaugh map, but those don't come up very often.

Interesting that you've actually seen complex enough cases to actually need a Karnaugh map, definitely one of the things I learned in class and proceeded to never use again.

Understanding compilers and interpreters gives a lot of insight into speeding things up and making code and program easier to be statically analysed.

Automata and state machines are useful. Algorithmic complexity helps avoiding hard problems.

I see model theory directly when modeling domains.

My last project involved making calculations, clustering and specific spatial queries over a set of 4D points ( GPS + time ) there is no way to make competitive complex applications if no one in your team understands O-notation, Dynamic Programming, Euristics, Graphs Theory, etcetera.

Building services as utilities with generalized input/output interfaces that know as little about your application almost always results in better code. If I can write something that could easily be pulled out into a generic package and used on projects with totally different data models and business logic, then I've built something right.

remember you or others of our Ilk will have to touch or replace that code some day. Getting fancy or sneaky is fun with competitions or bragging rights but in practical coding simple is ALWAYS best.