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