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.
Good book? Are you sure? This is a terrible book on performance...
It begins with the classic: "this book will make readers pass the first chapter, because it contains simple explanations for performance phenomena..." --> then, by chapter 2 everybody is completely lost about the subject... again......... :(
Edit: this book is currently sitting on my shelf collecting random particles of dust (for 4 years...).
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.
I agree. Writing spacecraft simulation software you use a lot of 3D math as well: matrix math, euler angles, quaternions, etc (being thrown into writing a simulation model for an attitude determination and control system with no prior exposure to orbital mechanics was great fun). Didn't have to become an expert (we had PhDs on staff for that), but had to gain an understanding of the basic concepts in order to get the job done.
I've also worked on some signal analysis stuff -- had to learn about FFTs and basic filtering (band-pass filters, etc.) -- it's all math. But had books and the internet to look up those algorithms.
I have several books on my bookshelf for these things, including an old copy of "Numerical Recipes in C" :)
If I may ask, how does one get "thrown into writing a simulation model for an attitude determination and control system with no prior exposure to orbital mechanics"? I always wanted to write software that deals in some way with spacecraft, but always thought one needs to have some physics degree for that.
Right place, right time. My career path has been a little weird. I got into the aerospace industry because after leaving the Army in 2006, I had a 4-year old CS degree and no work experience - but I did have a clearance, so I was able to land an entry-level SW job with a small aerospace company working on 3D visualization stuff. After a couple of years with that employer, I was hired on with a huge aerospace company working on a large satellite program.
As to the how, consider that if finding good software engineers is hard (debatable), finding them with clearances is even harder (definitely true). The interviews for defense and aerospace jobs are easy compared to your standard technical interview at Netflix, Google, et al. They really don't want to risk screening folks out for trifling things like "competence" when they have billets to fill (because they're selling man-hours of labor to the govt, even a mediocre engineer can be profitable).
But you should also know, that while working on a large satellite program may sound cool, the maddeningly slow and byzantine bureaucratic development processes (I'm currently on a waterfall-driven project) inherit in such programs will suck every last ounce of joy out of your working life. So, there's that...
And yet I’m constantly surprised by people knowing nothing of set theory. Occasionally someone who doesn’t know logic (evidenced by nasty, over-complicated Boolean logic)
Or my current favorite: a very senior and very optimistic person who apparently doesn’t believe in decidability, the halting problem, or NP completeness.
Like, they think computers are just invincible problem solvers, or can't even really comprehend the question? I can't grok what it means to not believe in NP completeness.
That developers can do anything if we stop complaining and get to work.
No, in fact we've proven there are a lot of things we can't do, and oceans of things that are theoretically possible but completely impractical to do (another class of people mistake intractable for impossible, but for small enough N sometimes it is both possible and worthwhile).
> Or my current favorite: a very senior and very optimistic person who apparently doesn’t believe in decidability, the halting problem, or NP completeness.
Undecidability and the halting problem is usually analysed for Turing machines (I am aware that there also exists literature on these problems for other types of automata). The problem is: It is impossible to build a Turing machine. Every computer that has been built up to know is just some kind of finite state machine. So the halting problem is perfectly (in a mathematical sense) deciable for real computer programs. The problem is: We have no idea how to do this in general in a timespan that is suitable for practical purposes.
IMHO you need just enough to be comfortable using math as a tool applied to your particular every-day practical situations, but you don't need to go into the academical depths like e.g. a scientist would have to. And you also need to have at least some faint idea what are the available options, so that, if needed, you know what to google for.
I'm not sure that's true. I think it's pretty tough for somebody who doesn't understand a field to assert that understanding the field deeper is not necessary.
You'll see many non-programmers assert that it's not necessary to get trained programmers to do a certain task (say, automation). However, they don't understand all the software engineering considerations and issues that you'll run into if you don't have a programming background.
It's only when you truly understand a field that you can see when that field is applicable to the task at hand.
Yeah, I'll never tell someone not to learn something for the sheer enjoyment. But this article is downright pretentious. It gussies up a lot of simple day-to-day tasks with off-putting terms and would not be helpful to a beginner.
The secret to linear algebra is homogenous coordinates together the exterior algebra. plus matrices sprinkled in. If you use those for everything all your problems simply disappear.
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.
This. I believe we are ripe for another leap in math education, or at least computer science education. A new approach to teaching that in a generation will make current methods looks like rhetorical algebra.
That page is a sort of rosetta stone for me after years of learning to code while also struggling with math notation. I find a similar fog lifts when I look at set theory through the lens of SQL and relation databases.
It amazes me that we still can't clearly demonstrate to children why math is important and instantly and universally instill a love and curiosity. Instead we have unforgiving educational models that are "well, you either get it or you don't."
It angers me to think of all the potentially _effective_ programmers who get their dreams squashed because they can't pass Calculus II (or other prereq.), and thus are literally not allowed to enroll in a programming course.
I didn't know about Karnaugh Maps but I use truth tables constantly in the design phase of tasks. Thank you very much for this. If you've found other tools like this please share. Not really related but for requirements I find gap and SWOT analysis to be vital tools as well as weighted pairwise comparisons. Throw in some UML diagrams and I start feeling good about things. These things impress far more people than they should.
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.
No. Post-college, I didn't need it for my job and I discovered programming - at least at the level that I was enjoying it - was as much, if not more, about logic and breaking problems into pieces. Despite that my lack of math ability felt increasingly like an albatross around my neck. In the same way that one might feel they're missing out by not studying history.
It was only after coming across a quote from Charles Darwin where he mentioned that one of his regrets was that he didn't study math more thoroughly. And that because of that there were entire "conversations" he was missing out on. For some reason I found that both liberating and motivating.
"Me and Charles Darwin, we're not so different you and I." ;-)
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.
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.
Programmers use tons of math, they just don't recognize it. Partially because you can still come out of even a bachelor's program in computer science and still think "math is just about numbers", but some of it is also just excessive familiarity and not realizing the easy things that you're doing that are actually mathematical because school trained you that Math must be Hard and you have to be Sitting There and Thinking Very Hard or you're not Doing Math.
Every day I'm using mathematical reasoning such as "I reached this line of code, and since this is a structured program I am guaranteed that this variable was initialized by the time I got here", "this function can only return either a non-empty string XOR an error and has nowhere it can throw an exception so if I handle those two cases I have fully handled everything this function can do", "the error string has the username in it, and values like that must come from somewhere, so even though I've been looking for an hour and can't find it, mathematically the thing generating the error message must have access to the username", "if I construct this as a pure function that does no IO, on the flip side, no users of this function will have to worry about what errors could arise during IO, reducing the mathematical cognitive load of using this function for users".
Then you start stringing together those steps by the dozens and hundreds and thousands and millions (and you get qualitative differences there too, but those don't fit into a little post like this anywhere near as well), and you can build software.
You don't have to realize you're reasoning mathematically (proof: look around), but you're leaving useful tools in the toolchest if you don't. Even if you won't believe me about building systems this way, I can assure you those magical stories about people who can debug systems at a glance that have defeated others for hours or days comes back to someone who either formally or by experience has a fairly mathematical understanding of the system in question and was able to apply some sort of logic, even if only intuitively, to arrive at that conclusion.
But that's mostly logic, at best mathematical logic. I don't think anyone formally reasons when writing code anyway, we mostly rely on intuition. Maths isn't about numbers but it's not about intuition neither.
Programmers doing actual math would be modeling problems and creating proofs for their solutions. Usually we clasify those problems based on the field of math we use to model them.
Saying we do tons of math implies we use a lot of knowledge from a lot of those fields. But most of the time, programmers use only the introductory notions of those fields. We are usually guided by a domain expert anyway so that the math part is correct.
Programmers don't use a ton of math. They use some math.
I think most modern mathematicians would be taken aback if you told them logic is not math. You might be surprised what some logicians have gotten up to.
And sure, if you define what I talked about as not math, then you don't use math. If you don't want to use the tools of mathematical thought, be my guest. It's one of my competitive advantages in the marketplace.
But I think Dijkstra would be pretty surprised to hear that structured programming wasn't math, and you might be interested in budgeting six months or so to play with Coq or something like it, where you'll learn that the difference between proving code and what you do in just trying to make code work and debug code is much more a quantitative difference than the qualitative difference you think. There's no magic in how code proofs work... it's the same processes you use all the time if you code at any scale beyond a single screen of code, just taken to their logical conclusion.
Propositional logic / zeroth-order logic is like arithmetic. You didn't consider numbers (by which I gathered you meant arithmetic) as math, and I'm the same in saying this type of logic is not math.
Logic is a VAST field, and most programmers don't get to use most of it, that was my point.
I already played with Coq (that feels weird to say :)) ). It is a very specialized tool useful in very specific cases. I don't think it will ever be adopted as the standard way of programming since it's really unproductive.
Just because you use math that is really heavy does not mean you understand the math behind completely. We can view a ball throw as a complex quantum-mechanical physical process but we don't call ourselves theoretical physicists for being able to throw a ball.
Some of your points remind me of Underwood Dudley's 2010 article "What is Mathematics For?" [1]. Briefly, he argues that we greatly exaggerate how much math you actually need in most jobs that people usually think of as needing math, but nevertheless learning math is worthwhile and important because of what it teaches you about how to think.
I agree. It's (usually intuitively learned) reasoning that's very similar to the logical reasoning of mathematics. I think if you were to study, say, calculus in a manner typical of a first course in college, you'd be missing out on that sort of problem solving, but you'd definitely get that if you took a proofs-based class in analysis ("This function is continuous on this interval, so it must have a maximum. How can I use that to prove what's being asked?").
> 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.
> 1) Learn math as necessary for a field you're interested in
I think this a Rumsfeldian problem: you can address the known unknowns, but what about the unknown unknowns?
There's no great answer to this, and it's why I think the original post was advocating the broad fields of math.
Just knowing math exists, though, doesn't address the depth to which you study it. I've gone at monads about five times now and I think I get it, to where I see why a promises library works the way it does. Same with databases, learned SQL, then stumbled across the wonderfully cranky dbdebunk.com, read Date's book, finally spent some months working on an implementation of the relational algebra and finally grokked it.
The problem with some of these deeper subjects is you'll have many "aha" moments only to look back at your early "ahas" and realize you had no idea what you were doing.
I'm not so sure. Programming is isomorphic to mathematics (via logic) as proven by the Curry-Howard Correspondance, and so is not just applicable to ones problem/industry domain—it's applicable in a much more general sense. In my experience, the learnings on both sides of the coin filter back to the other in surprising and often highly insightful ways.
> Most working programmers won't have to know any math beyond arithmetic.
If your job is to write code that moves information back and forth between a database and a web page, this may be somewhat true. However, once you get beyond that to the point you are actually solving problems in code (not just moving information) you are going to need math beyond arithmetic. Algebra, boolean logic, and statistics are just a few things programmers use all the time--almost to the point that they may not think of them as "using math" because it is just built into the way they think.
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.
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.
There's a good book for this if anybody is interested http://www.cs.cmu.edu/~harchol/PerformanceModeling/book.html
If you have access to Safari Books Online, it may be in your collection there as well.
http://techbus.safaribooksonline.com/book/electrical-enginee...
Good book? Are you sure? This is a terrible book on performance... It begins with the classic: "this book will make readers pass the first chapter, because it contains simple explanations for performance phenomena..." --> then, by chapter 2 everybody is completely lost about the subject... again......... :(
Edit: this book is currently sitting on my shelf collecting random particles of dust (for 4 years...).
There's many other books[1] on queuing theory if you want, I liked the Harchol-Balter book because of the exercises [1]https://web2.uwindsor.ca/math/hlynka/qbook.html
Cool reference. Lot of mathematical requirements are same as Probabilistic Machine Learning.
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.
I agree. Writing spacecraft simulation software you use a lot of 3D math as well: matrix math, euler angles, quaternions, etc (being thrown into writing a simulation model for an attitude determination and control system with no prior exposure to orbital mechanics was great fun). Didn't have to become an expert (we had PhDs on staff for that), but had to gain an understanding of the basic concepts in order to get the job done.
I've also worked on some signal analysis stuff -- had to learn about FFTs and basic filtering (band-pass filters, etc.) -- it's all math. But had books and the internet to look up those algorithms.
I have several books on my bookshelf for these things, including an old copy of "Numerical Recipes in C" :)
If I may ask, how does one get "thrown into writing a simulation model for an attitude determination and control system with no prior exposure to orbital mechanics"? I always wanted to write software that deals in some way with spacecraft, but always thought one needs to have some physics degree for that.
Right place, right time. My career path has been a little weird. I got into the aerospace industry because after leaving the Army in 2006, I had a 4-year old CS degree and no work experience - but I did have a clearance, so I was able to land an entry-level SW job with a small aerospace company working on 3D visualization stuff. After a couple of years with that employer, I was hired on with a huge aerospace company working on a large satellite program.
As to the how, consider that if finding good software engineers is hard (debatable), finding them with clearances is even harder (definitely true). The interviews for defense and aerospace jobs are easy compared to your standard technical interview at Netflix, Google, et al. They really don't want to risk screening folks out for trifling things like "competence" when they have billets to fill (because they're selling man-hours of labor to the govt, even a mediocre engineer can be profitable).
But you should also know, that while working on a large satellite program may sound cool, the maddeningly slow and byzantine bureaucratic development processes (I'm currently on a waterfall-driven project) inherit in such programs will suck every last ounce of joy out of your working life. So, there's that...
And yet I’m constantly surprised by people knowing nothing of set theory. Occasionally someone who doesn’t know logic (evidenced by nasty, over-complicated Boolean logic)
Or my current favorite: a very senior and very optimistic person who apparently doesn’t believe in decidability, the halting problem, or NP completeness.
Like, they think computers are just invincible problem solvers, or can't even really comprehend the question? I can't grok what it means to not believe in NP completeness.
That developers can do anything if we stop complaining and get to work.
No, in fact we've proven there are a lot of things we can't do, and oceans of things that are theoretically possible but completely impractical to do (another class of people mistake intractable for impossible, but for small enough N sometimes it is both possible and worthwhile).
> Or my current favorite: a very senior and very optimistic person who apparently doesn’t believe in decidability, the halting problem, or NP completeness.
Undecidability and the halting problem is usually analysed for Turing machines (I am aware that there also exists literature on these problems for other types of automata). The problem is: It is impossible to build a Turing machine. Every computer that has been built up to know is just some kind of finite state machine. So the halting problem is perfectly (in a mathematical sense) deciable for real computer programs. The problem is: We have no idea how to do this in general in a timespan that is suitable for practical purposes.
IMHO you need just enough to be comfortable using math as a tool applied to your particular every-day practical situations, but you don't need to go into the academical depths like e.g. a scientist would have to. And you also need to have at least some faint idea what are the available options, so that, if needed, you know what to google for.
I'm not sure that's true. I think it's pretty tough for somebody who doesn't understand a field to assert that understanding the field deeper is not necessary.
You'll see many non-programmers assert that it's not necessary to get trained programmers to do a certain task (say, automation). However, they don't understand all the software engineering considerations and issues that you'll run into if you don't have a programming background.
It's only when you truly understand a field that you can see when that field is applicable to the task at hand.
When you say "field", do you mean algebraic field, or professional "field".
I suppose "professional field" here, even though the other interpretation seems more fun.
Yeah, I'll never tell someone not to learn something for the sheer enjoyment. But this article is downright pretentious. It gussies up a lot of simple day-to-day tasks with off-putting terms and would not be helpful to a beginner.
The secret to linear algebra is homogenous coordinates together the exterior algebra. plus matrices sprinkled in. If you use those for everything all your problems simply disappear.
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.
This. I believe we are ripe for another leap in math education, or at least computer science education. A new approach to teaching that in a generation will make current methods looks like rhetorical algebra.
I think this is a great example: https://github.com/Jam3/math-as-code
That page is a sort of rosetta stone for me after years of learning to code while also struggling with math notation. I find a similar fog lifts when I look at set theory through the lens of SQL and relation databases.
It amazes me that we still can't clearly demonstrate to children why math is important and instantly and universally instill a love and curiosity. Instead we have unforgiving educational models that are "well, you either get it or you don't."
It angers me to think of all the potentially _effective_ programmers who get their dreams squashed because they can't pass Calculus II (or other prereq.), and thus are literally not allowed to enroll in a programming course.
I didn't know about Karnaugh Maps but I use truth tables constantly in the design phase of tasks. Thank you very much for this. If you've found other tools like this please share. Not really related but for requirements I find gap and SWOT analysis to be vital tools as well as weighted pairwise comparisons. Throw in some UML diagrams and I start feeling good about things. These things impress far more people than they should.
</rant>
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.
So, are you still afraid of math?
No. Post-college, I didn't need it for my job and I discovered programming - at least at the level that I was enjoying it - was as much, if not more, about logic and breaking problems into pieces. Despite that my lack of math ability felt increasingly like an albatross around my neck. In the same way that one might feel they're missing out by not studying history.
It was only after coming across a quote from Charles Darwin where he mentioned that one of his regrets was that he didn't study math more thoroughly. And that because of that there were entire "conversations" he was missing out on. For some reason I found that both liberating and motivating.
"Me and Charles Darwin, we're not so different you and I." ;-)
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.
Programmers use tons of math, they just don't recognize it. Partially because you can still come out of even a bachelor's program in computer science and still think "math is just about numbers", but some of it is also just excessive familiarity and not realizing the easy things that you're doing that are actually mathematical because school trained you that Math must be Hard and you have to be Sitting There and Thinking Very Hard or you're not Doing Math.
Every day I'm using mathematical reasoning such as "I reached this line of code, and since this is a structured program I am guaranteed that this variable was initialized by the time I got here", "this function can only return either a non-empty string XOR an error and has nowhere it can throw an exception so if I handle those two cases I have fully handled everything this function can do", "the error string has the username in it, and values like that must come from somewhere, so even though I've been looking for an hour and can't find it, mathematically the thing generating the error message must have access to the username", "if I construct this as a pure function that does no IO, on the flip side, no users of this function will have to worry about what errors could arise during IO, reducing the mathematical cognitive load of using this function for users".
Then you start stringing together those steps by the dozens and hundreds and thousands and millions (and you get qualitative differences there too, but those don't fit into a little post like this anywhere near as well), and you can build software.
You don't have to realize you're reasoning mathematically (proof: look around), but you're leaving useful tools in the toolchest if you don't. Even if you won't believe me about building systems this way, I can assure you those magical stories about people who can debug systems at a glance that have defeated others for hours or days comes back to someone who either formally or by experience has a fairly mathematical understanding of the system in question and was able to apply some sort of logic, even if only intuitively, to arrive at that conclusion.
But that's mostly logic, at best mathematical logic. I don't think anyone formally reasons when writing code anyway, we mostly rely on intuition. Maths isn't about numbers but it's not about intuition neither.
Programmers doing actual math would be modeling problems and creating proofs for their solutions. Usually we clasify those problems based on the field of math we use to model them.
Saying we do tons of math implies we use a lot of knowledge from a lot of those fields. But most of the time, programmers use only the introductory notions of those fields. We are usually guided by a domain expert anyway so that the math part is correct.
Programmers don't use a ton of math. They use some math.
I think most modern mathematicians would be taken aback if you told them logic is not math. You might be surprised what some logicians have gotten up to.
And sure, if you define what I talked about as not math, then you don't use math. If you don't want to use the tools of mathematical thought, be my guest. It's one of my competitive advantages in the marketplace.
But I think Dijkstra would be pretty surprised to hear that structured programming wasn't math, and you might be interested in budgeting six months or so to play with Coq or something like it, where you'll learn that the difference between proving code and what you do in just trying to make code work and debug code is much more a quantitative difference than the qualitative difference you think. There's no magic in how code proofs work... it's the same processes you use all the time if you code at any scale beyond a single screen of code, just taken to their logical conclusion.
Propositional logic / zeroth-order logic is like arithmetic. You didn't consider numbers (by which I gathered you meant arithmetic) as math, and I'm the same in saying this type of logic is not math.
Logic is a VAST field, and most programmers don't get to use most of it, that was my point.
I already played with Coq (that feels weird to say :)) ). It is a very specialized tool useful in very specific cases. I don't think it will ever be adopted as the standard way of programming since it's really unproductive.
Just because you use math that is really heavy does not mean you understand the math behind completely. We can view a ball throw as a complex quantum-mechanical physical process but we don't call ourselves theoretical physicists for being able to throw a ball.
Some of your points remind me of Underwood Dudley's 2010 article "What is Mathematics For?" [1]. Briefly, he argues that we greatly exaggerate how much math you actually need in most jobs that people usually think of as needing math, but nevertheless learning math is worthwhile and important because of what it teaches you about how to think.
[1] http://www.ams.org/notices/201005/rtx100500608p.pdf
I agree. It's (usually intuitively learned) reasoning that's very similar to the logical reasoning of mathematics. I think if you were to study, say, calculus in a manner typical of a first course in college, you'd be missing out on that sort of problem solving, but you'd definitely get that if you took a proofs-based class in analysis ("This function is continuous on this interval, so it must have a maximum. How can I use that to prove what's being asked?").
> 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.
So there's some funny folklore regarding this...
http://www.ibiblio.org/harris/500milemail.html
> 1) Learn math as necessary for a field you're interested in
I think this a Rumsfeldian problem: you can address the known unknowns, but what about the unknown unknowns?
There's no great answer to this, and it's why I think the original post was advocating the broad fields of math.
Just knowing math exists, though, doesn't address the depth to which you study it. I've gone at monads about five times now and I think I get it, to where I see why a promises library works the way it does. Same with databases, learned SQL, then stumbled across the wonderfully cranky dbdebunk.com, read Date's book, finally spent some months working on an implementation of the relational algebra and finally grokked it.
The problem with some of these deeper subjects is you'll have many "aha" moments only to look back at your early "ahas" and realize you had no idea what you were doing.
I'm not so sure. Programming is isomorphic to mathematics (via logic) as proven by the Curry-Howard Correspondance, and so is not just applicable to ones problem/industry domain—it's applicable in a much more general sense. In my experience, the learnings on both sides of the coin filter back to the other in surprising and often highly insightful ways.
> Most working programmers won't have to know any math beyond arithmetic.
If your job is to write code that moves information back and forth between a database and a web page, this may be somewhat true. However, once you get beyond that to the point you are actually solving problems in code (not just moving information) you are going to need math beyond arithmetic. Algebra, boolean logic, and statistics are just a few things programmers use all the time--almost to the point that they may not think of them as "using math" because it is just built into the way they think.
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]