Do computer programmers need to be good at math?

There are mathematical things that you should understand if you wan to be a good programmer. You should be able to understand how many times a loop will be gone through, how much memory will be used etc. If you can’t understand the differnce between 2x x^2 and x^x then you won’t be able to make good decisions about how to do certain things.

There are certain areas that rely a lot on math. Encryption, compression, graphics, etc. Working with graphics and color especially. When you take an image (and pretty much anything else) and change it with a computer, you are doing it by representing it as numbers and using math to change those numbers.

Before computers pre-press guys used slide rule to calculate what changes to make. A lot of the operations used linear algebra. These types operations are built into the graphics programs. A programmer had to understand the math involved. But, if you can rely on someone else do the math and code those bits, you don’t need to know the math. Graphics cards and active X both do a lot of the math.

As Ultrafilter said, you can’t have too many tools in your toolbox. On the other hand, if I were hiring someone for a typical business-oriented programming position and had to choose between someone that was really creative versus someone really good at math, I’d choose the creative person. Not that you can’t be both.

Not so much math skills but logic skills and enough math skills to know where to look, in case you need the math formulas.

I’m an ex-CS prof. I’ve taught a lot of future programmers over the years. I’ve also hung out enough with industry types to be able to predict how a given student will do in Real Life Programming, etc. So my 2 cents.

  1. There are really two types of programmers. The regular grunt programmers who just fill up cubicles, grind out thousands of lines of code, etc. Their work is awful. But it looks like real programming to PHBs, so they keep their jobs.

Then there are the superprogrammers. They grind out far, far better code. Smaller, faster, fewer errors, etc. One superprogrammer is worth 50 or more regular programmers. PHBs hate them. They’d rather have 20 regular programmers working for $60k than 1 superprogrammer working for $200k. You can explain the economics to the PHBs for years and they still won’t get it. All too often, superprogrammers spend most of their time cleaning up the work of the grunts. If you fire the grunts, the superprogrammer will get more real work done.

Note that almost all people who claim to be superprogrammers aren’t. They are really quite rare. You might see a ratio of 95% to 5% claimed but I really think that the ratio is much much higher. I just don’t want to get into any “cite!” wars.

IME, the overwhelming majority of grunt programmers are bad at Math and the overwhelming majority of superprogrammers are great at Math. However, you can’t turn yourself from being a grunt programmer into a superprogrammer by becoming good at Math. It doesn’t work that way. Either you’re a superprogrammer or you’re not. But on the other hand, if you refuse to learn discrete Math, the chances of becoming a superprogrammer are quite low. So learn it anyway. Certainly can’t hurt and could help.

  1. Regarding Math vs. programming abilities. Abstraction plays a key role in both skills, but in different ways. A lot of serious Math involves abstraction only. I have met far too many Math types how are completely unable to relate their problems to anything remotely real-world. (The best Math prof I ever had came from an Engineering background. He would start off with a real-world example and then express it as a differential equation and solve. Great stuff but not common.)

Programming heavily relies on mapping real-world stuff into something abstract. “Hey, that’s just a convolution!” “I’ll use a weighted graph for that.” “I’m going to need a 2-dimensional array of pointers to doubly linked lists for that.” Etc. Superprogrammers do this abstraction mapping easily. That is why they can “think in the large” about a problem. They excerpt out the key parts of the whole thing and then only have to synthesize a solution from those key parts.

In short, programmers keep one foot in the real-world and the other foot in the abstract-world.


So answering the OP involves asking a question: “Why is meant by ‘good programmer’?” Grunt programmers are considered good programmers by PHBs and therefore Math is no biggy. But that’s Dilbert-world. But if you really mean superprogrammers, then being good at Math is something that goes hand-in-hand with the job.

One thing to note also is that the stereotype of programmer as drudge seems to be long gone. In my work I find programming to be a very social activity. I would say that maybe 20-30% of my time involves communicating ideas, developing shared group concepts, getting the group to go a particular direction to make things happen (sometimes referred to as herding cats).

The opportunity to actually sit and pound out some code is a rare pleasure. You spend much more time working to get information from parts of the organization that are from some reason politically incented to not share information, or to address alterations to the plan that weren’t there when you started the project, etc.

So you would part of the third group, then? :wink:

You are exaggerating. Real world tests have frequently shown a (very high) difference in productivity of programmers, but only 10 to 1, not 50 to 1. Also, productivity of programmers follows a bell curve distribution, you can’t lump everyone into either “grunts” or “super-programmers”.

Like you say, the hallmarks of high quality code are simple, clean architecture and a low incidence of errors.

This is why I struggled with pure math, but found mechanics and statistics quite easy. I could relate the latter to real world situations, likewise I find modelling a software system into a number of components a fairly natural thing to do.

In my experience, set theory, graph theory, and the theory of algorithms has proven real handy. Numerical analysis is good to know, but I’ve never needed it. Calculus, differential equations, and trig I’ve never needed, and can only seem them as being useful for specific applications.

When I was running a CAD development group, everyone programmed. Now I’m around pure engineers and statisticians, and the level of programming skill is abysmally low. Excel has replaced coding for a lot of people, and if you can’t do it in a spreadsheet a lot of them are stumped. I’ve been able to do a lot by just writing Perl scripts to play with data in ways that aren’t feasible in spreadsheets.

I’d also add writing to the skills that programmers should have. Many disasters occur because of miscommunication between the user and the programmer. Being able to express yourself clearly counts a lot more than advanced calculus in my experience.

There are a great many tasks which can be lumped under the category of “programming”, and the amount of math required for them varies enormously. Designing user interfaces, for example, or maps for various games, involves almost no math, and is almost pure art. A person could make a living as a “programmer” doing nothing but such tasks. On the other hand, someone doing algorithm design is guaranteed to use a lot of math, because algorithm design is itself a branch of mathematics.

On the other hand, good spelling has never been seen as a priority in a programmer, though computers are quite picky about it. :wink:

If you think Bippy’s spelling is bad, you should see my handwriting. :wink:

This sums it up pretty nicely, except I’d add that even algorithm design can fall within the capability of an experienced programmer who didn’t do well in the traditional math sequence. Particularly if optimization isn’t critical–and it often isn’t–then there’s no reason why a nonmathematician can’t come up with practical solutions to decidedly nontrivial problems.

With that said, let me cast another vote for the theory of “brain overlap”. I’m one of those programmers who did badly at math. I didn’t get past first year Algebra and Geometry in high school, or Calculus Lite in college. But I found after I’d been programming for several years my interest and ability in math was markedly improved. I do wish I’d taken a CS major in college, but under the circumstances at the time it was out of the question.

This is coming from an applied mathematician. Knowing how to program (which I define as writing code to carry out a set of calculations or data manipulations that will help solve a well-defined problem) is an important part of my toolkit. In my case, I have to first figure out the solution before testing it by writing some code that will simulate the results. Sometimes I hand off the solution algorithm/formulas to a computer programmer who does the coding. Is it helpful for the programmer to know math? You betcha. It speeds up his work to be able to read my specifications that are filled with math. But is it essential for the programmer to know the math? Not really. I can still walk him through all the steps and he should be able to write working code.

I started out my career as a systems analyst and wrote and maintained a lot of programs. From that experience, I think that math aptitude is not as important as: (1) dogged determination to squash bugs; (2) ability to translate specifications into code; and (3) logical and at times clever thinking. I would surmise that the last two attributes tend to correlate well with math ability. Anyone can possess the first attribute regardless of math ability. I’ve always view the process of debugging as akin to puzzle solving. So perhaps another indicator of a good programmer is someone who enjoys solving puzzles.

I think there’s some confusion here between being good at math and doing well in math classes. For whatever reasons–bad teachers, short attention spans, lack of interes, etc.–people who do have some aptitude for math can do poorly in math classes. And through sheer hard work and dedication, people who don’t have an aptitude can succeed in low to mid-level math classes.

I take it you’re in the last 25%? :smiley:

Too true. John Donovan, my Systems Programming professor, told us that he added various spellings of Fortran keywords to his compiler, so that his compiles wouldn’t bomb out due to spelling errors.

I am both a math person and an English person - high SAT scores in both math and verbal categories and master’s degrees in both math and linguistics. Although I work as a mathematician, reading and writing has always been very important to me. I am a terrible programmer. The little programming I do in my job has always been a problem, since programming is both boring and difficult for me.

As a mathematician who’s looked over his share of code and known his share of computer programmers in his time, evidently not.

[hijack severity=“slight”]
Programmers here have now mentioned set theory three times. I have yet to see a computer science degree which required a real class in set theory.

Just what do you people think constitutes set theory anyway?
[/hijack]

Yes, but most programmers don’t have a computer science degree.

Many of the earliest generation of programmers are retiring nowdays, but most of them worked for years, and computerized most of the businesses in the country, without any computer science degree. Heck, most schools didn’t even offer one at the time they started programming.

I’ve worked at many shops, with programmers from all kinds of backgrounds. At one shop (a railroad company), there was a large group of ex-coal shovelers who the company was required to re-train by their contract. So they made them into programmers. About half of them were effective at the job.

Anecdotally, I have noticed a few traits that seem more common among programmers than the general population:

  • background in filing/classification/pattern-matching jobs.
  • background in music.
  • like to read science-fiction or mystery books.
  • like logical puzzles (crosswords, word problems, etc.)
  • exacting, detail-oriented, nit-picking kind of personality.
  • logical, follow-the-evidence type of mindset.