The Best Programmers have OCD

Sometimes talking, or in the case blogging, about a problem is a good thing.  I have been thinking what makes a good programmer.  Why is this programmer better than another?  Why can some programmers remember their code while others forget it minutes after typing it in?

Maybe the good programmers have some mild form of OCD (obsessive compulsive disorder).  The one symptom that seems to fit was constantly check and re-checking things.  I cannot tell you how many times I look at code and look at code and look at code to see what I have written is okay.  But the difference, with me at least, is that I can do this in seconds not minutes or hours.

There is many a time while driving, sleeping, eating, or doing chores that I figure out what is wrong with a piece of code. That I believe is the obsessive portion of my brain.  I cannot stop the process whether it is conscience effort or by letting to code lie like a sleepy dog.

Maybe it that obsessiveness that creates programmers that are the best.  None of their code is good enough.  The brain never stops. They strive to be the top of their profession but do not always work well with others. The skill set is well defined not to one style of programming or even one language type. They are more than bilingual.  They are a polyglot of programming languages built into a bundle of "nerddom".

Probably the most distinguishing feature is they sometimes tackle projects and quickly hack the code.  Whether the code is pretty or good that is not the point.  The point is that the code is done and finished quickly and can be improved on the next iteration.

Here is what  Mark Zuckerberg's letter to investors February 2012 about the hacker way:

The word "hacker" has an unfairly negative connotation from being portrayed in the media as people who break into computers. In reality, hacking just means building something quickly or testing the boundaries of what can be done. Like most things, it can be used for good or bad, but the vast majority of hackers I've met tend to be idealistic people who want to have a positive impact on the world.
The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it -- often in the face of people who say it's impossible or are content with the status quo.

Sometimes the OCD programmer is someone you would never guess has it in a million years.

Debugging versus Logging

Being first to the market with our XLr8Editor for Universe and Unidata, we were asked why we did not have a debugger.  Most of the time the answer was that you could not hookup to Universe's RAID debugger or Unidata's debugger without Telnet session and some type of changes to both products.  After Rocket Software's BDT came out with a debugger we looked at what they had done.  Rocket Software had changed both Universe and Unidata to talk to Eclipse.  Now our answer was that we needed access to the API they wrote for Eclipse.

In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."

We have found the debugger certainly has its place but we are not Fan Boys.  Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies?  Maybe you are not even getting to your UniBasic code and your error is in the JavaScript.  That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console.  In our UniBasic code we call a logger throughout our code.  This logger subroutine writes out data to a file which we can use later to figure out where our problem is.

We always do say that logging has its problems.  It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved.  However, we find that the process is much cleaner and we can look at the output long after the program has been run.

Vindication of our Release Strategy

Many U2 (Universe and Unidata) programmers had disliked and voiced their opinion negatively when U2logic announced many years ago that our XLr8 Tools was going to 3 to 4 week release cycle. We felt that most of our bugs and enhancements could be released after they had been completed, unit tested and quality tested.  While Firefox, Chrome, and Safari browsers were getting released at least every month and half, we did not see any reason we could not do the same even though we have a smaller team.

Just the other day Rocket Software announced that it has been releasing it's Eclipse based tools almost every month since March of this year.  They also stated that they had fixed around 60 bugs, plus added many new features.  A competitor vindicates our strategy.

During the same period as Rocket Software, U2logic has enhanced and fixed over 140 items.  We should be patting ourselves on our back for a job well done.  This represents a lot of work from our staff of programmers, testers, QA's, and customers.

Whenever we are going through our Bugzilla items and deciding what we will tackle in the next few weeks, we are always aware of this mandated release schedule.  We have stopped working on some enhancements because they are taking too long and would contribute to a slower release schedule.

The question becomes can we keep this strategy going for more than a couple of years?  Is this strategy harmful to our customer base?  And last but not least, can we remember what the release numbers mean after 10 or 15 releases?

Just in case you have not updated your copy XLr8 Tools, the current release is 3.5.15 which was released yesterday.