How to Think Like a Programmer: Part 1

This is the first of a three part series regarding how to think like a programmer.

Writing code involves a mode of thinking that is foreign to most people. However, writing code is not a unique process. There is actually nothing very special about it. But most people are simply unequipped to think in the manner required of good programmers. That is not to say that they are unable to put together a piece of software. Anyone with enough knowledge of the right libraries can glue together a piece of software that accomplishes some sort of goal, whether it be taking a list of URLs, fetching the results, and saving them to a specified file location, or maybe queries a database and displays the results in a particular way.

One of the recent discussions on TechRepublic, “Has calculus enhanced your IT career?” highlights the problem with the way people think about writing software. Too many people fail to look outside of the immediate problem when writing code; they are so focused upon the trees, they do not see the forest. Writing code does not require “thinking outside of the box.” It requires a view in which the box is gigantic. Too many people, when writing code, look at the tools that they are already familiar and comfortable with, and see every problem from that perspective.

One example of this is the passing of tabular data that is in a rigid format (such as the results of a SQL query) via XML. I have written all too often about the inefficiencies of XML as a format; it is particularly inefficient for this type of data transfer. A flat file format, such as CSV or a fixed length record format, would be created, transmitted, and parsed by the client significantly faster than an XML format. But programmers feel comfortable with XML; JavaScript has built in handlers for it, and the methods for working with it are well documented. In reality, it takes only a few minutes to write a CSV or fixed length file writer on the server side, and only a few more minutes writing JavaScript to consume it. But few people do things this way, because XML is a “chicken soup” format, it feels comfortable, it is known, and there is no work needed to use it. This is an example of the adage, “when you have a hammer, every problem looks like a nail.”

For decades, programmers were scientists or mathematicians who ended up writing code. The mode of thought needed to write quality code is very close to the way physicists, biologists, mathematicians, etc. approach their problems. Interestingly enough, much of the literature in the field of Computer Science nearly always ends up in the realm of Philosophy. Any discussion on Artificial Intelligence is going to take about three seconds to become a philosophy discussion; there is no way around it. Some of the most interesting uses of computers for research purposes are being done by philosophers working with game theory. “Philosophy” simply means, “the study of something which cannot be quantified.” As a particular topic becomes more rigidly defined, it becomes a subset of philosophy (such as psychology in the years of Freud and Jung). Eventually, someone finds a way to quantify the topic, and that is when it becomes a science (psychology after Skinner).

To be not just a good programmer, but a great programmer, you need to understand the scientific and philosophical ways of thinking. There just is no way around it. I worked for a company where most of the programmers had degrees in Physics and other similar scientific fields. They were excellent programmers. The programmers that I have met that came through a program where they were taught how to write code simply were not as good. Their education was based upon the syntax of a particular few languages, how to accomplish certain tasks. This is how oriented programming. These programmers simply did not understand the why of what they were doing. What Calculus (and other high level math courses) teaches someone is not just the math itself, it teaches a way of thinking about problems. This way of thinking is crucial for any programmer.

You can be a “shake and bake” programmer by going through something like DeVry or Chubb or Kumar, or whatever. But if you do not extend your knowledge, you will have a very hard time being more than just the type of programmer who glues libraries together. You will have a hard time working on the high level projects, like Artificial Intelligence, compiler design, languages, kernels, device drivers, and so on. No one wants to hire someone to be writing machine code or assembly, or some other low-level code who will be writing inefficient code, or who does not understand the principles of algorithms, and so on.