Ask HN: Did studying proof based math topics make you a better programmer?

[jobhdez]

Hello, Hope all is well. I love math but haven’t studied much of it.

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

[williamstein]

I received a Ph.D. in pure math (number theory) from Berkeley, and then worked as an academic mathematician for 20 years, so wrote a few dozen research papers and some books. My ability to write software for doing mathematics was obviously better as a result of studying mathematics, e.g., I started SageMath (https://sagemath.org) and wrote a big chunk of it.

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.

[boothby]

Responding to William here because I was once a student and collaborator of his.

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

[copperx]

I've always been intrigued by higher math, but I never got further than Calculus III, differential equations, and proofs by induction in discrete math.

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?

[BeetleB]

If you've already done diff eq and calculus, you're ready for real analysis.

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.

[bkallus]

Taking a course in abstract algebra is a good first step. A first course in abstract algebra is supposed to introduce you to groups and rings, so you won't be out of place.

You might also consider taking a proof-based course in linear algebra.

[ekm2]

You did a PhD in number theory,but you are recommending group theory and abstract algebra?

[bordercases]

They overlap in part because the latter two topics are used to abstract over any mathematics.

[jobhdez]

wow -- thanks so much. I will learn group theory and abstract algebra. thanks

[JamesLeonis]

I lie to people about programming all the time.

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]: https://www.algorist.com/

[stodor89]

I went through Algorithm Design Manual before learning Discrete Math[0]. Suffices to say, I had plenty of these "always has been" moments you're talking about :) The book is great at explaining algorithms, math prerequisites and all. Then you try the exercises, and they leave you with a subtle feeling of "hmm, perhaps there's more to this algorithms stuff". As an example, perhaps the first time I got this was in chapter 1, when I encountered the greedy pirates puzzle[1].

[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

[jdlshore]

There’s a lot more to programming than algorithms; so much so, in fact, that I’d say that the sort of algorithm optimization you’re talking about is one of the least important skills to study.

[nimih]

I have an undergraduate degree and a couple years worth of graduate school in pure math (and continue to read/work through math texts on occasion when the urge strikes me), and can say with pretty high confidence that my ability as a programmer over my life has been relatively uncorrelated with the amount of math I've learned and my proficiency with understanding and writing mathematical proofs.

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.

[ivanech]

If your goal is become a better programmer, your time is better spent working on challenging programming problems.

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"

[ineedasername]

>If your goal is become a better programmer, your time is better spent working on challenging programming problems.

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.

[xcv123]

If you want to get better at DSP programming, then you will need to study calculus, complex variable theory, linear algebra, and linear systems theory. There is such a thing as pre-requisite or foundational knowledge.

[epgui]

That’s also how you end up with a narrow mindset and limited value-add.

Exploring adjacent skills/subjects can have tremendous value!

[mattbgates]

I never studied any type of math, but I was always great at logic, taking at least a half dozen philosophy and theology courses throughout my univeristy experience. I did take a few programming classes in place of several math courses, just to avoid mathematics... I think my highest math class was Algebra II. I didn't go the route of a computer science major because I didn't care about trigonometry or calculus classes, though still managed to land a science degree of psychology. I can see why college cirriculums may require computer science to have certain math courses, but if you can figure out the logic of how things work, you can get out of math courses and still be a programmer ;)

[jopolous]

Yes, though any subject which trains you to think with mathematical rigor will help.

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

[NoZebra120vClip]

No. In fact, I didn't study any of that. I'm bad at math. I took a required Calculus course (again) about 5 years ago, and struggled mightily, although I did achieve an "A".

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.

[epgui]

> For the things I've programmed, I barely needed any math.

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.

[NoZebra120vClip]

> 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.

[BeetleB]

As someone who has studied a lot more math than CS (including grad level physics and math courses), and does SW for a living, this is nonsense.

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).

[000ooo000]

A developer can barely need maths and also benefit from an understanding of maths at the same time. Unsure what your point is, if not just to dunk on programmers without math backgrounds.

[epgui]

To be clear, I don’t have a math background beyond a handful of undergrad classes (I studied biochem). I just really despise the anti-intellectual attitude of “YAGNI” applied to maths.

[NoZebra120vClip]

What's more anti-intellectual, me explaining why someone might use math as an SWE and what I chose to study instead, or you telling me that I'm "unaware or ignorant" of things I'm quite familiar with?

[gmuslera]

Mathematical proofs are in some way algorithms put in practice. And another useful thing they have is not leaving possibilities out.

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.

[kzz102]

I think "learn B because it will help you do A better" type of advice often doesn't work. But "learn adjacent fields if they are interesting to you, time and energy permitting" may work, as they sometimes do yield unexpected benefits.

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.

[sjruu]

They overlap so much that it doesn't matter too much. Computer science is based on formalist logic. You'd probably get more out of learning breadboard computer engineering.

[markus_zhang]

I'm following Ben Eater's building a 6502 computer casually and it has been a lot of fun. The thought that I can buuld my own computer! That's exciting.

[crote]

No, I would not say it has.

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.

[agomez314]

It did not. Learning git in-depth beats any amount of proof-solving skills you might have in traditional, day-to-day software engineering. Doing proofs makes you a better thinker _in general_, but doing it in isolation (i.e without communication skills or team skills) can actually be detrimental.

[yazzku]

Propositional and first-order logic along with Algebra and basic proofs by induction, reduction to absurdity, etc, should beat the logical, pedantic motherfucker out from your inner self. At least that is what we did at uni -- along with physics, calculus, discrete mathematics, and theory of computation -- but I'd argue the first list should be a sufficient starting point.

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".

[ironSkillet]

My math PhD has helped me be a better programmer in several ways. The first is in terms of reasoning above the behavior of complex systems, which mathematical domains and programs are both instances of. Another is in terms of problem solving via abstraction. Mathematics advances by building new abstractions that serve to encapsulate a set of ideas that can then be reasoned about efficiently and in new ways. The same way abstraction layers in programming allow you to build up more and more sophisticated behavior while "hiding" lower level details and not having to even think about them.

[analog31]

In my case it would be hard to separate cause and effect because math and proofs came before programming. "Back in my day," the public school that I attended had a K-12 math curriculum that included sets, proofs, and problems that had no answer. (You were supposed to write down "no answer"). I was kinda slow at memorizing my arithmetic, but proofs and weird stuff made math come alive for me.

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...

[beyondCritics]

If you are not passionate about it, than you should probably not study it. Also, studying Informatics should give you a lot of opportunities to showcase your extra skills, e.g you can study functional programming from the ground up. IMHO the much more interesting question is: How to cope with the upcoming of AI? This will probably make programming much cheaper and more less skilled people will come to sit right before your nose, tending to devalue higher education.

[colomon]

I think the proof mindseet was a huge help to me as a beginning programmer, BUT that was in the context of high school Euclidean geometry, not analysis, around the same time I was first learning a programming language that let you write functions. As I recall (long time ago now!) the two things kind of fed off of each other very nicely.

Then it got a bit of reinforcement in my honors "1st semester calculus but we're proving everything" course.

[sfpotter]

Learning math helps develop your ability to hold large, complicated logical edifices in your head and to analyze them. There are different ways to develop this skill, doing math is one way to go about it. Programming is fundamentally about reasoning about large logical structures, so the skills carry over. The specific topics may not help, but then again, they might. Learning multivariable calculus and linear algebra will help you if you work in graphics, machine learning, etc. Note that these are huge subjects, and there’s always more to learn—much more than you can pick up in a semester or two at college.

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.

[BeetleB]

I did a lot more math before focusing on programming, so it's hard for me to say.

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

[injb]

>>> Doing programming forces you to think rigorously.

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.

[BeetleB]

> In contrast mathematical proofs tend to be absolutely bullet proof.

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...

[injb]

>>> History has quite a few examples of proofs believed to be correct for years that turned out to be flawed.

>>> I've seen estimates as high as a third of papers have an error.

That is pretty much what I meant by "tend" to be right. If only a third of all the software out there had "an error" that would be a dramatic improvement.

[Madmallard]

Programming is improved by programming. Work on things increasingly out of your comfort zone and slowly grind your way up. Consume all programming related content you can that is written by experts. 5 years later you're much better. It's going to be a lot of mental blood and sweat though.

[wisnesky]

Yes, in the sense that "math is programming paper instead of computers", being better at one translates to being better at the other. This intuition can even be made precise via the "Curry-Howard isomorphism", upon which "proof assistants" such as Coq are built.

[westurner]

Lean mathlib was originally a type checker proof assistant, but now leanprover-community is implementing like all math as proofs in Lean in the mathlib project.

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

[000ooo000]

Not all programming is equal, and there's a big difference between programming alone/as a hobbyist and programming for profit. I think studying most any topic is likely to give one new or interesting perspectives in programming, but the question is: is the juice worth the squeeze?

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.

[prpl]

The problem is the premise of the question.

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.

[dkjaudyeqooe]

Thinking about your code is constructing an informal proof in your mind. Making this more rigorous and thus more formal involves the same trade off of accuracy/ease/speed versus correctness/tedium/slowness that any other formalism entials.

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.

[ldehaan]

I didn't graduate high school and I can program in multiple programming languages, and picking up a new one is pretty easy. I had to convert "math functions" into code before I could understand what the symbols meant when I was learning how to write ML software.

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.

[TillE]

I don't think so. I remember most of my required math (for a CS degree) was proofs, and I mostly hated it. Discrete math was great, and anything else with practical applications in CS would be good too.

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.

[monster_group]

If you want to get good at something, you will get far more return on your time and effort investment if you just practice that thing rather than something tangentially related to it. If you want to get good at programming, practice programming not math. Math may help you but it won't help as much as practicing programming.

[throwaway81523]

Yes, and studying some mathematical logic also helped. Neither math people or programmers really study logic enough. It is a rabbit hole, but just some understanding of the basics changes your whole approach to math.

[mathgeek]

Not generally, although proofs around set theory were useful in grokking databases.