The Dichotomy Between Computer Science and Software Engineering

This is a topic I’ve been talking/thinking about for a few years now.

There’s a pretty obvious dichotomy between Software Engineering and computer science. If you’ve worked in the field for any sizable amount of time, you’ll have seen this yourself.

You see this with incredible app developers who are afraid of doing coding questions during interviews. And you see it in the genius computer science guru who has no idea how to deal with state in an app.

I’ve seen one of the smartest humans I’ve ever met struggle to make a basic React app scale. Wonderful computer science brain, terrible at actually building apps in the modern world.

I’ve also known more than a few extremely talented engineers that were super not into computer science stuff. They don’t really think about data structures or algorithms as tools in their daily toolbox, and they don’t care much about the history of computer science or the innovations and ideas of people like Turing, Church, or Von Neumann. They also tend to be afraid of DS/alg interview style questions, or even actively spread their dogmatic dislike of modern interviewing styles.

I want to stress something early on: both of these are 100% valid personality types and I am not in any way criticizing anyone who fits either description.

In fact, the reason I’m bringing this up at all is so that I can tell my students and readers that both camps certainly exist in the real world. And it’s totally valid to fit either of these descriptions and live your professional life this way. A few of my favorite people in the world fit these descriptions, and I actually used their personality quirks as a guide to write them.

I myself was a member of one camp early on in my career before switching entirely to the other camp. It wasn’t until a couple of years ago, almost a decade into working professionally, that I started to take inspiration from both sides of the coin.

Why these things get confused

I think a lot of folks conflate SWE and CS pretty naturally. After all, there is a ton of overlap. In all reality though, you can be pretty deep in one world without even touching the other.

For example, imagine someone writing a compiler for a new type of programming language with some crazy new feature. A compiler is actually a relatively self contained little world, and you get to make all the rules. You get to design your language and only implement the things that you think are a good idea.

When you’re designing a piece of software for the outside world, you have to consider all the possible edge cases based on human interaction. Who is the software for? What features do they need from it? What platform are they most likely to be using? The constraints are a lot more “people-y” and out of your immediate control.

What is science?

To make my stance just a bit clearer I want to actually define science. I think the official definition of science that most aligns with CS is this:

science: a department of systematized knowledge as an object of study

I want to think about this from a different perspective. Some of the language I’m about to use is inspired by something that Neil DeGrasse Tyson said at some point, although I can’t remember when/where he said it.

The human race has a collective knowledge. It essentially operates as a hive mind and we are all connected via our communication streams (the written word, the internet, etc). This body of knowledge has a boundary, and it constantly growing.

You can picture this body of knowledge like a spot of light growing larger in a vast dark expanse. Science is the process of helping this body of knowledge grow. Scientists stand at the edge of this ring of light and peer into the void, looking for new bits of information that might help the light grow larger.

Computer Science happens the same way. There are a group of humans that actively stand at the edge of this void and try to unravel the mysteries of computation. What things are computable? What are the fundamental limits of computers?

When you look at it this way, I think it’s pretty obvious that very few people are really doing this kind of work. I know a ton of engineers, but I don’t know any that I would say have “redefined what the species knows about the fundamental limitations of computers.”

This could easily just be a frame of reference issue, though. Where I am blinded from the truth that the actual CS community is really massive and thriving.

But in reality I think the truth is that most people are just using the tools that have come from previous research. The ratio of consumers to producers in the CS world is probably something like 999:1.

The same tools

I think one of the major reasons these things are talked about in the same sentence is pretty simple: they both use a lot of the same tools. CS may be predicated on some crazy mathematical formalisms, whereas SWE is predicated upon the need to provide value to the daily lives of humans and businesses. But they both use the same tools.

Programming is at the heart of both disciplines, and so I think it’s easy to see some software engineering work and say “Wow that’s computer science!”. I think it’s similarly easy to see someone doing some science-y work and think of them as a software engineer. And they dont always diverge, of course.

What’s the point

There’s really no huge conclusion here, I just wanted to ponder on the spectrum that runs between SWE and CS work. Some people focus entirely on SWE and actively strive to ignore the principles born of CS.

I mean this literally: I’ve met human beings in the real world who are wonderful software engineers, and who actively are afraid of computer science (and openly admit this). They ignore data structures, algorithms, and all the CS-y bits of the world, and just focus on getting their app/system doing what it’s supposed to do. This is a human process, not a science driven one.

And I’ve met people with beautifully intense CS minds, master’s degrees in the field, who couldn’t put together a usable and robust front end application to save their lives.

I’ve also met a ton of people who have some natural balance of the two skillsets, and the main reason I’ve brought this up to validate the entire spectrum. If you want to be an actual computer scientist and you don’t care about real world software, you can go focus on just that. And similarly you should feel empowered to focus on building apps and forget about the whole science thing if that’s what you want.

In reality some combination of the two does tend to breed the most effective minds in the engineering discipline, though.

A quick history lesson

For those of you who are interested in the science-y stuff, I did want to leave a couple thoughts and some resources. Below is a quick recap of the major events that led to birth of computer science as a discipline. Keep in mind that I’m no expert, and I am missing a massive amount of context here. This is meant to serve only as a starting point to get your brain moving, not as some bottomless introduction into the reality of the world.

Just to get you started. The term computer science didn’t even exist until the mid to late 1950s. That’s actually pretty insane. It’s such a new discipline that it’s crazy to think about how far we have come as a species in such a short amount of time.

Entscheidungsproblem

In the late 1920’s, mathematician David Hilbert asked a simple question:

Is every mathematical statement provable?

In other words, he wanted to know if there was some generic way to take any mathematical statement and decide whether or not it was valid. He wanted this process to be abstract so that it could be used on any statement. Nowadays we call this an algorithm, btw.

The problem was known as Entscheidungsproblem, and it was a really hot topic in the field of mathematics.

Church-Turing

It was tackled later by Alonzo Church and Alan Turing, who both ended up releasing papers on the problem around the same time (~1936).

They both came up with the same answer to the question: no. Every mathematical statement was not provable. They went about answering the question in two very different ways. If you’re interested in what they came up with it, check out the following:

There’s also another great resource that I read when I first got really into this stuff a few years ago. The annotated turing is a great book by an author named Charles Petzold. It takes Turing’s original paper and breaks it down entirely, including a bunch of history about society and the field during this huge transition.

Some of the big takeaways

I think the most important thing to think about is their answer to the question. By saying that every mathematical statement could not be proven, they were really saying that not every thing you could possibly want to compute can actually be computed.

With our modern architecture being heavily descended from the work they did in the 1930s, this means that computers are fundamentally limited. It’s easy to see this massive shift in technology and think “wow we are really just going to keep progressing forever!” But the reality is that computers have fundamental limitations just based on the nature of reality. Pretty psychedelic shit if you ask me.

Recently the world has tried to make breakthroughs in those limits with a fancy thing called quantum computing that attempts to use the principles of quantum physics to broaden our set of “computable things.” I won’t pretend to have any knowledge worth sharing there.

The last big takeaway I’ll leave you with has to do with the difference in how they got their answers. I don’t understand either of their original papers well enough to be an expert, but I do understand the lineage of their ideas well enough to say this:

Turing and his paper tape are basically the core ancestor to modern imperative thought in programming.

Church and his lambda calculus are basically the core ancestor to functional programming.

What’s next?

I’m still on my own journey here, I just wanted to share this in the hopes that someone finds it interesting enough to go and do their own research and reading. If you’ve already exhausted all the resources above and are still craving more, I’ll leave a list of books at the end (and hopefully update it over time as I learn more).

For me the biggest thing is the limitations of computation. I’d love to one day be an expert in computability, energy willing. For now I just take some small comfort in the fact that not everything is computable. To me there’s something hopeful in that statement.

Maybe it’s because I’m an engineer and I don’t want my job to be stolen by some crazy AI. I think there’s some analog between not all things are computable and we will always need some to translate ideas into code.

After all, programs are just state. They are the state of our ideas about how a system should operate. Updated all the time with our new thoughts about how things should happen. Programs are nothing more than human ideas, encapsulated in weird little languages. I hope to continue having ideas and translating those ideas into code for many more years.

Cheers!

Resource List

Originally published on my mentorship blog on March 14, 2022.

🐍 Snake