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’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.
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!
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’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.
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.
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 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 = 1or 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.
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.
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.
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.
deleted by creator
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.
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
