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.

After too many years professional experience, it’s become plain to me that there are basically two types of people who program computers. The first group, whom I think of as the “computer science” people know about underlying architecture, algorithms and the like. The second group, whom I think of as the “MIS” types, know only whatever applications they work on.

The obvious advantage to hiring a “computer science” person is that when something goes wrong, or something out of the is required, they have a knowledge base with which to work.

The obvious corresponding disadvantage of hiring the “MIS” person is that they lack any such facility.

An excellent example of this was the consultant I worked with some years ago who had never heard of (and was utterly confused by) the idea of two’s complement numbers. Clearly, he was an “MIS” type. I could relate any number of similar tales, based on other encounters in my career.

Before we become too haughty, though, it is worth considering the value of the “MIS” guys: economy. Given the rapid expansion in need for people with computer skills, it is unrealistic to expect that everyone know how to disassemble the operating system kernel and have a soldering iron in one hand.

While I believe that nearly all businesses lean too far toward economy, I think this subject requires some balance between expertise and economy.

-Will

[…] of proving problems, and I was naive then, so I hadn’t yet developed a healthy fear of the Terrifying Triple: show, prove and […]

I agree with what Will said, essentially. People truly trained in computer science (and not just software engineering) generally have experience with all of the problems you mentioned above – we know about DeMorgan’s theorem and graph theory and how to use both, for example. In fact, the upper echelons of a theoretical computer science curriculum are essentially all about this sort of study – the programming ability is *assumed*.

Michael, I agree with you and Will too. My friends who were computer science graduates (from the same era?) are ok.

I just met quite a few programmers who don’t know fundamentals other than their “economic” value. The article’s more a rant than a statement really…