Got Math?

I agree that "math" per se is not especially important. However, logic is extremely important -- understanding truth values, deduction, induction, etc. Often logic is taught as a philosophy course rather than a mathematics course.

The only math topic (other than logic) I would say I consistently use in programming is what they called "Discrete Math" at my university. It was basically sets, probabilities, graphs, networks, and all of the other fringe topics that the core algebra/geometry/calculus vein doesn't touch on that much. Also, statistics is useful for some people doing number crunching, but I haven't used it too much.

I agree with both, you Amy and Sean.

I think that math knowledge is not a requirement for a good programmer but i think that learning math actually contribute to develop a concise and powerful abstract line of thinking, which is really important to a developer.

Of course, a developer can develop a abstract line of thinking without knowing math but if i had two amazing developers candidates i'd certainly pick the one with a good math background. Not because it knows math but because i'm sure that he can solve issues easily and probably in a more elegant way.

For me, I find it more of the process than the use of math. In both math and programming you are told 'I have A, B and C and I want D'. Your job is to build that black box which you can give A, B and C to and in return get D.

It's being able to visualize a problem and the steps you take to correct it. They're very similar in that regard, but beyond that I wouldn't call it necessary.

I think I'm beginning to fundamentally disagree with the idea that programming is about "solving problems," at least not the kinds of problems people seem to mean when they say that. That presumes that A) there are lots of new problems, B) that the "problem" that appears in front of you is actually the root of the matter, and that C) "solving" that "problem" will result in the success of the overall endeavor (e.g. the application, not just the code snippet).

I think it is extremely easy to win the battle and lose the war.

Almost nothing a programmer -- even a very good programmer -- does on a regular basis is terribly original from a technical or mathematical viewpoint. In fact, it seems like many of the best innovations are not based on pure technical strength, but philosophical realignments of what the "problem" area is.

Sometimes the best solution is to do it a way that has been done before and known to work. That doesn't require "problem-solving" skills as (allegedly) taught by math courses, but rather sense and memory and the ability to synthesize experiences into a revelation of "hey, this looks like something I saw/experienced/read about before."

Mathematics classes - like most of the rest of formal education - rarely teach that kind of reuse, especially not across multiple disciplines, because the way schooling developed in western culture is very very segmented and compartmentalized.

And, of course, sometimes "the problem" is not only not a problem, but not the right thing to be approaching to begin with. Too many assumptions!

A word that rarely comes up when discussions of programming is "Empathy". While most teams have programmers jut as cogs in the wheel that attack very small excessively defined pieces of code (defined by business analysts) the best programmers are those people who can put themselves in the end users shoes and very quickly bypass a lot of the crap that makes it to production.

The western world still pushes the concept of hyper-specialization which worked great in the industrial era (e.g. spoke fitter, wheel polisher, etc.). When you have a programmer that only knows the one thing they do there is no growth (e.g. learning other languages or influence from other disciplines) and the creatioin of a dead zone as far as inventiveness goes.

I'd say that anyone who wants to be involved in a creative problem solving to explore that creativity in as many ways as possible.

I completely agree with John.

Developers should be people who love to create, to build things, be them new things or old things with a new vision. Also, they need to love simplicity: build simple software to solve little problems.

I'm seeing some very good comments here, and I'm finding myself agreeing with elements of what just about everyone is saying.

I tend to be a little hard-nosed about math skill, particularly when I interview candidates for developer positions. In my experience, "math" is actually a core required skill. Not that most developers will need to invert a matrix or solve a differential equation in the course of a typical project. However, math and programming are nonetheless inextricably linked disciplines, such that skill in one invariably opens insights in the other, and trouble in one is a pretty reliable predictor of trouble in the other.

This manifests directly in the form of subdisciplines such as logic and discrete math, as Sean mentions. But at a deeper level, it also stems from the fact that both traditional mathematics and programming skills are outcroppings of the same basic skill, one harder for us to define, but maybe Rodrigo takes a good stab at it by calling it "abstract thinking", and maybe it's what mendicant is calling the "process" of math.

What Amy calls "synthesis" and "intellectual flexibility" are important, but only when strongly connected to the basic technical skills. A programmer who can synthesize in a general sense, but can't think abstractly enough to understand recursion, is never going to make it in a development shop.

The best basic educational background for a programmer (and for an engineer in general) I believe is a combination of mathematics and the arts. And yes, I mean the fine arts: music, literature, and visual are all relevant. Isn't that the engineer's role: a combination of mathematical abstract thinking, and artistic creativity and (to use John's term) empathy? In my experience, those with one and not the other end up half of an engineer.

The great Philosopher Queen of Code, my dear lady:

Programming is like a musical instrument. Some can jam, some can sight read from a complex classical score, and some can play their instrument and write scores, too.

There are so many programming tasks in the projects that I supervise, that are 'task oriented', small in scope, but critical in function.

Then there are grand designs where a top notch software engineer can actually increase the project's value by altering the architecture - because these folks are smart.

You dont want to confuse those two programmers. No, No, No.

I haven't finished it yet, but the Programmers' Stone seems to be going in a really similar direction. Might be worth a read if you haven't seen it already:

http://the-programmers-stone.com/about/

Here, here! Couldn't have put it any better myself about web programmers. A few months ago I was musing on this same subject - picked up some math books from college and marvelled that I had begun to forget much of it, and also as a programmer that I rarely used the stuff. Now for those who do advanced 3D imaging programming, I'm sure it's an entirely different story.

I agree with Amy, and I agree with Daniel and mendicant. I think that we're all coming at the issue as though there is a single kind of programmer.

Amy's programmer is my kind of programmer, we are handed something like "design a comment system for our users". We are tasked with creating user-centered systems and understanding all of the components, thoughts, maintenance, cooperation, problems and user trifles therein. Here, math is almost useless save for being a means to learning the foundation of logic. The underlying logics necessary can, and frequently are, learned in the utter absence of math.

Conversely, I think that Daniel and mendicant's programmer is the one who is tasked with creating a model of a system. They are given a set of inputs "A,B,C...etc" and told what the outputs are supposed to be. They have clear concrete goals that have to be achieved with finesse and intimate knowledge of a rigid and unchanging architecture. Here, math is incredibly helpful. Understanding the intricacies of an encryption algorithm, of a physical formula, and the calculus necessary for these sorts of things are all but required. Being able to take those defined set of inputs, and have a defined output is an almost verbatim description of modern mathematics courses.

So, I think that both sides are right. We see programmers answering both ways; "Math is required" - "Math is not required". So programmers themselves can't agree whether they need to know math. The not-math camp agrees with itself but disagrees with the lots-of-math camp. The real question I think boils down to this; Are application programmers, like Amy and myself, any less programmers than black-box systems engineers? Is one camp more important than the other? I don't think so.

I think that we're simply two (and probably more) distinct categories which require distinct skill-sets. Empathy, synthesis and flexibility for one and algorithmic knowledge, memorization and ability to utilize both of these together for problem solving for the other.

@Amy

I see your point about problem solving skills. And i agree with it, partially.

Even if you're not working in anything new and using something well known to solve a already solved problem, knowing math will allow you to actually understand how and why it works.

Again, I'm not saying that knowing math is a requirement. There are many others skills that are more important. I see math more as a way to develop the mind in order to work and understand abstract concepts.

If you think about it Math is one of the main difference between a computer scientist and a programmer. I'm an undergraduate student in computer science and i know how much learning math contributed to myself. It allows me to answer almost any questions i might have about an algorithm or language, and explain the behavior of a technology X. Also, it let me optimize and develop greater solutions than the ones i might find.

Of course, programming is not all about technical skills. Skills such as passion, creativity, empathy and synthesis are as important or more than the technical ones.

I think the important thing is the balance between soft and hard skills, discussing a single skills it pointless unless you have a pretty specific context.

Keep the good writing, Amy.

PS: English is not my native language so sorry for any eventually error.

Hi,

Programming isn't about problem solving and math skills aren't required for programming. Programming is about abstraction and math is a valuable tool to learn this abstraction.

The skill of abstraction that programming requires is the key to good software (in my humble opinion). Programming is about reflecting the world by abstracting it and making is simpler (we just can't catch the worlds complexity in software! Bad software does try to do that). This proces creates problems (these are what many people see as the problem solving task of a programmer). But the real skills of a good programmer lies in the emapthy to understand the interpretation of the world of a user/users and reflect this in their software. A user should feel 'at home' in software.

Good discussen, by the way!

P.S. English isn't my nativa language either. Forgive my spelling and grammer errors.

Is programming really about abstraction? So much of what we create has no real-world analog. If we try to hew too closely to what's possible out here in the Big Blue Room (aka reality), we get Microsoft Bob.

Microsoft Bob!

I don't see a very good real-world analog for email, RSS feeds, blogs, or chat software that wouldn't be extremely limiting. The best thing about creating things with code is that we can go beyond what's possible with physical objects, don't you think?

More specific comments about math stuff coming up soon... when I get time to breathe ;)

(Responding to the way Division by Zero used "abstraction", not the technical concept.)

(But speaking of the "power" of the technical concept of "abstract thinking," I've also seen awesomely huge amounts of code in the past where the Abstraction Beast grabbed the programmer by the short hairs and the programmer never realized he was under its spell. You know what I'm talking about.)

(I still don't believe that advanced math is the only, or even best, way to learn to think sensibly, logically and - heaven forbid - abstractly.)

A lot of the "programming" has already been done, what I end up doing for the most part is scripting. Where languages help to abstract a lot of the math so you get concentrate on relationships.

Manipulating and understanding relationships seems to be what programming has become. I've used if/then/else tons more than any traditional math. Recursion is an important concept, which is an uncommon paradigm, but I don't think it's really math.

With the web it seems like programmers have to be the designers. The results are often horrific, so you see a lot more scripters who choose to work on a higher level, rather than bit shifting. I bet half the web programmers couldn't multiply by 2 in binary.

I suppose strong math is important in some programming environments but there are a lot of different kinds of programmers now.

Saying saying that math skills are essential to programming is like saying that baking skills are essential to cooking.

I see the confusion about my comment. With the world i didn't mean the real world, as in fysical objects, but in a more philosophical/psychological way. The world as is how a user (or a group of users) see the world, or how they iterpret how the world works. What is their truth about the world.

In this way you won't be limiting yourself with fysical objects, but your software wil work as the users interpretation of the world expect it to.

E-mail software should work in the same way a user wants to communicate. Rss feeds about how the user selects information en orders information. If software works in the way the users worldimage is, she/he will feel comfortable when using the software. In many softwareapplications too many possible ways of getting something done or to many unused features are added. Simplicity is the key.

About abstract thinking in a technical manner. This is a tool which should be used to some level. Every software application has a level of abstraction and reusing code, but most of the times this abstraction is used too far and too many. Programmers, in my interpretation of the world, should be pragmatic in writing code and abstactions within the software should only be at the level the software requires (the purpose of the software). Simplicity is (again) the key here. In this way software will be more usable and more maintainable, i think.

All software is an abstraction. All it is is a heap of electrons. That's what a webpage is, an email, a program, etc.

Humans use language to describe the real world. Language is a total abstraction. From that, they use both written language and mathematical language (as well as other types) to describe it in greater depth. Programming and logic are both abstract ideas formed from a combination of written and mathematical languages. There are specific (named) languages that are built upon the abstractions of programming and logic. That's what we deal with, day to day.

Email, RSS feeds, blogs, chats, are all abstractions too. Not of a physical object, but of the abstract idea of methods of communication. Newspapers, commercials, snail mail, etc are equal abstractions.

How much math you need to know depends on how much of the real world you are trying to abstractly express with your programming language. HTML doesn't require a great deal of mathematical knowledge - mostly only a small amount of logic - but then again, you can't say very much with it. Simple programs; where stuff goes in and stuff comes out with little work in-between, require a little more math than HTML does, but not much. Slightly more logic, as well as some other disciplines. Large programs, where stuff goes in and stuff goes out with a lot of work in-between requires even more math. Even more complicated programs where the work models the real world, they require even more math. Think of the graph theory behind google maps, for example. At this point, you're using your programming language to model the mathematical language that is modeling the physical world. Why? Because we only have a limited ability to map written/spoken language to our mathematical language. [An interesting side-effect is that we use math to do the language-to-math mapping! And that, again, is programming... and obviously requires math.]

The simple answer is that the more you're trying to say, the more you need math to say it.

Eddie, consciousness is an abstraction, if you want to go down that route :) We have no ability to interact directly with anything... our senses are our intermediary, all the time.

When somebody says "programming is about abstraction," I think about taking code and abstracting it. Then I think about modeling (perhaps the better word) real things in more abstract media, e.g. code. To which I say, no, programming is not about abstraction. It's a problem of semantics :)

However, regardless, I will always disagree that programming requires a foundation in advanced math. First of all, what does that even mean? And secondly, programming is a good a tool to learn logical thinking as math, perhaps better, because it's more interactive and much easier to peer into / understand the inner workings than advanced math.

The deeper my math education became, the more I realized: wow, math is like programming! It didn't go the other way. And it didn't have to. The programming background helped me in advanced math. (When we learned about variables in 7th grade, I was the only kid in the class not stumped for an entire week... I already knew BASIC.)

It seems that many people in a given industry simply want to set up barriers to entry for those not already in the club—especially ones like ours, where most people already seem to feel terribly insecure about their place in the world and compensate with overwhelming arrogance.

Advanced math is simply not required to learn programming. It may be required for certain outcomes you want to program, but that is entirely different. Replace "advanced math" with another term and you'll see what I'm arguing. OpenGL is not required for programming, it's only required to program stuff that uses OpenGL. Would it help your general programming knowledge to know it? Possibly. But it's not required.

Amy, I think that we were basically saying the same thing while looking at it at from opposing angles.

When you thought that math was like programming you realized what I was trying to say; that they're one and the same. When you're doing any type of programming, you are using math, and vice-versa. That's all. As for "advanced math" (the definition of which is kinda open, but let's say anything equal or above calculus in a standard public school program)... no, I don't believe you use it very often, unless you are programming something inherently mathematical. [like I said, it all depends on what you're trying to "say" with your program] So no, I don't believe that you need it.

But I think it can help! You point out that you value a person's "synthesis" and "intellectual flexibility." I believe that math helps us practice both of these skills. In my experience, advanced math and physics classes were as at least as useful in refining these skills as my programming classes were. So I don't think barriers are being set indiscriminately, I think that having advanced math skills on a resume simply helps to show that a person has had multiple outlets to hone these skills. Insecurity and arrogance could drive some people, but I sincerely doubt that it's the norm. Few people are hired just because they can specifically do Fourier transforms, thats why textbooks and formula handbooks exist. They're hired because of what they learned along the way.

I'm motivated to join the discussion, since I have wondered about the same issues that are presented here.

Sounds like a few different ideas are being brought to the table.

The difference between knowing math and using math, is one of the issues I see. There are those skilled in a trade who have various tools on their belt. When they know the most efficient use ( not necessarily most conventional use ) of all their tools, I consider them a skilled trades person and am grateful for their work. In my world, if someone doesn't understand math, they are blocked from understanding certain concepts and use only the tools that are available to them. Then there are others who understand math very well, but when required to use other skills like communication and presentation skills, are lost and they too are limited. I think that a person needs to understand math in order to access that tool when math is required. The level of math is determined by the combination of the goal and the person. They also need to have other tools on the belt as well, and what those tools are and how they use them depends on both the project and the person, since I see tools (of which math is one) as an interface between the person and the project (however the project is defined).

Also I think that one of the other issues on the table is acceptance of one's work by the larger community. That is a complete flip of the coin, and from my point of view, has more to do with whether the planets Neptune and Mercury are having a good time in the sky at the moment. If the community thinks you are in, you're in and they will make up reasons why. If the community says your out, you're out and again they will change the rules accordingly.

I am enjoying the conversation and look forward to more installments.

Thank you, Amy, Anita.

I've been listening to the audio book Freakanomics on my overly long commute so I've been thinking about correlation vs. causation. I'd say that being good at math is correlated with being a good programmer but not necessarily a cause.

I agree with what you said above: "That means somebody who can come up with a sensible, coherent vision of what the application will do, not only keep its working parts in her head but imagining/seeing how it all fits together as a whole...". The two best programmers I've ever known both had the ability to juggle a HUGE numbers of items in their head at once and keep them all sorted out.

What started as a comment ended up as a thousand-word blog post ...

Firstly, mathematics is NOT a requirement for programming, but it can help.

Secondly, I agree there are types of programmers. Generalizing to all programming might be difficult, especially if we're not considering the specific types as we do it.

If anybody saw/read/took SICP, there should be a very clear understanding of mathematics vs programming. Mathematics is a language, unlike natural language, where all possibilities are expressed exact and precisely. And with that language, we talk about what-is-true knowledge in declarative relationships.

Programming, or whatever this idea really is about, is another type of language or way of expressing that is fundamentally different in that it is about how-to knowledge or process. Because unlike natural language where you have lots of ambiguities created by our natural chunking and abstractions ("I got up, ate breakfast, went to work") in programming you have to be exact and precise ("I opened my eyes, I pulled my left foot out of bed and onto the floor, I pulled myself up and out of bed, I walked towards the door... etc").

For that reason, real software is complex and deals a lot of abstractions to make things sane, but entirely formalized abstractions. Complexity is a huge deal with most programming but it still all boils down to process and flow.

Programming is about automation. Unlike mechanization where it's about automating physical work, programming is about automating the process of manipulating symbols. You might realize that at some point, but it's not necessary.

Nothing is required to start programming. Anybody that has requirements has excuses. Unless you're talking about getting a job where you need a certain amount of experience to start getting things done in that environment.

Everything else though, you can learn through programming and getting better. That's just how it works. If you need math, you learn math. Programming is teaching, and teaching is learning.