"Anyone can program, but not everyone is a programmer..."

By Everett Lockhart
January 04, 2007 5:23 PM EST

As a child, did you ever pretend to be a fireman? Did you ever take your dad's tools and build something from start to finish -- something like a club house, a tree house, or even a soapbox car (cart)? Have you ever made a bridge for a train set? Have you ever drawn a house, a car, or a building on a piece of paper? If so, then by some standards, you are an architect! In fact, you are also an engineer!

Are those statements believable? Can you believe that simply because an individual drew something, like a house, on a piece of paper, that they can be considered an architect? Anyone can draw a picture on a piece of paper, but to actually design this structure properly, the discipline of architecture must be studied.


Now, I would like you to listen to the following phrase, which is often echoed within the ranks of members of IT management, members of the human resources departments, and others within the IT community. " ... programming is not that difficult. Any body can be a programmer. So, just hire someone, we'll teach them what they need to know." Is this true? These words are very, very misleading. Yes, one could find some degree of truth in them, in fact I will agree that almost anyone can be taught how to program, but that doesn't make them a programmer, in the true nature of the word. That would be the same as saying, anyone that I teach how to draw is by default an architect, or an engineer, and they can go out and design bridges and buildings.

Programming is a discipline, a discipline that is often undermined and taken lightly. Superficially, it may be easy to say that anyone can program, but in the "world" of a programmer, it is a well known fact that not everyone is a programmer. Just like any legitimate discipline in today's world, one must study to become proficient. Some people are born with the talent to program. There are also those who study the theory behind computers and programming, and they eventually become very good at it. Nevertheless, at the end of the day, it is not feasible to classify everyone who knows a programming language as a programmer. To be a good programmer you must have an aptitude for logical thinking and analysis, problem solving skills, clarity of thought, patience, a natural curiosity for how things work, an acute attention to detail, the discipline to do things the right way, and above all, an understanding of computers and how they work to accomplish the things that they do. It is easy to teach someone a programming language, or provide them with programming tools (that produce much of the work for them), and give them projects to work on, but this doesn't mean that they understand, truly understand, what they are doing.

In today's world of the IT professional, I have met many individuals who use tools that aid them in programming, yet they lack a basic knowledge of what is actually going on. They claim to be programmers, and boast that they can "code anything", with the help of an IDE of course. However, when asked can they code from scratch, they normally reply, ' ... why, when that does it for me'. Yes, the tools of today are capable of doing the majority of the work for programmers, but this doesn't excuse them from actually learning how to do what the tool is doing. This is not to say that programmers should code everything from scratch. These tools make their job much more efficient. However, what happens when the tool is unavailable? What happens when there is something that it cannot do? What happens when there is a problem in the code written by the tool? Can they dig into the code and fix it? It's probably safe to say that not many could. These "programmers" have no clue on how to "program". They are just exceptional application users who know how to combine a series of mouse clicks to produce, or reproduce, a desired result. This is not programming! They can't explain why sometimes it may be better to use a linked list verses an array, when to use an AVL tree instead of a binary tree, the difference between quick sort and bubble sort, or why it may be better to use Stringbuffer instead of String. These are people who have never written an entire program from scratch in their life, and they don't see a need to do so. They rely on the IDE's to produce the majority of the code, and they provide simple code snippets, found on Google, when necessary. And, when something breaks (really breaks), or when something runs too slow; they don't have a clue as to what the problem is, or where to look to begin to solve it. So, I now ask you, "Is anyone who can program, a programmer?"