Do software engineers need mathematics? (2000)
1–10 of 41 posts
Re: Do software engineers need mathematics? (2000)
#2Good article. I would just add that Philosophy classes especially the more abstract 19th (Kant, Hegel, Schopenhauer, Nietzsche) and 20th century (Heidegger, Foucault, Mearleu-Ponty, Wittgenstein) philosophers are fantastic and often under appreciated tools for gaining deep abstract thinking skills that mathematics didn't teach me. Often times I've drawn on the modes of thought acquired from learning to read them when solving particularly difficult problems in software design and engineering.
Re: Do software engineers need mathematics? (2000)
#3I don't really buy it. I think practice with tackling bigger and bigger problems teaches you more about the need for the specific kinds of abstractions that are most useful for SE. When you get to problems that are too big to fit entirely in your head, you start realizing the absolute necessity for hiding implementation details, and when you work over time with other people using your code, the similar necessity for limiting the flexibility and expansion points in the libraries you write - i.e. not making things too abstract, in many cases.
So much of abstraction in SE is about chunk size - what's comfortable to fit in your head when thinking at any particular level - and minimizing surface area between modules, where enough experience with a wide selection of APIs to develop good taste is important.
Whereas I see a lot of mathematics as being about eliminating redundancy, seeing connections between things and reducing them to their most orthogonal and best factored form, with the minimal number of concepts; but with not a whole lot of concern for complexity specifically. The same approach applied to SE can be useful, but mostly only in central libraries that have the widest variety of uses. I'm thinking of collections in particular; there, you want a wide selection of querying and transformation primitives to make arbitrary data manipulation problems easier to express. But most libraries and APIs don't benefit from that kind of factoring; they are best approached from a UI perspective, looking at use cases and building in affordances that make all the common cases trivial, while making the edge cases possible. This makes them lop-sided and redundant, and probably would offend someone with a heavy mathematical orientation.
tl/dr: mathematical thinking is roughly the right kind of thinking, but practice of reading and writing code teaches thinking that's a better fit.
Re: Do software engineers need mathematics? (2000)
#4I don't really buy it. I think practice with tackling bigger and bigger problems teaches you more about the need for the specific kinds of abstractions that are most useful for SE. When you get to problems that are too big to fit entirely in your head, you start realizing the absolute necessity for hiding implementation details, and when you work over time with other people using your code, the similar necessity for…
Reading and writing code does not teach you recursion. Certain abstract ideas fall into the domain of mathematics even if you can pick up some of them outside of a formal mathematical education.
Re: Do software engineers need mathematics? (2000)
#5I don't really buy it. I think practice with tackling bigger and bigger problems teaches you more about the need for the specific kinds of abstractions that are most useful for SE. When you get to problems that are too big to fit entirely in your head, you start realizing the absolute necessity for hiding implementation details, and when you work over time with other people using your code, the similar necessity for…
Reading and writing code does not teach you recursion. Certain abstract ideas fall into the domain of mathematics even if you can pick up some of them outside of a formal mathematical education.
Reading code using recursion certainly does teach you recursion.
Classification of ideas does not lend the classifier ownership over the idea. Ferns were around long before mathematicians.
(To a certain degree, I'm taking a devil's advocate position. I'm not arguing against the worth of mathematics. But not a lot of SE requires much mathematics; what I am specifically disputing is that teaching a lot of abstract mathematics necessarily results in a better software engineer than deliberate practice. Solving simple combinatorial, tree and graph search problems teaches you more about the practical uses of recursion than any amount of recurrence relations, IMO.)
Re: Do software engineers need mathematics? (2000)
#6Depends on what you're doing.
I've used calculus for physics simulations in games.
I had to do a bunch of performance analysis, and a little bit of knowing what distributions actually meant helped a lot. I regret not having taken more statistics in college.
I was talking with a philosophy prof once, and somehow we got to DeMorgan's theorem. "I use that nearly every day," I told him, and it kind of floored him -- apparently he considered it "advanced" logic.
Re: Do software engineers need mathematics? (2000)
#7Earlier quoted context omitted.
Reading and writing code does not teach you recursion. Certain abstract ideas fall into the domain of mathematics even if you can pick up some of them outside of a formal mathematical education.
Reading code using recursion certainly does teach you recursion. Classification of ideas does not lend the classifier ownership over the idea. Ferns were around long before mathematicians. (To a certain degree, I'm taking a devil's advocate position. I'm not arguing against the worth of mathematics. But not a lot of SE requires much mathematics; what I am specifically disputing is that teaching a lot of abstract math…
I immediately rethought my assertion when I submitted but left it for argument. Like Picasso saying "computers are useless" to encourage deeper discussion. Mathematics lends rigorous proof, like with an induction proof. It takes a level of abstract thinking to decipher recursive code, the kind of training helped by a mathematics education. Software programming gives you exposure to existing abstractions but direct mathematics training gives rigor to developing new concepts. University disciplines, within the university, do have ownership over domains of knowledge. So computer science is really math and engineering.
Like philosophy, mathematics is about ideas. Understanding the underlying philosophical and mathematical ideas are enlightening and often practical. Benefiting from understanding these ideas or methodology does not necessarily mean I have to be good at the level of philosophical writing, or solving proofs.
Re: Do software engineers need mathematics? (2000)
#8Interesting. Ultimately just one person's opinion. I don't use any college math (since I didn't take any) and dont't find a need for it in most programming. In fact, programming is a lot more like writing. Maybe that's why they call it a programming language. Too bad when I was doing programming using more interesting math, more interesting math was not taught in school (US 7th grade and on)
Re: Do software engineers need mathematics? (2000)
#9Earlier quoted context omitted.
Reading code using recursion certainly does teach you recursion. Classification of ideas does not lend the classifier ownership over the idea. Ferns were around long before mathematicians. (To a certain degree, I'm taking a devil's advocate position. I'm not arguing against the worth of mathematics. But not a lot of SE requires much mathematics; what I am specifically disputing is that teaching a lot of abstract math…
I immediately rethought my assertion when I submitted but left it for argument. Like Picasso saying "computers are useless" to encourage deeper discussion. Mathematics lends rigorous proof, like with an induction proof. It takes a level of abstract thinking to decipher recursive code, the kind of training helped by a mathematics education. Software programming gives you exposure to existing abstractions but direct ma…
Unfortunately, very little of software engineering involves new concepts; and when they are introduced, it's often ill-advised. It's usually better to build something out of two or three well-understood ideas that have stood the test of time in the industry than a single novel one, even if it's a lot shorter and less work for the initial implementer. There will be later maintainers who may not have had as much invested in their experience and training, and it's normally better for whoever is paying the bills that specific and exotic skills are not required on a continual basis.
New ideas really pay off when the constraints are such that conventional composition of existing ideas won't work well. But those situations are rare.
It might sound like I'm arguing against talented software engineers, or against education, training etc., but really it's just business pragmatics and economics.
Re: Do software engineers need mathematics? (2000)
#10The best part of mathematics is learning how to reduce something into a solved instance of something else. Recognizing when things are the same in abstract. Very hard to do.
As for the question. In english we have many words for those people who work on buildings and even cars because both go back thousands or hundreds of years each. So we have janitors, masons, carpenters, plumbers, architects and civil engineers. Each word clearly delineating a different expertise and scope.
Cars are newer so we have mechanics, automotive engineers and mechanical engineers. No one asks if the mechanical engineer or the mechanic needs math. The answer is obvious and contained in the Words. Electricity is from about the same time as cars and it too has electricians and electrical engineers. Not as many as houses but no doubt with more variations than common vocabulary implies.
Software has words like programmers, computer scientist and software engineer that are overly broad, ambiguous and interchanged indiscriminately. Leading to arguments about what really should be tautologies. I expect in time there will be terms like plumber, detective, architect, scientist, archaeologist and engineer for software and they will all mean something. And the subject will no longer be new and such questions will no longer be asked.
EDIT: I'd also like to chime in for it depends. If you are building a CRUD website it depends. For example: It depends on if you want to A/B Test your site in a non cargo cult manner. It is important if you want to compare A/B Test to multi armed bandits within a general framework. In general, you can only know not enough math.