Many programmers I know graduated either with a degree from computer science or obtained a professional certificate in programming. Yet simple programming errors or lengthy solution constructs still exist. These programmers only know the how, but not the why. Given a math graduate and a computer science graduate, both with similar academic results, you’re better off hiring the math graduate.

Abstract thinking
In solving problems, a mathematician comes up with a theory given what is known, and work towards a solution. For example, the Königsberg Bridge Problem was solved by translating what is known (the layout of bridges and land) into a mathematical equivalent, a graph of nodes and connections. Solving the graph theory problem is then equal to solving the bridge problem.

This ability to transform problems from unfamiliar to familiar grounds is crucial. Business requirements often have ridiculous conditions defying normal programming laws. An experienced programmer can draw upon his vast knowledge and piece together a solution. A mathematician can come up with an equivalent problem but is easier to solve. Tip: Hire the math graduate. He’s cheaper.

Naturally logical
I have seen program code with wrong if conditions, such as incorrect inverse disjunctions like if (!(p || q)) is equivalent to if (!p && q). It is disastrous to form wrong tests for conditional statements and loops, 2 commonly used programming constructs.

Mathematicians exhaustively explore all test conditions to ensure a complete solution. This ties in with their chain of thinking. A solution with sequential steps is only correct if all the steps are correct. If A then B. If B then C. If C then D. Therefore if A then D. What if B is false? Then the whole thing collapses. Mathematicians are used to checking their OR’s and AND’s.

Elegant solutions
In my university days, I used to fear the Terrifying Triple, consisting of a 4-letter, 5-letter and 7-letter word. They are “Show”, “Prove” and “Justify”. I get a lurch in the stomach whenever one of these words start off a problem.

• Show that [whatever] is equal to [whatever]
• Prove that [whatever] is true
• Justify your answer

However these exercises made me shrink my answers to the most concise solution I could think of. The less of a solution to be picked on by my professor, the better.

I find that some programmers simply write a solution code to the problem at hand, and if it compiles, oh yeah! And if it does what it’s supposed to do, woohoo! Next! Unbelievable… This is why the following code exists:

void SomeFunction(){
   int i;
   i = 0;
   abcd[i++] = 111;
   abcd[i++] = 222;
   abcd[i++] = 333;
}

Either the original programmer don’t know that a literal number value can be used as the array index, or he just found out about post-incrementing and is absolutely ecstatic that he can apply his new found knowledge.

Problem solving
Mathematicians are used to grabbing theorems from say calculus and apply them to chaos theory. They are accustomed to interdisciplinary thinking. Thinking out of the box is good. Sometimes making the box larger is better.

Then there are the programmers who copy and paste example code without giving a hoot to what the code is actually doing or why the author coded it that way. Then they compile and test it, and ask why it didn’t work. The situation is different for the copiers and a slight change is required to make the example code work, yet the effort required to understand the code is beyond them, thus escalating the slight change into a major shift in thinking.

Conclusion
Programming is simply giving instructions to the computer to solve problems. Learning to program for the sake of programming is limiting to the focus on problem solving. Sure, math isn’t the be-all-end-all of interdisciplinary thinking. But it’s a start.