It is often echoed that mathematicians make excellent software engineers, and that their logic-adjacent work will translate efficiently into coding and designing.
I have found this to be almost universally untrue. I might even say the inverse is true.
While I and many of my peers have capacity to navigate the mathematical world, it certainly is not what sets us (at least me) apart when designing clever algorithms and software tricks.
Point being: I dont think the property/trait that makes good programmers is mathematical literacy.
I would love to hear what others experience is regarding this.
I think the same can be said for a lot of fields. E.g., just because someone’s an excellent architect doesn’t make them a good animator by default.
There’s also so many variations on the types of programming. Maybe a mathematician might be better suited for data science rather than frontend stuff. And even then, each person is different and has their own set of skills part from whatever their formal training is.
What I think makes good programmers is having the ability to bash your head against your desk while debugging, but still walking away at the end of the day loving the job and problem solving. Persistence and creativity go a long way in programming.
Yeah, the ability to just sit in that chair until the code problem is solved is something that requires much more than just math… stubbornness+perseverance+bravery to try out some weird stuff
…ahh, you gotta love that head bashing. It definitely helps if you’re masochist.😂
What I think makes good programmers is having the ability to bash your head against your desk while debugging, but still walking away at the end of the day loving the job and problem solving.
Just quoting you for emphasis here, in case any of our newbies missed it. Well said!
I’ve known a lot of math people, and /on average/ I think they’re more capable of programming useful code than the other college graduate groups I’ve spent a lot of time working with (psychology, economics, physics) /on average/.
That said, the best mathematicians I’ve known were mostly rubbish at real programming, and the best programmers I’ve known have come out of computer engineering or computer science.
If you need a correct, but otherwise useless implementation, a mathematician is a pretty good bet. If you need performance, readability, documentation, I’d look elsewhere most of the time.
Mathematicians are good at writing algorithms, but not at the development aspect, which is basically building for different systems, packaging software and documentation.
I would disagree on the performance part, the vast majority of software developers aren’t writing high performance software and the ones that are tend to be computational mathematicians or physicists.
Just because you’re not writing high performance software doesn’t mean it shouldn’t be a consideration. Sure, I’m not gonna micro-optimize memory when I’m writing an API in Python, but that doesn’t mean I’m not going to write it efficiently.
If I have to store and then do lookups on some structured data I’m gonna use a hash table to store it instead of an array. If I need to contact a DB multiple times I’m only gonna close my connection after the last query. None of this is particularly difficult, but knowing when to use certain DSA principles efficiently falls pretty firmly into the computer science realm.
If you need someone to hyper-optimize some computations then a mathematician might be a better bet, but even those problems are rarely mathematician level difficult. Generally software engineers have taken multivariate calculus/differential equations/linear algebra, so we’re decently well versed in math. Doesn’t mean we don’t hate the one time a year we have to pull out some gradients or matrices though.
In my (anecdotal) experience, software is best approached as an engineering pursuit. Almost anyone can write code, but building code that is maintainable, scalable, and reliable has a lot in common with building other things that we want to see similar features in.
There are plenty of math people who are good at this, but there are lots of other fields of study that are just as adjacent (philosophy and communication both come to mind).
I would say, having an affinity for math can be a sign of affinity for programming.
Logical abstract thinking, order of operations, and problem solving all transfer. A for loop is just a summation equation for example.
But id say in today’s high level development, being math centric is less important.
To be good at programming, a lot of knowledge is needed, but “accidental”. From practical ones like how to use git, to conceptual ones like cache performance mental model. It’s perfectly possible that git is designed with a different CLI, or the common cache line size being 512 bytes. Mathematicians usually don’t care about these things, since they are accidental. So they are bad at writing programs that’s far away from math.
It’s a completely different story when they are writing programs about math. If the tool is good enough, i.e. allowing them to express math ideas in familiar terms, mathematicians are very good at writing math programs. As can be observed in Lean and mathlib.
I tend to agree. I think this attitude is something of a holdover from the early days of computer science, when of academics from all the other, existing fields, mathematicians were usually the best fit. Now that we have formal computer scientists, computer engineers, and software engineers, this is no longer the case.
In my experience, when someone from a purely mathematical background tries to program or explain something for programmers, they often (but not always, to be fair) insist vehemently on sticking to methods and algorithms that at best confuse the issue in a programming setting, and sometimes even run counter to how the computing hardware works, reducing performance. In these situations the rationale given is usually something along the lines of, “Listen, we mathematicians have been doing it this way for X hundred years, so that’s the way it should be done!”
I definitely concur. Scientists often write functional but abominable code that follow no style-guide, no conventions, no rules, just “get’er dun” mentality. Short obfuscated variable names, enormous functions, no comments, no build instructions, no tests, no edge case handling, no modules, no separation of concerns, etc.
They often write the most job secure code on the planet.
I get it, it’s because they come from a world of
f(h) = g(h) + i(h) -> assoc = 1
or whatever. Maths, physics, biology, computer science, etc. all have the most obtuse, unvarnished, terse expressions ever. They aren’t teachers (most professors have no didactic training whatsoever), nor do they write stuff that has to be understood by anybody outside of their field.
Especially if people from that field become researchers, only their results and number of papers for their peers count. They spend most of their time getting grant money and under pressure to release something that passes peer review.
Their entire system is more about money than actually expanding our realm of understanding and they are caught up inside of that.IMO, the most dangerous specimens to exit that system are mathematicians as they believe maths is the purest form of science (everything is maths after all), that they are smart, logical, and can solve anything. They treat software development as a practical application of their formulas and, in my experience, see it as beneath them to follow rules they consider superficial.
Code doesn’t have to readable, it has to be correct, functional, and at best pure. It’s why functional languages, especially Haskell, attract them so much. There are those of course who just want something that works and feel like they’re in the rat race of research.That’s been my experience anyway with making code written by scientific minds production-ready (tested, maintainable, documented, functional, extendable). It’s a task I actually do wish upon my worst enemies because I want them to suffer like I did.
For real, though, I wish maths in general, in all fields, adopted the way things are written in programming.
So, instead of something like:
e = mc²
Just write it out:
energy = mass * speed_causality²
And I mean, that’s still a harmless formula. I’ve had to learn so many formulas, where not the formulas were the problem, rather it was knowing what φ means in this field/context. So many scientific papers are just extremely hard to read for anyone from a different field, because the formulas are obfuscated like that.
And the thing is, I get that pure mathematicians don’t care. Their formula inputs usually truly don’t have much of a meaning beyond
a
andb
.
But their conventions, in particular multiplication being implied when two random letters are written next to each other, that just fucks up the option for anyone in any other field to use legible variable names.You’re absolutely correct, and in my experience authors with physics background are even worse.
I’ve seen algorithms that I know by heart, understand fully and have implemented tens of times represented in such a way that I can’t even recognise them.
“So many papers are extremely hard to read because the formulas are obfuscated like that”
This isn’t really an issue though, of you don’t have enough foundational knowledge to understand what the formula means or how it could be conceivably derived, does knowing how it’s calculated matter?
I do think so, yes.
For one, not everyone needs to be an absolute expert. You do want some person with expert knowledge to sanity check what you’re doing, but ultimately you’ll have engineers, programmers etc. that are tasked with putting a formula into reality. If they can intuitively read formulas and more easily read up on the surrounding context, that helps a lot.
In that sense, I may also be very programmer-biased in how I read papers, but generally I prefer to look at a given formula and then read up on why it is formulated like that. Maybe I also have some form of ADS, but for the life of me, I cannot linearly read a paper front to back. And I’m not alone in that.
From computer science papers / academic texts, I know that this method of reading works perfectly fine. But if I try to delve into any other fields, it’s always a matter of first decoding the formula before I can try to figure out what it means.
Ultimately, it just feels like unnecessary hindrance of understanding, even if theoretically you’re just hindering those who supposedly wouldn’t understand anyways.
“From computer science papers/academic texts I know this method of reading works perfectly”
This is almost certainly due to pure familiarity. CS papers are just as indecipherable to unfamiliar persons. Possibly even more since things like complexity are heavily used, without any explanation of what it is. Data structures are another common one that the vast majority of non-CS people would not understand when referenced.
I know because this is exactly how I felt coming from an intermediate mathematics background.
Your first paragraph likely also applies to many senior software developers, especially if they primarily worked in small companies / freelance.
I can see that, yeah.
I’m a mathematician by training who has worked extensively (and exclusively) in the software field. While I realize I’m probably biased here, I think I write very solid code and have rarely received any complaints from trained software engineers about it.
I did however also take quite a few computer science classes in college and have spent a lot of time learning how to write better, more readable and maintainable code. Having had quite a few jobs at the start of my career where I was the only programmer on a project and therefore forced to eat my own dog food has certainly also helped.
Interesting. Im curious, what are some key areas of math that you think is the most interesting/useful for software engineering (that you would personally recommend learning)?
I will likely have some spare time in the following months and i currently plan to spend it on deepening my senses related to linear algebra and analysis.
Yeah, I think you’re already on the right path with that, those are good basics for anything computer science related (and usually required classes if you take CS in college). Perhaps add Numerical Analysis to that list.
Also, Operations Research has some interesting optimization algorithms, and Statistics is useful for anything related to Machine Learning.
I majored in math and have so far a great career in software. I don’t think knowing math separates me out from CS grads generally. However, math majors largely chose to major in Math because we like problem solving. Plenty of CS grads major in CS because they are expected to. Being a passionate problem solver gets you pretty far.
I agree. I think we elevated Computer Science’s importance early on in the industry, and that has stuck around. If you’re a University researcher trying to make a better compression algorithm or whatever, then yeah you’ve got a lot of overlap with mathematicians. But if you’re out in the industry building CRUD apps to fit some business use case, all that theory isn’t going to matter much in your day to day.
It’s still just one of those mostly-bureaucratic hurdles where you need a CS degree to get your first job, and you need to be good at math to get the CS degree.
That said, there are definitely crucial moments where regular projects can still hit scalability boundaries, and a solid understanding of math and CS fundamentals can get you through that. Every single developer doesn’t need to know that stuff, but it’s occasionally good to have access to somebody who does.
Math people don’t have time to delve into modular code with the right amount of encapsulation/abstractions. Their money making is via testing hypotheses by constructing models and experiments.
If you want good code look at people making money writing code.
Maybe you’re confusing engineering with programming.
Although everyone uses both interchangeably, software programmers aren’t more engineer than ‘sound engineers’. Engineers are good at structuring and optimizing. Programmers, though, are much better at finishing the job.
Sound engineers used to basically be electrical engineers.
They made the tape machines, they made the preamps, they made the eqs and compressors.
Working with sound and a band was a side effect.These days it’s a bit more blurry. There are recording engineers that will do maintenance, drive tapes/DAWs, and ensure creatives get the most out of the kit.
There are systems engineers that design and tune PAs for gigs.
And there are sound engineers that can successfully layer instruments so that they are well defined, cohesive, and don’t pile frequencies on top of eachother.I always see engineers (I know it’s a protected term, but the more colloquial term) as “doing more with less within a budget”. Anyone can design a bridge (just pour a huge block of concrete), but only an engineer can design one to a spec and budget (allow ships to pass, be resilient to weather, be maintainable etc).
I’m sure I could throw a couple speakers in a room and get something intelligible sounding.
But a sound engineer will be able to do it in any room/arena, make sure it is loud enough, rigged correctly, has an even frequency response across as much of the venue as possible, and will do it using the equipment available and within budget while producing plans/documentation in advance.
Never mind all the work for doing mic plots, patch plots, RF frequency management, speccing networking and mixing consoles, pre-production to produce show files… There can be a lot.A recording engineer will know mic placements to capture the desired sound for an instrument so it will sit in a mix with as little post-processing as possible, they will know the acoustics of their live rooms, they will be able to maintain equipment, they will know the equipment to put in a signal chain to get a desired outcome and what the desired outcome is (as opposed to swapping/fiddling random kit until something sounds cool).
A mastering engineer will be able to process a song to make it sound consistent across as many speakers/headphones as possible, and they will be able to provide feedback to the recording/mix engineers as to how to improve this (they might ask for stems, tweaks to effects, all sorts). They will be able to produce a version that’s optimised for vinyl, digital, streaming, compressed, radio, television (although, the difference between these has shrunk massively)
Sound engineer is quite a wide term. But it has a lot more skill behind it that a sound technician (someone that can put a lav mic on someone and make it not feedback in a room).
I’d expect someone calling themselves a sound engineer to have in-depth knowledge of one of these things, and enough knowledge of the other things to be able to problem solve, read docs, assist etc when doing them. Basically a specialist with “get out of jail” skills in the rest.
Whereas I’d trust a sound tech to put 4 speakers in a medium conference room, run 4 lavs, 4 handhelds, top table mics, lectern mics, and a few other audio sources. And be able to run it with minimal assistance so it is intelligible in the room without feedback.Probably similar to a software engineer Vs a software programmer.
A programmer can make it work. An engineer will plan it.
Yeah this is generally true in my experience. I have a colleague who is a mathematician, and they write completely uncreative code most of the time, often with logical flaws.
I think Haskell was created by mathematicians and it feels exactly like that: Clever and elegant language, but no normal programmer would stick with it as it’s unpractical to write
deleted by creator