In defense of theory

I feel like theory gets a bad rap these days.

I’m all for practical applications, but there are times when it helps to understand why things work they do, which is difficult to do without some theoretical understanding.

Some of my fellow coders out there are saying, “Duh, of course you need theory. How else will you pass a technical interview?”

There’s some truth to that, but it’s putting the cart before the horse. Performing well in a technical interview should be a side effect of a deep understanding of how your tools actually work. The technical interview shouldn’t be a goal in itself.

It’s the difference between heating up a meal in the microwave and cooking something from scratch. Yes, the latter is harder, not to mention riskier if you don’t know what you’re doing. But all things being equal, I’d guess most people would prefer a well-prepared meal from scratch to a microwaved frozen dinner, not to mention it’s probably better for you, too.

For the record, I’m not saying that everyone who codes for a living needs to have a computer science degree, or even has to set foot in a university. But it helps to know, for example, that some approaches are faster than others for certain problems, and it’s even better to know why.

The counter-argument that I often hear is that the vast majority of coders don’t use a lot of theoretical concepts in their jobs. This is true enough. I’ve coded a grand total of zero linked lists since I’ve started writing code for a living.

That said, I don’t consider the time spent working on linked lists in school to be a waste. While you might not use linked lists per se in your programming career, there’s a good chance you’ll encounter some kind of custom data structure in your work. Writing your own linked list implementation helps prepare you for the kinds of data structures you’ll encounter. Commit histories, anyone?

It’s a similar story with bubble sort. I whined like a squeaky wheel when I had to write a bubble sort as a beginner. Why do we have to do this, I wondered, when every modern language has built-in sorting methods?

Again, the purpose is not to write a production-quality method that you can return to time and again throughout your coding career. The purpose is learning to think like a computer and apply some of the most fundamental concepts required in programming (conditional statements, control flow, etc.) without bringing recursion into it.

Now if you want to argue that insertion sort would be a better choice for this task, that’s fair.

On a similar note, I’m not as bothered by some people that university computer science curricula rarely cover the latest cutting-edge development frameworks. First, those frameworks change awfully quickly. A framework can spring up and disappear in less time than it takes to get a journal paper published.

Second, and more importantly, it isn’t a university’s job to turn out tailor-made junior developers. Once you have basic computing concepts down, it’s much easier to learn how to implement them in a language you’re less familiar with than it is to understand how something works if all you’ve done is follow online coding tutorials.

I’m not saying we need to walk around with the equivalent of an algorithms textbook in our heads, although if that describes you, that’s amazing and I’d like to meet you! But like all good artisans, it’s important to understand the properties and limitations of our chosen material. Some basic theoretical understanding can go a long way in making coders better at their craft.

Has theory helped you become a better coder? Are there theoretical concepts that you feel have tripped you up unnecessarily? Let’s talk about it in the comments!