Good at math, bad at programming?

June 16, 2006 10:44 PM

I'm good at math but bad at programming. What could this mean?

I'm scatterbrained and disorganized; this hurts my programming ability. I get lost in big programs, make syntax errors, and spend inordinate amounts of time debugging. Others have commented on these tendencies.

I find math -- especially discrete math and geometry -- much easier, because there's more visualization and less text.

How can I figure out what this means about my cognitive skills? My goal is to find the academic areas that my brain is best suited to study.

posted by lunchbox to education (39 comments total)

Well, what's the matter with, um, mathimatics?
posted by delmoi at 10:45 PM on June 16, 2006

It means you're normal. I haven't met very many good mathematicians that can program. I haven't figured out why yet, but I know I'm not the only one to observe this.
posted by BioCSnerd at 10:56 PM on June 16, 2006

Well, math is not necessarily what I want to study most. There's theory of computation, economics, operations research, statistics, physics, and so on. Also, within math I'm weak with linear algebra. I'm looking for a way to predict what I'll be good at.
posted by lunchbox at 10:57 PM on June 16, 2006

I don't see how math and programming have to be related... so you're good at one and not the other? I stink at math, but I'm great with languages (picked up Spanish in high school and got straight A's) and I'm also really good at HTML. I guess I could assume that HTML is a language and that's why I'm good at it, but FWIW I *hated* programming in college, even just in Visual Basic.
posted by IndigoRain at 10:58 PM on June 16, 2006

Well, if you like mathematics, try your hand at:
- Abstract Algebra
- Set Theory, Logic, and other foundational parts of mathematics
- Topology
(If you're truly that weak with linear algebra, there are a few pieces of abstract algebra you won't want to spend too much time on.)

(FWIW, I'm a mathematician, an algebraist to be precise, who is a poor programmer.)
posted by CrunchyFrog at 11:01 PM on June 16, 2006

Oh, as a programmer: it's not difficult to program even with a short attention span if you just keep your classes nice and small and well-seperated.
posted by delmoi at 11:06 PM on June 16, 2006

If you want to program (I'm not exactly sure what the question is; this might be one part of it) you could always try lisp/scheme (or another functional language) or prolog -- these might be quite a bit more like actually doing math. They are almost certainly quite different from the programming you've done so far, in the kind of thought required.
posted by advil at 11:08 PM on June 16, 2006

Probably nothing. I'm terrible at math but good at programming (or at least I think I am: I tend to pick things up pretty quickly, comparatively).
posted by patr1ck at 11:08 PM on June 16, 2006

I've noticed correlations between math, music, and programming. Do you play an instrument? (guitarists tend towards visual/spacial including design and light programming and multimedia scripting while drummers and piano players tend toward heavy duty progamming.)

What sort of programming do you have trouble with? Also how long have you been programming?
posted by shoepal at 11:09 PM on June 16, 2006

How long have you been programming? (Sounds like you might be choosing a major?) This doesn't necessarily mean anything about your cognitive skills; could just be that you need more practice.

If you're getting lost in big programs, break them up into tiny functions. Inordinate debugging time might be due to going too long between debug sessions--compile and test every function as soon as you've written it. Bad habits can make programming much harder than it needs to be.

But, yeah, ain't nothing wrong with math. If that's what you like, why not do that? (But make sure you try some more advanced math before you decide.)
posted by equalpants at 11:10 PM on June 16, 2006

Math and programming are completely different. Duh.
posted by croutonsupafreak at 11:18 PM on June 16, 2006

Not completely different. Both of them involve visualizing something then laying down very fussy little arcane invocations to invoke them. I would guess lunchbox is not particularly adept at proofs.

lunchbox, have you considered engineering and physics? Strong visualization helps there, I think.
posted by fleacircus at 11:35 PM on June 16, 2006

invocations to invoke.. shit, I can't write
posted by fleacircus at 11:36 PM on June 16, 2006

I've also noticed a correlation among mathematicians, programmers, and musicians.

If programming is understood not as the writing of instructions for this or that computing machine but as the design of methods of computation that it is the computer's duty to execute (a difference that Dijkstra has referred to as the difference between computer science and computing science), then it no longer seems possible to distinguish the discipline of programming from constructive mathematics.

The effect of student attributes on success in programming

mathematics and computers

epsilondelta.net
posted by foraneagle2 at 11:48 PM on June 16, 2006

Programming requires a variety of skills, and mathematical ability rarely comes into play. Some abilities of mathematicians and programmers must intersect, but there are definitely distinct attributes to each.

If you're looking to improve your ability at programming, read books about good practices, such as The Pragmatic Programmer. As delmoi suggested, keeping things small makes it significantly easier. Don't tightly couple objects together, keep things modular. You should be able to work on one small chunk in a near-vacuum without breaking the rest of the application, that is, design by contract.

It's possible you're lacking some specific ability, maybe the ability to juggle a few pieces of information in your head, or maybe problem solving skills. But I think it's more likely you just need to improve your skill and understanding in some particular area(s). For example, knowing how things work under the hood can definitely help demystify the programming experience.
posted by knave at 12:09 AM on June 17, 2006

I get lost in big programs, make syntax errors, and spend inordinate amounts of time debugging. Others have commented on these tendencies.

I used to be good at math, then ventured into programming and never looked back, but I can relate to this feeling of dauntedness when programming.

There's as much beauty in a perfect formula as there is in a perfect algorithm. Sometimes it springs from your head like Athena, other times you have to slowly chip away, optimize a loop here and there, freeing the inner algorithmic beauty like Michaelangelo freed his subjects from blocks of stone.

Whenever I spend a protracted period away from my work, I find it takes at least a day of pouring over code just to get "back into it" in my headspace. I've heard similar things from mathematicians working on proofs--it takes a large amount of concentration to follow a systematic method from start to finish, and any break in concentration can be so frustrating as to make you want to start anew.

(Eggregious analogy alert) The first time I start programming something is much like the first time I drive or walk in a new city: I'll bumble about for a while, get lost, then promptly start again, only this time being more methodical. I learn the major streets, and only once I'm comfortable with those do I venture down the narrow side streets and crooked lanes where the real action is.

In other words, it helps to break down your projects. Start abstract: What do I want it to do? Then figure out the major "sections" involved and sketch some very, very basic pseudocode: Main Screen, Section 1, Section 2, Etc. Then for each section, further break it down procedurally. Constantly discern that which is local from that which is global (i.e., Customers might be a global construct, View Payments might be a section, Adjust Payment might be a local procedure, while Amount is a local instance).

Everyone's style is different, of course. Some people like to write their fancy algorithms first, then slowly work backwards until the larger parts are wrapped around it. I work in the other direction, rough-outlining the big pieces and only getting more detailed when I break it down into the smaller parts. I have to do it this way or I quickly lose track of how whatever I'm doing relates to the bigger picture.

When tackling a specific problem, I'm constantly thinking procedurally. What is the first thing I need to do? Write the code. Test it. Does it do that? Now, what's the next thing? Test. Next thing. Test. It might not seem like a very "rapid" development approach, but if I don't do it in an extremely step-by-step way, I'll get innundated with "ideas" and be in over my head.

I apologize for the abstractness of this response, but like Tolstoy said, all good programs are written the same, all bad programs are unique. I can't guess as to what your particular application will be, but I've found the above strategies helpful.
posted by Civil_Disobedient at 12:49 AM on June 17, 2006 [2 favorites]

Not only are maths and programming different, but different areas of maths are different still.

In high school, I was in the advanced class, but was pretty much the bottom of said class, generally only just scraping past tests. Except when it came to probabillity and physical mathematics, where I came top of the class. Now in uni, I hate calculus, yet feel strong in linear algebra. Even if you consider programming to be an aspect of maths, it doesn't necceserily follow that someone good at most branches will excel at this particular one.

Remember, they're way more than just numbers.
posted by Serial Killer Slumber Party at 12:53 AM on June 17, 2006

I'm good at math but bad at programming. What could this mean?

I'm bad at math but (fairly) good at programming. I'm bad at math, because I'm bad at arithmetic, and I was duped as a kid into believing that math and arithmetic were the same thing. So I figured I my brain couldn't handle math and quit studying it. Now, in my 40s, I'm slowing getting back to it. But since I don't know much about math, I'm not qualified to compare it with programming.

I do know a little about the way good programmers think. Maybe the following list will help you figure out where you're having a problem:

1) Good programmers have the ability to step in and step back. They can spend a couple of hours focusing on minutia and then pull back and look at the whole project and its goals -- and then step back in. It's like being a good host at a party, focusing on one person and making sure he's happy, and then stepping back and taking in the whole room, making sure there's enough beer and cheetos left for everybody. Then back to the one person.

2) A refusal to cut corners. On a mundane level, this means naming a variable totalNumberOfSharksInTheTank instead of S. But programming is full of these sorts of decisions on large and small scales. Decisions that involve choosing between something that works and is easy to type and something that works and is more difficult to type -- but that will be easier to understand later.

Pretty much everything that makes your program easier to understand and debug is a pain to set up in the short-term. Long, descriptive variable names, comments, etc. It's so tempting to be penny wise and pound foolish. But the good programmers I know EMBRACE this extra work. They get pleasure out of going the long way around to make things clear. They love the beauty of transparent code.

3) Good programmers, like good writers, make multiple drafts. They go back over their code many times, optimizing and clarifying. Some people don't like making multiple drafts. If you're going to be a good programmer, you can't be the type of person who likes to go over something once and then be done with it.

4) Good programmers work to allow themselves to selectively forget information. The goal is to make parts of your program become "black boxes." You try to perfect functions, classes and the like so that you don't need to remember how they work any more. They are self-contained tools that you can just use. Programming needn't involve holding a zillion things in your head at once if you work this way.

The flip side of this is my item 2, a refusal to cut corners. Once you have forgotten the guts of function, there will come that inevitable day when you'll need to revisit it. On that day, you'll be ecstatic about the breadcrumbs you left yourself -- the comments, identifier names, and organization -- when you originally built the function.

5) Good programmers learn from other good programmers. People have spend DECADES theorizing and experimenting, and they've learned a lot. There are all sorts of programming structures and practices that have been well worked out: design patterns, data structures, etc. These aren't things you're likely to come up with on you're own. You have to read, study and practice.

6) Good programmers (like good people in any field) work to improve themselves. I keep a personal "Syntax Error List." I tend to make the same mistakes over and over. For instance, I tend to write single equals in a conditional statement instead of double equals (accidentally making it an assignment instead of a test of equality). When my program doesn't work, instead of staring at it blankly, I go down my list and check for my common errors.

7) Good programmers learn to debug. Debugging shouldn't be an afterthought that you do in a haphazard way. It's a specific and necessary skill that must be learned and applied. (Again, don't re-invent the wheel. Learn from people who have gone before you!) You need to learn to think the way a good electrician thinks: the light doesn't come on. Is it the bulb, the socket, the switch, the wiring...? You need to test each component part to see where exactly the problem lies. Once again, it's about stepping in and stepping back.
posted by grumblebee at 3:19 AM on June 17, 2006 [4 favorites]

Because math and programming share common terms, demigods, and structures, there is a high degree of overlap.

When I studied discrete structures, I saw an attempt to turn a programming lanuguage into a mechanism for generating proofs of correctness. In other words, using programming as a tool for symbolic logic and deductive reasoning.

When I took linear algebra, there was a day when I saw the language of math as an object-oriented programming language with operator overloading.

Then again, I've known people who were killer at the really screwball languages like Scheme and sucked at the really screwball languages like assembly.

With regards to syntax errors - that's rapidly being removed as an obstacle by modern development systems. To be a good debugger is to be methodical, deductive, scrutinizing, paranoid, stubborn, and creative in the right mix at the right time.
posted by plinth at 3:37 AM on June 17, 2006

grumblebee, with regards to 6, you can often eliminate this by always putting constants on the left hand side of the test.

e.g

while( NULL == pBuffer )
{
TryAndLoadBuffer( pBuffer )
}

Slightly contrived in that case, since you'd test against nothing for null-ness, usually, but you get my point.

Also, many compilers will allow you to flag this as an error (since the chances of you actually wanting to assign inside a test are fairly small ).
posted by Jon Mitchell at 3:39 AM on June 17, 2006

perhaps you could study accounting? i dated a fellow who did a great deal of programming, but it was excruciating for him due to problems like the ones you describe. he was a whiz at accounting.

i find questions like yours fascinating: "what can my brain do best, and what real-world tasks would be best for me based on that?" i'd like to know more about this in general.
posted by lisaj32 at 4:58 AM on June 17, 2006

Very few people are good at everything. Everyone can get better at nearly everything with practice. It is not a sign of failure that you can recognize where you are good or bad, but instead, a sign of being observant. I'd be happy about that, because it can lead to the sequence of work that results in improvement in the area you assess as 'bad'.

"Programming", like "math" and "law" are all deceptively HUGE words, covering enormous areas of endeavor. If you are good at what you think is a tiny part of math or programming, you're ahead of the game, IMO. No matter how much you learn about any one part, you'll always remain mostly ignornant of the field, just due to its size.

It has helped me over the years to embrace this, and to not be uncomfortable with the feeling of ignorance. I always know less than I wish I did when I confront a new problem. It's not a sign of weakness.
posted by FauxScot at 5:36 AM on June 17, 2006

I empathize: I'm of a similar mind. I can't understand an equation without a visualization. When I can relate a symbolic relationship to a graphical description I'm much happier. Consequently, things like complex analysis and differential equations are hard for me, while things like group theory and topology are much easier.

The trick, such as there is one, for programming for people like us is to do all the planning as a flow diagram. I still find myself using the fishbone stickchart method I learned in highschool if I need to do anything complex. Traditional "coders" think this step is completely a waste of time, and perhaps for them it is, but it's crucial for me to understand the web of relationships. That way, when it comes to the linear code, I can keep the 3-D model of relationships in my head as I program. I'm working from that model, bending the code to fit the shape in my head. As you evolve as a programmer, you may find that you can skip the flowcharting and just get by with a highly structured pseudocode. Python is a great language to work in for me because space and indentation is part of the language. Geometry is syntax in Python.

And don't worry, you're hardly unusual. This mode of thinking can be highly successful. Richard Feynmann was at least partially a visual thinker. He describes his thought processes in some detail in one of his books.

Which brings up a point: what other areas would you enjoy studying? Physics is almost pure visualization. Analytical mechanics can be the main juice for someone like you. It was like a drug for me in second year. Quantum mechanics is the same. The pictures in your head need a serious readjustment after doing classical mechanics, but it's quite a rush when you get it.

Chemistry is almost entirely dominated by visual thinkers. Being able to think in 3D, to rotate, reflect and invert very complex shapes is key to just about every every type of chemistry. Remember I mentioned group theory above? Chemistry is applied group theory.

There are lots of places for people strong visualization skills. The trick is to find out how to adapt it to whatever interests you. Math, in particular, is often taught by people who are strong at symbolic manipulation, but weak at visualization. You need to find an approach, either through a book or a mentor, to make your equally valid but different way of thinking work for you in these fields.
posted by bonehead at 7:03 AM on June 17, 2006

Everybody gets lost in big programs. That's why so much of today's software sucks.

Comprehensible code is a rare and beautiful thing, and you need to have written and thrown away a tremendous amount of crap code in order to know how to write it.

Scatterbrained and disorganized programmers can end up learning to write code of crystalline clarity, purely in self-defence. Having acquired that skill, you become quite valuable.

Spending an inordinate amount of time debugging is a good thing. It'll make you good at debugging. Many, many people are not good at debugging.

Syntax errors are most easily avoided by using a development environment that understands the syntax of the language you're coding in; you get told about them almost as soon as you've made them. It's kind of like using a word processor with inbuilt spelling and grammar checks.

If you want to stick with programming, and visualization is your thing, learn to write low-level device drivers in assembly language. Device drivers are generally not huge, the job they do is generally very specific and pretty well-defined, but they have to be right and they have to be fast; debugging-oriented people are the right people to write them.
posted by flabdablet at 7:34 AM on June 17, 2006

1) Perhaps you aren't a good judge of your own skill.

2) What is it that you want? Don't decide to do something merely because you're good at it.

3) Do you enjoy becoming good at something, or just being good?

4) programmer specifics

Don't think that there is one true programmer with the one true set of skills. there are different programming worlds out there, with different requirements, and you can find a role that plays to your strengths.

and know that many programmers have had to learn not to let "the perfect be the enemy of the good."

5) me: I started college as an English major. switched to physics. didn't know what I wanted. asked a philsophy professor--who suggested cognitive science. I switched to computer science because it seemed to be the most flexible for getting into a multidisciplinary field. got bored. decided to add another discipline to it. settled on psychology. if you are still in school, play.
posted by bleary at 8:46 AM on June 17, 2006

btw, linear algebra drove me crazy at first. I had trouble going to class. at times I wanted to stab the desk with my pencil out of frustration. I took the class three times, and I am not stupid. The third time it really clicked. It was as though I was seeing something that formed the basis of space and reality. I went on to take an advanced course in it. it can be visual.
posted by bleary at 8:51 AM on June 17, 2006

Haskell, dude. It's foundations aren't 60 years old, it allows you to deal with variables almost entirely locally and facilitates equational reasoning. It's all straightforward symbolic manipulation, no sloppy registers and/or memory allocation.

You will become a better programmer and a possibly a better mathematician.
posted by sonofsamiam at 9:13 AM on June 17, 2006

Math and programming are the same thing, if you're doing it right.
posted by iconjack at 9:14 AM on June 17, 2006

There are two types of programmers, in my experience: brickmakers (who write small amounts of code tolerably well) and architects (who design entire systems). Perhaps your strength is more in high-level design, including database design, than procedural programming.
posted by SPrintF at 9:30 AM on June 17, 2006

Math and programming are the same thing, if you're doing it right.

How do you figure, exactly?

Programming is minutae. The major difference between math in school and programming in school is that the programming you do in school is at least somewhat like what you would actually do on the job as a programmer-- it's both some problem solving and a lot of knitting together complex elements in a hopefully reusable fashion.
At least in the earlier phases of school, math is lots of relatively short problems. They might be hard, even really hard, but their scope is extremely limited. So you're good at solving really hard problems, which is a great skill, but is not enough in and of itself to make you a good programmer.
However, out here in "the real world" there are a lot of people that are not great programmers but are good at math that write programs to solve mathematical problems. Economists, scientists of all sorts of stripes, certain types of finance specialists. Look into doing that. Try taking classes that use Matlab or Mathematica. Or maybe one of the functional languages mentioned above (although I am much less convinced that you will easily fall into that).
If you're young and have only relatively little programming experience, though, try just giving it a little time. I don't feel like I really came into my own as a programmer until somewhere around my junior-senior year of a very intense undergraduate CS program. Ultimately even people that eventually become quite good programmers don't always start out easily. It is a skill like any other, that takes experience and practice to become good at. Just don't force yourself into it because you think "I'm good at math so I *should* be good at this and *should* enjoy this." There's plenty of room in this world for good at math bad at programming.
posted by ch1x0r at 9:41 AM on June 17, 2006

Great! This is exactly what I'm looking for. I plan to take more courses in:

-Graph theory
-Combinatorics
-Probability
-Physics
-Geometry
-Topology
-Set theory
(The last two I haven't done much of.)

And be careful about:
-Algebra
-Differential equations
-Advanced analysis

As for programming, a good language (Python has been a godsend) and good planning (esp. flowcharting and high-level design) help a lot. I'll check out the other languages mentioned.

For those who discussed being visual problem solvers: how can one excel with this style? Are there certain books that teach subjects more visually, or general guides to this way of thought?
posted by lunchbox at 11:03 AM on June 17, 2006

As I mentioned above, read Feynman's autobiography. It's a very accessible, fun read. His Lectures on Physics (the red books) is amazing, even thirty+ years later.

For the group theory, Serre: Lie Algebras and Lie Groups is a quickish (if dry) read to see if you like the flavour. It should be in a good university library.
posted by bonehead at 11:25 AM on June 17, 2006

If you like Python, you might also enjoy Lua.

Flowcharting: meh. If you're going to draw boxes and lines (and you should draw boxes and lines), draw representations of your data, and what's supposed to happen to it.

Designing good data structures before you even think about flow often means you won't actually need to think about flow very much.

Learn at least one assembly language. Learn to grok pointers. Spend some time with your debugger, single-stepping through compiler output to see how the machine actually gets your job done.

Actually, you could spend a few hours in lots of less productive ways than reading Joel... even when he's making sweeping generalizations, he's right more often than not.
posted by flabdablet at 11:55 AM on June 17, 2006

People who are good at math are in much shorter supply than those who are good at programming, because math is harder. If you would like to remain in the IT field, my suggestion is that you become a computing scientist (i.e. a theoretical researcher) rather than a commercial software developer. Don't lament your inability to program well, but exploit your aptitude for computational theory.
posted by randomstriker at 12:06 PM on June 17, 2006

FYI - I'm a visual/spatial learner in that my means of remembering things has to do with the way they look. This has never, ever, ever hampered me as a programmer (and not to be conceited, I'm among the top), although recalling API names is torture, but again, use tools to help you. I code with a dual head setup. My code goes on the left screen, API references on the right. Life is good.

If you're a visual thinker, take computational theory. You'll find most of it requires visual thinking.
posted by plinth at 1:10 PM on June 17, 2006

It's all because of the = sign.
posted by phrontist at 7:57 PM on June 17, 2006

Math and programming are the same thing, if you're doing it right.

How do you figure, exactly?

See, for example, Curry-Howard.
posted by iconjack at 8:17 PM on June 17, 2006

look into being an actuary. they tend to be good at math, but bad at programming.
posted by lester at 8:33 PM on June 17, 2006

I am an actuary-in-training. If lunchbox is as "scatterbrained and disorganized" as he claims, he will not make a good actuary. The math part is very demanding, but the profession requires you to be even more meticulous than accountants are (accountants joke about us being anal).

Besides, I don't think he would enjoy the profession much. As others have mentioned, math is a very broad field. Actuarial mathematics is based mostly on probability distributions, sequences and series, and calculus merged finance, micro/macro-economics, accounting and a thorough knowledge of pension, benefits or insurance law. All that is about as different from "discrete math and geometry" as you can get.

lunchbox should look into studying, say, graph theory. Best if he talk to various professors in the math or computing science departments at his local university.
posted by randomstriker at 9:41 PM on June 17, 2006