In the last few years I have become increasingly aware of a chasm between programmers and computer scientists.  It seems like the two have nothing in common when in fact they should be one and the same.  To be a truly great programmer you must also be a great computer scientist.  Why is it that so many programmers have no concept of computer science?

This chasm has been there all the time, but has been made more apparent the more I study computer science.  What is the difference between a programmer and a computer scientist you ask?

This post stereotypes the programmer and computer scientist.  I exaggerate the weaknesses in each to illustrate a point.  Obviously, this is not necessarily the case and this post should not be viewed as a rant or an attack on the two types of individuals mentioned here.

The Programmer

The typical programmer is someone who writes code on a daily basis.  They are familiar with a few programming languages and their API’s.  The vast majority of programmers are only aware of the C family of languages (C, Javascript, Java, PHP, Actionscript, etc) as opposed to functional languages (LISP, Scheme, Erlang) or concatenative languages (Forth, Factor).  They typically write the same type of code over and over and never think they can abstract it out to make their work easier and less repetitive.  Their thinking, and hence their ability to solve a problem, is constrained by the tools they use.  Even after doing something over and over they never have the thought, “There must be an easier way to do this”.

The Computer Scientist

The computer scientist is someone who knows a lot of theory, is well versed in math, and understands how computers work at a fundamental level.  They see the computer as an abstract system of computation.  They are usually more involved with academia rather than day to day programming.  When confronted with a problem they break it down into its fundamental parts and then build a model to solve it.

In short, the computer scientist is someone who sees a problem and builds a tool to solve it.  The programmer is someone who is familiar with a few tools (languages / API’s) and uses them to solve his problem.

The Problem

The problem is the programmer is constrained by his tools.  You may have heard the saying, “If all you have is a hammer, everything looks like a nail”.  The programmer will eventually get the job done but not necessarily in the most elegant or efficient manner.

The computer scientist doesn’t really spend much time in the trenches, so to speak, to know the problems facing the average programmer.  They are more concerned with solving purely intellectual problems.  As a result the computer scientist doesn’t build the tools the programmer needs or does so in a way that is not very useful, convenient or easy to use for the programmer.

So, computer scientists don’t actually use the tools they create or know what tools need to be created and programmers only know about the typical tools other programmers are familiar with.  Programmers don’t spend much time researching to see what other tools are out there or bother to create their own tools.

The Reason

There are some reasons why these situations exist.

The programmer usually writes code for other people.  They are charged with getting a job done and they are only interested in getting that job done as quickly as possible.  When confronted with a problem they look at their tools they have in front of them and then set out to work on the problem.  As soon as they get the job done there is more work for them to do.   As a result the programmer typically has little time to learn new languages, environments or API’s.

Not having a solid background or interest in computer science the programmer often does not know there is a better way of doing things.  They have learned from other programmers that is all there is.  They are not accustomed to taking a step back, abstracting out what they are doing, and developing a system that allows them to get the job done faster in the future.

Building tools takes time.  If it takes 30 minutes to get a task done and it looks like it would take a full day to create a system to do the same job in 30 seconds the typical programmer is not going to want to spend their time working on it.  They are not going to want to explain to their boss why what previously took 30 minutes is now taking 8 hours.  If there are other programmers around, they don’t want to look like an incompetent idiot while their fellow programmers are, at that moment, finishing much more work.

There is also a break even point.  If it takes 30 minutes to solve the problem and the problem only comes up a few times a year it would be counter-productive for the programmer to spend 8 hours coming up with a system to let him solve it in 30 seconds in the future.  If on the other hand, it is something the programmer does on a daily basis, that same 8 hours is going to pay for itself in less than a month.

That’s a 6000% ROI in a month.  How would you like to make that in the stock market?  Unfortunately, the typical boss is even less aware of a better way of doing things or is in the same situation where he is reporting to someone else and doesn’t want to have to explain why it is taking longer than normal.

Typically you are not going to see 60 times increase from creating a tool.  But you may see 5 times the increase and that’s nothing to ignore.

As mentioned before, the computer scientist lives in the world of academia.  They typically don’t work on the same things a programmer would on a daily basis.  As a result the problems they solve are a little grander in scale and do not always have direct application.  Again, this is a generalization to illustrate a point.  Academia has provided enormous value to modern programming.

The Solution

I have attempted to illustrate the weaknesses of strong polarization to only one side.  The obvious solution is to move towards the middle.  The programmer should learn more about computer science and theory.  The computer scientist should spend more time working on real world projects.

For programmers, I recommend the books The Pragmatic Programmer and Code Generation.  Study other programming languages, especially those that are radically different from what you are used to.  LISP, Ruby, and Factor are all good candidates I would recommend.  Look at open source projects, especially frameworks and see how they do things.  They will expand your mind as to what is possible and make you much more efficient.

Posted Sunday, January 4th, 2009 at 2:46 pm
Filed Under Category: Miscellaneous
You can leave a response, or trackback from your own site.

2

Responses to “The Digital Divide”

AndrewBoldman

The article on antibiotics are very good.

CrisBetewsky

Some of us even don’t realize the importance of this information. What a pity.

Leave a Reply

You must be logged in to post a comment.