Some insights inspired from theory help a lot with writing CRUD apps. (Also of course, inspired from outside and then explored further by `theoreticians'.)

The most successful of these are now invisible. Either because they are available libraries or so ingrained in the background of what we are doing.

See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs.

For CRUD apps, "Out of the tarpit" (http://shaffner.us/cs/papers/tarpit.pdf) is an interesting paper that I hope describes how the mainstream programmer will build CRUD apps in perhaps ten years time. (I already used a variant of their techniques in a previous job, and it was rather pleasant.)

But yes, in practice knowledge of theory often acts more as a gatekeeper for getting into the likes of Google than you will use it. But when you do spot some opportunities to replace endless workarounds and tedious manual monkey-work with an elegant overarching principle, it often makes all the hours spent studying worth it.

As an great practical example: shake (http://shakebuild.com/) is a build-system that was born out of our frustrations with Gnu Make at Standard Chartered Bank.

Similarly, Bloomberg used to use C++ to describe financial derivative contracts. Those derivative contracts don't fit well into class hierarchies. Switching to an embedded DSL approach embedded in a functional language made the software easier to write and more robust to common errors especially when maintaining.