Mathematics I Use (2012)

I would say almost half the performance problems I have seen developers and devops managers run into over the last 5-6 years could have been avoided with a bit of front loaded queueing theory.

When you are doing microservice orchestrations, using an enterprise service bus or a pubsub, or doing multiple asynchronous operations, small delays multiply through the system. Spending a day to model your solution as a queue will give you some ballpark tolerances for lag, queue size, and in particular, RTT through the service.

Doing microservice architectures takes a lot of the logic of the problems solved decades ago on the network layer and reinstantiates them at application service layers without those solutions. Request TTL, state, queue flushing, retransmission, shortest path, service availability, 'ping', 'traceroute', etc.

If one service crashes, and requests start piling up, you need to clear that queue, and oftentimes your solution isn't built to clear that queue while more requests are coming in and your cache overflows because "keeping state is a next order complexity problem that wasn't specified in the user story." There is an assumption you can just horizontally scale your way out, which has significant compute and administrative costs. I suspect AWS makes a lot of its money as a direct result of those assumptions.

Not saying someone needs to be doing new proofs, but some forethought using a handwavy abstraction might provide some insight into the needs of the system under load.

I feel like you have to know a little bit about a lot of things. Like, yeah, you have to have a basic understanding of SOME graph theory when programming computers, but you don't really need anything too advanced. Yes, I guess you need to understand SOME category theory to be able to use advanced typing systems effectively, but it's a very surface level understanding of a very deep field. Same thing with most of the other fields mentioned.

One thing that wasn't mentioned: if you're doing any kind of graphics programming, you use a huge amount of basic linear algebra every day. Vectors, matrices, dot/cross products, affine transforms, spaces and subspaces, that kind of thing. If you're doing more advanced stuff, a working knowledge of how to solve large linear systems (i.e. things like Gauss-Seidel/Jacobi methods) and the physics of light transmission is also useful. If you're doing physics simulations, obviously you need a working familiarity with calculus.

Again, though, all of these things are massively deep fields that people dedicate their lives to understanding, but as a programmer you just need to skim the surface, generally speaking.

You don't need much mathematical knowledge to _merely_ be productive, but his points are valid.

1) The more math I learn, the more I realize how much I'm already doing it (via poor heuristics) without realizing it.

2) Mathematical training comes with many tools I would never think to Google without prior introduction. For instance, I sometimes use Karnaugh maps to simplify complex boolean logic. I'm sure there are many areas where I re-invent the wheel, miss simpler solutions, and generally produce less quality because I'm ignorant of the surrounding mathematical context.

As someone who has spent most of his adult life recovering from a math phobia (due largely to poor teachers in middle and high school) and enjoys programming as a hobby, had I read this article when I was exploring whether or not I had the aptitude/background for programming this would have turned me off entirely.

I agree with the others that this article seems to overstate the requirements.

This is a very well written post, in the sense that much of what he mentions is central to programming. But there's also a Zadeh's principle to mathematics -- when you have measure theory suddenly everything is a change of measure.

And I mean, this is great. "Diversity in tech" should be more like "people who are into analysis, topology" versus "people who are into algebra and cat theory" etc. There are many different ways to skin problem spaces into mental models and coding styles.

A good programmer may use many of these types of math without even knowing the formal names.

Sometimes knowing the formalism helps a lot, sometimes it doesn't add much. Some people overly obsess with formalisms and some people are overly adverse to them.

I do find people who need to over-formalize everything to be annoyingly pedantic.

For whatever reason, the link does not work for me. Google's cache doesn't seem to provide a copy, so here's one from the Wayback Machine:

https://web.archive.org/web/20180420113021/http://pub.gajend...

To the topic, I think this quote from the article is very important to note here: “Of course, I do not do all of this every day, but I have done all of it at one time or another and most of it regularly.”

It is nice to have an idea of how you write a parser for a language, but I do not believe the author advocates for being able to write one of the top of your head. Same with most other points.

I think if you're a programmer wondering what math will help you in your career, which is the question this article is trying to answer, this article is misleading.

Most working programmers won't have to know any math beyond arithmetic.

For instance,

"Also, how does one distribute a large computation across globally distributed data centers? You have to understand some physics to do this well: at Internet scale, the speed of light starts to be a bottleneck. Heat dissipation, density of electrical current draw per unit area, etc, are all real world considerations that go into what programmers do"

Come on, let's be real. In grade school we learned that light goes around the earth 8 times a second. That means 1/16 of a second (63ms) to go around to the other side of the world. That doesn't set a useful lower bound since this is the ballpark of latency within a country anyway. You're just going to ping between the two servers and measure the latency.

That being said, programming could in theory require any kind of math. If you're doing machine learning, you'll need to understand statistics. If you're doing graphics programming, you'll need to understand trigonometry, linear algebra, etc.

If you're writing software for the medical industry you'll presumably have to understand a little bit about how that industry works, but I wouldn't suggest programmers go learn that just for the sake of improving their "general" programming skills.

Here's a more realistic take:

1) Learn math as necessary for a field you're interested in

2) Know binary and hexadecimal representations of numbers.

3) If you're going to use a lower-level language, understand how signed/unsigned arithmetic works, boolean algebra, and some basics of the floating point representation (in a nutshell, don't assume that computations are exact, so don't rely on equality (==)).

4) Understand time and space complexity. For most programmers, this is going to be simple: don't nest too many for-loops. I'm guessing 90% of programmers will never have to construct an algorithm whose complexity involves a logarithmic function, except for maybe binary search. Even then, most programmers will rely on libraries to do those things.

5) Be able to do back of the envelope calculations, and understand that order of magnitude is more important than exact numbers. Try to do them in your head so you can quickly evaluate possibilities.

6) Increasingly, statistics and machine learning are becoming important for programmers to know. Learn some basic statistics and it will make you much more desirable. Play around with R or Octave or numpy and don't make the mistake of applying too much statistics without thinking, unless you're in the marketing department.

I you find yourself wondering how math heavy programming is before diving in...just start programming and ignore the math. You'll get by just fine. There's libraries for everything. Yes int theory you need to know some math to know when to use what but we live in an age where you can search for things like "I want to do X, tell me how" for most programming problems and get a reasonable high level "practical" answer of use library/function X and btw. here's the docs.

That being said (basic) logic, applied probability theory (no and some vector and matrix stuff are probably the most useful (for ML/DL). The more into algorithms you get, the more mathy it gets. Most programmers do this rarely in their day to day life unless they are rather specialized.

tl;dr: Don't worry about math, start writing code right now. It's fun. The rest will come once you get interested in certain things.

I'm very skeptical about the applicability of group theory to computer science - outside of the usual applications to counting/combinatorics and crypto/number theory.

[2012]