Mathematics for Software Engineers: Light Encouragement

Have you ever felt entirely too cool? Do you ever feel as though you hold in your hand the keys to something that might totally change the perspectives of people around you? Because I’ve had this feeling. I’ve had it when speaking with software developers who speak poorly of mathematics. This post is here to evangelize a for a little math study to add to your repertoire of frameworks, API’s, and modules. To some of the more academically inclined computer scientists out there who understand the close relationship between math and computers, please do not check out now. I in no way sell myself as a great, or even good, mathematician, and I need your support!

Consider these circumstances: Have you been encountering a problem with your algorithm that simply won’t go any faster? Maybe it’s because the problem is in NP space. Do you want to know the minimum number of nodes you need for your network to stay up? Maybe you need to understand the connectivity of your graph. Are you having difficulty with a recursive call? Perhaps a review of mathematical induction is in order.

If you’ve taken a course in discrete mathematics, graph theory, or theoretical computer science, then these scenarios should sound very familiar to you. I argue that study of these, and many other subjects, will make your study of algorithms, data structures, databases, and networks a much easier proposition. It’s likely that, as a programmer, you already think quite mathematically. Proofs and programs have a tight relationship. According to certain dogmas of logic, there is even an isomorphism from one to the other. The program’s network of implication, variable declaration, study of cases is already much like the construction of a proof. And when your algorithm finishes for all possible cases, well, you may have actually proved something.

You may say “Well, John, that’s really only showing that computers can be useful for mathematicians”, and that would be very mathematical of you. But I argue the converse as well. While I don’t argue for abandoning test-driven-development for proving that your algorithms halt for all inputs, I do argue that thinking mathematically can help you understand better what must be true about your inputs such that your algorithm has a chance at halting, what sets of inputs you can ignore because of their similarity to other inputs, and other shortcuts.

Perhaps the best kind of shortcut math gives us is the kind that takes algorithms from polynomial to constant time. I was recently working on the n-Queens problem with the rest my fellow Hack Reactor students and one of them figured out just such a trick for the case of the rook. Instead of checking every board, they realized they could just return a number. This is the kind of cleverness that computers don’t necessarily have the brilliance to solve. Anyone who’s ever experienced a stack overflow will know that.

So yes, thinking mathematically in that fashion will help you design the programs you want to create without having the pain of an infinite loop or the potential rabbit hole. But also, math is very cool. And I urge you to learn some terminology and definitions because clearly everyone who has written a major language knows them. Maps, graphs, sets and functions are common terms in math and working with them away from the keyboard will help you write better code.

Like what you read? Give John Soo a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.