When I learned to program, back when dinosaurs walked the earth and the internet had no cats, there was an idea: if you were good at math, you’d be good at programming. I was great at math as a kid, but perhaps because I didn’t like it much, no one steered me towards programming. I came to it accidentally, in college, when I took an elective programming class because it fit my schedule.
So my first programming language was Fortran, an abbreviation of “Formula Translation.” As you might expect from the name, the projects in the class were exciting things like estimating the area under a curve using rectangles, like you see in the diagram below.
Doing Riemann sums in Fortran is about as math-oriented an introduction to programming as you can get.
And I loved it. SO MUCH!
That same quarter, I was taking my first Japanese class. Towards the end of the term, when I was getting ready to change my major to computer science because PROGRAMMING FUCK YEAH, I thought briefly about how similar the two classes felt. In both cases, I was coming into a culture I didn’t understand or feel part of. I was learning the mechanics of communicating, while at the same time trying to gain enough cultural knowledge to feel at ease.
But I knew – and everyone knew – that programming was like math. So clearly, I was good at Fortran because I was good at math.
Now, almost twenty years later,
I’ve changed my mind.
It started when I graduated, became a software engineer, and discovered that the vast majority of developer jobs only required middle-school math at the most. I had to keep a bit of math handy to do whiteboard interviews, but once I was on the job, my ability to communicate both with computers and with other humans was much more important.
I figured, at the time, that my jobs were the exceptions. Surely most programming was way more about math. I just, uh,…didn’t see those jobs. Even on the job boards. And my friends didn’t seem to have them, either…but oh well.
Then after I’d been working about ten years, I started teaching new people to program in my free time. I taught Ruby on Rails, which is a web programming framework; people came because they wanted to learn how to make websites. Because of those motivations, the curriculum had virtually no math.
And this is what finally did for it me. The students I saw – all adults – came from a wide range of backgrounds. People with a math background did fine, of course, but people with a heavy language background often did better. I saw this curious effect again when I started working with high schoolers, with a similar curriculum. Bilingual kids often took to programming more easily than monolingual kids.
I thought back to college, to my jobs, to my friends’ jobs, teaching…and I finally figured it out. Programming is not math.
Programming is Language.
Specifically, learning to program is more like learning a new language than it is like doing math problems. And the experience of programming today, in industry, is more about language than it is about math.
And my next thought, of course, was why doesn’t anyone else think this? Why do we still have this idea that math skills indicate programming potential, while language skills mean you should go into poli sci?
Well, when I feel out of my depth, I usually start by looking for “official” opinions. So I looked for relevant academic research.
I found absolutely none, which is pretty flabbergasting. I found a lot of opinions, both from computer science educators, and from people in industry. Perhaps within academia, the link between math and programming is considered such an obvious truth that it isn’t worth confirming with research.
It seems more likely, though, that this research exists, but not under the search terms I tried. Please let me know if you are aware of relevant papers.
In the meantime, if we can’t have data, we can at least examine the conversations people have on this topic. Here are some things people often say when asserting that people must be good at math to be good developers.
Generally, they fall into three categories:
1. “You need to know math to be a good programmer.”
2. “You need to learn math to get the skills you need for programming.”
3. “Plenty of programming is still math!”
Let’s look at them one at a time.
1. You need to know math…
1A. …because computer science comes from math.
This is true. Academically speaking, most computer science departments trace their lineage to the mathematics department. Many computer science degrees are still very math-heavy. Mine certainly was.
However, as many other people have noted, computer science is not programming. At most academic CS schools, the explicit intent is that students learn programming as a byproduct of learning CS. Programming itself is seen as rather pedestrian, a sort of exercise left to the reader.
For actual developer jobs, by contrast, the two main skills you need these days are programming and communication. So while CS still does have strong ties to math, the ties between CS and programming are more tenuous. You might be able to say that math skills are required for computer science success, but you can’t necessarily say that they’re required for developer success.
1B. …because without a mathematical foundation, you’ll have only a surface understanding of programming.
A common variation on this: without a CS degree, you can’t build anything substantial. Which, ha ha! Don’t tell the venture capitalists! They’re down there on Sand Hill Road giving actual money to hundreds of people building software projects without any formal qualifications whatsoever. In fact, they do it so often that the college-dropout-turned-genius-programmer is our primary Silicon Valley archetype of success. And monetarily, their strategy seems be to working out for them, if the fleets of Teslas on 280 are any indication.
Back here in the real world, I have found little connection between a person’s formal qualifications and the depth of their understanding. As an example, consider whiteboard interview staple big-O notation.
If you took a dynamic methods class in school, you know that big-O notation is pretty much meaningless in the real world. Which is to say, it doesn’t matter how an algorithm operates on an arbitrary set of data. The only thing that matters is how it operates on your set of data. An algorithm that is O(n**2) for arbitrary data may actually be constant time (meaning O(1)) on your particular data, and thus faster than an algorithm that is O(nlogn) no matter what data you give it.
There are some interesting mathematical ways to model this, but weirdly enough, the people with CS degrees conducting whiteboard interviews never seem to be too interested. Go figure.
So, if you don’t actually need to know math to be a successful developer, perhaps instead the very act of learning it primes you to think the right way?…
2. You need to learn math…
2A. …because it teaches abstract problem solving, which you need to be good at programming.
Abstract thinking is absolutely a skill that every developer needs to hone. In fact, some people say that finding the right level of abstraction for a concept in your code is the root of all hard problems in software.
It is also quite true that you can learn abstract thinking by studying math. At last year’s GoGaRuCo conference, Daniela Wellisz, a developer with a background in math, did a fascinating talk on how programming is similar to doing proofs in math. I recommend watching it if you’re interested in the topic.
However, just because you can learn abstract thinking via mathematics doesn’t mean there is no other way. Learning a new human language is another way to develop that skill. Coming to understand concepts that are literally impossible to express in your native language is pretty damn abstract. When we learn a second language, the way we re-organize concepts based on a higher level of abstraction is structurally quite similar to how we re-organize concepts when we learn to think mathematically.
So while math is one way to learn to think about abstraction, it is not the only way.
2B. …because programming based on the mathematical concepts of logic.
Indeed, programming is often concerned with logic. But the same logical concepts are embedded in our human languages. Math is just a formalization of the concepts we use every day when we construct sentences and communicate with other humans. The best writers and speakers understand that, and can construct logical statements in human language that are easy for other people to evaluate. Sometimes they even change people’s minds about things.
Mathematical logic is a notation for concepts we already know, and it is the concepts – rather than the notations – that are important.
So if you don’t need to know math to be a developer, and you don’t need to learn math to be good at development…wait! But some jobs still do!
3. My developer job uses plenty of math!
Of course people still use programming to do math. But programming itself no longer is math.
Even in non-math-oriented languages, there are some applications where math will be useful. And then of course there are whole languages oriented around math, such as Fortran, as I mentioned before, and Haskell, a largely academic language now finding favor among some industry developers.
But these are the exceptions that prove the rule. If a small and shrinking set of programming applications require math, so much so that we cordon you off into your own language to do it, then it’s pretty clear that heavy math is, these days, a minor specialization.
And even if you are writing code to do math-y things, you’re probably not very good at it unless you’re also good at language. The best developers today work on teams, and they do well IFF they know how to communicate – via their code, and directly with other people. As one of my favorite programming books once said, “programs must be written for people to read, and only incidentally for machines to execute.”
The long view
If programming is so similar to language, why haven’t we – developers – already made this mental adjustment? Why does the idea that “if you’re good at math, you’ll be good at programming” persist so strongly?
When programming was just getting started, early in the last century, we used it to solve highly mathematical problems like calculating missile trajectories and decrypting secret messages. At that point, you had to be good at math to even approach programming. Tools, such as programming languages, were designed specifically to solve mathematical problems, because those were the ones we thought it was worth spending money on. Computers were for doing math.
Over time, due to lots of different factors, our societal conception of what computers are for has evolved. When considering this question, these days we think in higher-level concepts such as solving a problem, making some tedious thing more convenient, and/or making money. These higher-level goals sometimes include mathematical subgoals, but also include things like ease of use, connectivity, and interface — problems that can basically be summed up as “messy humans and their relationships to other messy humans.”
So as a result, while programming is still applied to some mathematical problems, in our modern world it is more frequently applied to other, messier types of problems. The shift happened pretty quickly – it started gathering steam in earnest in the 90s. And today – only 20 years later – we find ourselves with math-oriented programming jobs firmly in the minority.
It makes sense that slow-moving academia hasn’t caught up yet. And the programmers who today are the senior developers, the old guard, came of age when this wasn’t yet true. So of course they think the path to success looks like theirs.
You can still be successful if you walk the traditional path. If you’re good at math, you’ll probably still be good at programming.
But the rapid evolution of our industry means that math skills are no longer the only indicator of potential developer skill. In fact, they’re probably a weaker indicator than they’ve ever been, given where the industry’s going. So please, guidance counselors: send us the ones who love language. We’ll give them the tools to change the world.