I have only studied up to real analysis. But definitely not a whole semester worth; my experience with analysis has been analogous to Poor performance in a quarter based analysis course. I did some exercises but not many.
I have heard from an mit professor[1] that math is the way to learn to think rigorously. So I’m curious about this and I’d like to improve my thinking skills in the hope that I will become a better programmer.
In an article a math professor said that there was some evidence that math improved logical skills[2].
So I’m wondering if any of you noticed that your thinking skills improved thereby making you a better programmer after studying analysis or topology or some other proof based math course.
Also which math other than the math required in CS programs should one study to be a better programmer and thinker? Thanks [1] https://m.youtube.com/watch?v=SZF0MFm9pqw&pp=ygUTQWR2aWNlIHJ1c3MgdGVkcmFrZQ%3D%3D [2] https://www.nytimes.com/2018/04/13/opinion/sunday/math-logic-smarter.html
Now I mostly do full stack web development (I have goals that require doing it), and I do often think about my programming informed by intuitions from topology and algebraic geometry (e.g., scopes in programming are like neighborhoods in topology). Having experience with formal logic and proofs also helps in reasoning about what code I'm looking at will do. Experience with rigorous mathematics also makes me more humble about just how difficult it is for anybody to ever reason correctly about anything.
I taught mathematics to many undergrads over the years, and I would recommend anybody interesting in a career in programming also learn at least the basics of group theory and abstract algebra. It's extremely beautiful, and probably different than the other mathematics you encountered, e.g., in high school or engineering courses. There's just so many beautiful and deep ideas in an intro abstract algebra course that aren't very difficult to learn. I initially got into mathematics when I was an undergrad browsing the programming section of a used bookstore, and found an abstract algebra book that was misfiled in the programming section.
I was long considered "bad at math," a thing my dad said about himself* and an excuse that I readily took on when I got bad grades. I got a career in web development straight out of high school, and that carried me for several years until I got bored and resumed community college classes for enrichment. I took calculus and a beginning algorithms/data structures class my first semester. At the time, I still wasn't ready to jump back into calculus, and only showed up to the algorithms class. I was intrigued -- proofs had a direct application to my life! Later I would realize that programming taught me the basics of rigor and abstraction in a language I was willing to hear.
Thus began my mathematics career. I always had one foot in the computer science, and one foot in the mathematics. The proofs I saw in analysis were... fine, I guess, I got good grades because I did my homework with enough time to focus on it. But William exposed me to a world of computational mathematics that really carried my interest. From there, I learned new classes of algorithms, hairy implementation details, and more. My experience there was incredibly beneficial to my programming experience.
So my path was crooked: programming, then math, then back to programming. It is undeniable that these skills are heavily intertwined. Even if that undergrad analysis course feels like an inapplicable stumbling block along the way. Most mathematicians I know only used calculus to hone their symbolic manipulation skills.
* parents: watch your &$%&@@&$ mouth
Do you have a suggestion on how to get into real math?
Could taking a class in Abstract Algebra be a first step? I've thought about auditing the class at a local college, but the syllabus scared me. Groups? Rings? I've never heard about these things in any class.
Any suggestions?
Abstract algebra has little prerequisites, so you can definitely do that. However, if calculus clicked with you, then you may find real analysis more to your liking. If you've done enough physics/engineering that requires calculus, you probably won't have trouble connecting the analysis material to your experience.
For me (engineering/physics), abstract algebra was ... abstract. It felt like a bunch of abstract ideas and structures that mathematicians invented to occupy themselves. Of course, that's not at all true in reality, but it was mostly irrelevant to my real world problems.
PS: If you've forgotten your calculus, don't worry - most real analysis courses/books start from scratch and don't assume prior knowledge.
You might also consider taking a proof-based course in linear algebra.
For the things I've programmed, I barely needed any math. I found it more beneficial to study things like systems architecture and computer science. Knowing theories behind data structures, functional/imperative programming, algorithms, networking, file manipulation and more, that was the sort of thing I studied and exercised in my programming days.
For the record, I programmed Unix systems and services in C, Bourne shell, Perl, and similar languages. That was my professional career. Of course I got a real early start with BASIC, LOGO, and a little bit of assembly.
I understand that countless engineers have this opinion, but really (and bluntly) all it means is that you’re unaware or ignorant of how maths applies to what you’re doing.
I disagree.
I am aware of trigonometry, for example. Sines, cosines, tangents. Circles, curves, parabolas. Degrees and radians. None of that stuff is even encountered in systems programming.
Calculus I know. Derivatives and integrals. Rates of increase and decrease, acceleration, calculating areas and volumes. Totally unnecessary for systems programming. Or is it? Of course, if you're into profiling programs, taking metrics, observing historical trends, then you'll need calculus to make sense out of that type of monitoring data. But if you're slinging code to make an authentication server work, it's irrelevant.
Now, the math that I have handled in programs is basically integer operations. Floating-point math is likewise nonexistent in systems programming. Simple arrays in one or two dimensions, usually. Pointer arithmetic and making sure you're dereferencing the right thing. Bitwise logic with AND, OR, XOR. Different numerical bases: binary, octal, decimal, hexadecimal; converting among those formats and reading them in and out. Exponents, certainly. I learned all the powers of two so early in life!
Again, my background is in Unix systems programming and text manipulation. You just don't need trig or calc in those domains. Not to put a basic program together and get it debugged and deployed, or hack someone else's code.
I think the last time I must have run into trigonometry or floating point in code was in college when I was ftp'ing and installing a bunch of Unix adventure games. Wasn't my code, though; I didn't touch those sections.
And an interesting case in point is LOGO: how do you draw a circle in that language? All you need to do is
REPEAT 360 [FD 1 RT 1]
Now you may protest that knowing 360 degrees is a tenet of trigonometry, but it seems just like common sense to me.I mean, sure, algorithms involve math. If you're dealing with trees/graphs, that's math. If you're compiling a program there is math behind the scenes. But for the majority of SW engineers, actually knowing the math is of little benefit to most problems that SW engineers need to solve. As long as you know the rudiments of algorithmic complexity (big Oh notation, etc), you're good.
(I am excluding trivial things like arithmetic and very basic algebra, as clearly this submission is speaking of more advanced math).
If you enjoy math, go do some math. It might help you see problems differently. If you don't enjoy math, don't grind through it.
In general, the best advice for the question "I want to get better at $skill, should I study $subject?" is "just do $skill"
I disagree. If the you'd answered an aspiring engineer with "your time is better spent on challenging engineering problems" then, at the level the asker of this questions seems to be at, that would not be the best advice. A person could bootstrap their ability much faster by studying first (or concurrently) other subjects as well.
I think the same applies to programming. I don't have a strong opinion on proof-based math in particular but "just do $skill" is a large oversimplification glossing over the fact that most skills require at least some subject matter knowledge that is a precursor to performing the skill, either because it's necessary in itself or because studying the subject instills some transferable skills as well.
In the case of proof based math, one skill you learn is how to begin things, or break them down, to first principles and build up from there. That's extremely useful for programming, or problem solving in general. You can learn it in different ways, not just from math, but learning it through math or some other subjects are much more direct paths to obtaining that skill, if you don't already have it, than jumping only into programming.
Exploring adjacent skills/subjects can have tremendous value!
I tell them it's not about math, you just have to think logically through every step.
With more steps comes more scrutiny, so you study how to optimize.
You will read papers about optimization to reduce the number of steps.
Those papers have a suspicious amount of math.
By the time you discover, "...wait, its all math?"
"Always has been."
What I personally found helpful was the book The Algorithm Design Manual [0]. It starts right off with math, but in a way that connects it to basic primitives of programming. You start building up an algorithmic understanding as you increase the computation complexity. It was very intuitive for me, both for understanding the math and understanding Big O in a rigorous manner. From there it dives into actual algorithms and code, but the math returns periodically.
[0] Had plenty of books to select from. Kenneth Rosen's was the only one I liked. Knuth's Concrete Mathematics is great if you decide to give a subject a second go -- the material is somewhat different, more abstract, and the side notes by his students are hilarious.
[1] https://www.mathsisfun.com/puzzles/5-pirates-solution.html
Doing a lot of math definitely helps you think rigorously. Doing programming forces you to think rigorously.[1] So it's not clear if math is a value add in that direction.
I think the only way math has helped me is that mathematicians tend naturally to think "functionally", so for me switching from C/Python to more abstract functional programming (be it in Scheme or ML based languages) was fairly easy. In fact, I was already trying to program functionally in Python before I knew what that even meant.
On the whole, I would say: Study more math if that's what interests you - but not with the expectation of becoming a better programmer.
[1] See also my prior comment that discusses a Field's medalist's comparison between math and programming: https://news.ycombinator.com/item?id=36344681
Would that it were so! But alas a lot of software is happy-path only because many programmers don't tend to think mathematically. In contrast mathematical proofs tend to be absolutely bullet proof.
I can only assume that the mathematician who wrote the quote in your footnote was talking about maths notation vs computer language syntax. In that narrow sense, yes programmers need to be more careful. But software doesn't need to be anywhere near logically correct to run, and he seems to agree that in fact it never is correct.
In contrast, logical errors in published mathematical proofs are relatively rare.
They really, really do not. It's why an initial proof of the four coloring theorem was believed for a decade before a flaw was discovered. History has quite a few examples of proofs believed to be correct for years that turned out to be flawed.
Read the quotes from William Thurston's essay in the comment I linked to. I've spent time with professional mathematicians, and they say that finding errors in papers is not at all unusual - I've seen estimates as high as a third of papers have an error.[1] This doesn't concern them as even though there are errors, they have good reasons to believe the correctness of the theorems and freely will use them as references to their own work. Thurston's essay goes into detail as to why that is.
> I can only assume that the mathematician who wrote the quote in your footnote was talking about maths notation vs computer language syntax.
While the quote I supplied was in the context of notation, the essay addresses the wider issue.
> But software doesn't need to be anywhere near logically correct to run
Indeed, and his analogous statement is that proofs don't need to be completely correct to believed :-)
I believe he cites Wile's proof of Fermat's theorem. At the time of writing, he had presented his proof and a flaw had been found - the fixes came after his essay. So at that time, he knew the proof had problems. Yet he points out most people believed that Wile's approach was correct, and resolving the problems in his proof were a matter of detail. This wasn't a matter of faith. Those mathematicians understood the theory Wiles used well enough to have a good intuition that the reasoning was sound. It was certainly challenging to resolve the bug(s) in his proof - the Wikipedia page indicates he almost gave up. But I suspect that had this been a less dramatic theorem, the pressure to fix the flaws would not really be there.
Of course, at times that intuition turns out to be surprisingly wrong. But those tend to be the exceptions.
[1] This link points out that about 1.4% of published papers have corrections: https://mathoverflow.net/questions/291890/what-percentage-of...
However, I believe that most flaws that are found are not corrected (i.e. the author doesn't bother sending in a correction).
Here is an anecdote from Kevin Buzzard, who is a proponent of formalizing proofs using computers:
> It is true that there are holes in some proofs. There are plenty of false lemmas in papers. But mathematics is robust in this extraordinary way. More than once in my life I have said to the author of a paper "this proof doesn't work" and their response is "oh I have 3 other proofs, one is bound to work" -- and they're right.
...
> But until then I think we should remember that there's a distinction between "results for which humanity hasn't written down the proof very well, but the experts know how to fill in all of the holes" and "important results which humanity believes and are not actually proved".
Taken from https://mathoverflow.net/questions/351640/extent-of-unscient...
Lean (proof assistant) https://en.wikipedia.org/wiki/Lean_(proof_assistant)
"Lean mathlib overview": https://leanprover-community.github.io/mathlib-overview.html
"Where to start learning Lean": https://github.com/leanprover-community/mathlib/wiki/Where-t...
leanprover-community/mathlib: https://github.com/leanprover-community/mathlib
I do believe that having some baseline ability to think carefully, logically, and rigorously, while being able to shift your perspective between levels of abstraction as you analyze a problem, is very useful as a computer programmer, but I don't think mathematics is the only route (or even the best route) to acquiring that skill; I've had a number of colleagues over the years with no formal training or education in any sort of "STEM" field who were nevertheless quite adept programmers.
At the end of the day, based on both my own experience and what I've observed in friends and colleagues, the way to become a better programmer is the way to get better at most things in life: do a lot of it, find other people who are good at it and get their feedback, and stay humble enough that you'll be able to learn from your mistakes and change your thought processes. But mainly just do a lot of it.
That's not to say you shouldn't learn some serious math, of course: there's a lot of cool and interesting stuff to learn, and some of it even has useful applications. But the thing you get good at when doing math is, well, doing math, and if you really want to be a better programmer, your time is likely better spent writing software.
I switched my major from CS to math midway through my undergrad studies. I have worked at startups and FAANG as a SWE so I have seen these skills in different engineering environments. A few things I’ve seen:
1. My later classes used the Moore Method which made whiteboard interviews much less stressful 2. I can spar with our data scientists and call out BS metrics rigorously in a very political environment at my current company 3. I can sometimes find pathological execution scenarios and bugs faster than my CS coworkers
The one caution is that time spent studying things that aren’t programming needs to be balanced with time spent programming
As for math outside of CS that’s helpful for programming and thinking, modern algebra and category theory can really help in understanding type systems and their limitations. They’re also very accessible when compared to stuff like differential equations and analysis IMO
I think that those two things are useful mental models to have when learning programming, things that would be useful to have more as built in patterns than thinking step by step. And in that sense is useful to have a background in math. Maybe it doesn’t need to be too advanced, but at least at the level of thinking naturally in that way.
I am doing the opposite of what you are asking, as my day job is a mathematician, and I found my hobby of programming sometimes helpful.
Having a basic understanding of math can provide some value. For example, things like understanding Big O notation, or the fact that algorithms can be proven at all. Stuff like that provides you the right tooling to select the right algorithms for your problem.
However the actual proving part is mostly busy-work, and due to the Halting problem provides relatively little value in general programming. It might be useful if you want to develop a compiler or something, but most people don't.
Proof-based maths is the main reason why I dropped out of my Computer Science M.Sc. course. After a while it became painfully obvious to me that it didn't teach me anything I could actually use as a developer, and it was a waste of time if I didn't want to go into academics.
You'll learn more about programming by actually doing programming.
Not really sure about "better programmer", but I think it makes you at least more logical and helps develop a keener attention to detail. "Better programmer" entails an array of many other qualities outside of the scope of "better thinker".
Then my first programming class, in BASIC (in 1981), was taught by my high school math teacher, so there was a math perspective, plus my love of math probably biased my interests in programming. Today, I'm not employed as a programmer per se, but use programming and math as problem solving tools as a physicist.
I know programmers who are great at math, but most are not, and the ones who are take care of the math stuff in a team. Likewise with most engineers. So I'm hesitant to claim that math is a particular boon to learning programming. Rather, it is or it isn't, and that might influence what kind of programming you get into.
Like Joel Spolsky's article about programmers, I think there's a two humped distribution in terms of ability to grasp proof based math. If you discover by accident that you have a facility for it, then you might just try a few more courses because it's a boatload of fun.
https://blog.codinghorror.com/separating-programming-sheep-f...
Then it got a bit of reinforcement in my honors "1st semester calculus but we're proving everything" course.
How crucial it is for you to be able to accurately analyze large logical systems depends on the kind of programming you do. In many cases, it isn’t that important. I think I being comfortable with ambiguity, understanding how to satisfy multiple conflicting constraints, how to be political, etc. are probably much more valuable skills. Many programming jobs simply do not require you to be that technical to get your tasks done.
If you asked me to describe a 'better programmer' in a professional setting, it would probably be:
* writes understandable code
* knows when to optimise/dedupe /abstract, and more importantly, when not to
* treats it like a craft, but knows that pragmatism is also key
* can communicate about code, explain concepts and just be generally helpful and pleasant to others in or outside the team
Thats IMHO anyway, and those things don't seem to have much to do with math.
Is “better programmer” a useful metric to problem solving? For a class of problems, probably.
Math and other hard sciences will probably give you a different perspective than a traditional CS education which may help with solving certain types of problems. Those may be programming related, or may be something else. Of course it may depend on the kind of person you are too.
In my opinion it’s worth pursuing whatever feels hard in terms of education, even if there’s not a rigorous CS education. You can always go into CS later.
I'd say studying mathematical proof is helpful for developing your proof making skills, but then it is best largely forgotten after you've internalised those skills.
Imo you learn the academic lingo, and it can make it easier to communicate with other programmers, but you can just pick it up. School is for chumps.
If you have a choice, I'd rather spend the time further studying algorithms and data structures instead of proofs. There's a ton to learn, and working through algorithms in pseudocode is always useful.