Stop being a programmer for a moment !

Budding (new) programmers may wonder, “what makes a good programmer” and what advice would you offer that would help make me a better programmer ?

My answer would be:

Stop being a programmer for a moment (maybe longer) !

Maybe an illustration would help here.  The engineers who design automobiles are likely very knowledgable about their craft, some even being experts in their field. But one failing I see in such “experts” is that they fail to put themselves into the shoes of those who eventually must repair those automobiles (all cars break down some day). Out of shear necessity I have had to learn how to work on my own cars. I recently had to rebuild the engine on my car. Guys (and gals) who work on cars often find themselves saying, “what was the guy who designed this thinking !”. As an example, my trusty old Geo Prism (which finally died after over 335,000 miles on it) had the alternator right up front near the top of the engine. It was so easy to take off, that I once went to the autoparts store, purchased a new alternator, went out into the parking lot and replaced the old one with the new one in a very short time and then walked right back into the store to get my refund for the core price on the old one.  Now my current car,  has the alternator hidden underneath the engine on the far back side of the engine in a place which makes it very hard to remove. Sure there is a plastic panel you can take off to get better access to it, but it was still a real pain to remove and replace. The point is, those who design stuff often fail to grasp what those who will ultimately use (and/or repair) it think.

When designing software, “stop being a programmer for a moment” and consider those who will use your software. One important aspect is whether the software has bugs in it. When software “breaks”, the end user can’t go to a mechanic and say “fix this”. Often they can’t even grasp what is actually happening and then end up suffering just trying to figure out what has happened to their favorite software. Programmers may feel that “bugs are inevitable and must be lived with” and that “I don’t have time to track down every bug”. If you feel that way, then IMO you are not ready to be called a programmer yet.  Now you may say that “time is money” and I can’t afford to spend that much time on debugging my software. Well, this experienced programmer can tell you that it can be done, but it requires two things.

(1) Debugging is an art!

Maybe more time should be spent on training programmers on how to debug their software. IMO, it is an art, and a rare one at that. I can assure you of one thing, that the compiler (or programming environment) can’t be your only means of debugging. The debugging skills of a compiler can’t compare to the debugging skills of the human mind. You can’t program a debugger that thinks like a human being. Despite all the science fiction you may watch and how they portray computers, simply put “computers are dumb”.  Computers just are faster than us when it comes to counting and stuff like that, but they are as “dumb as a door nail” (as the saying goes). Yes, computers are stupid! A young child only a few years old can master two languages at one time (ie. both Spanish and English spoken in their family) and yet the greatest super computer can’t even master one language (so called artificial intelligence is a overrated).  Debugging requires the powers of the human mind, requires the desire to “make it right” for the sake of the end user and requires experience.

Actually debugging is similiar to being a auto mechanic. Good mechanics are the ones who “care about the customer” and who will do whatever it takes to get it right. Good mechanics are those who “think it through”, rather than simply just start replacing parts. Good mechanics are those who have developed the “art” of diagnosis. The same holds true for programmers. Debugging is an art, which comes from experience, as well as the desire to “do it right” for the “sake of the end user”.

(2) Be a learner, rather than acting like a master.

What I mean is this. No matter how experienced you are as a programmer, often your end user is far more experienced than you when it comes to the task at hand, that your software must handle. For example, if you write software for a business (ie. a custom application for handling some important task they must do), then you need to be a “learner” which means take time to learn everything you can (in a reasonable amount of time of course) about the task at hand and the business who will use your software. I have written software for all sorts of businesses, from mom and pop video stores, quality control for manufacturing, lumber supply store accounting, machine shop estimating, etc. Each time I had to “learn” as much as I could about the end users and what they required for the task at hand. You may know more about programming than your end user, but you likely don’t know more than your end user about the task at hand. Also the needs of end users tend to differ from person to person, so one may need to ask lots of questions and to get answers from multiple users.

Beta testing is a good example of where sometimes this goes wrong. Most programmers think of beta testing as a means to get end users to find all the bugs in their software. You give a bunch of beta testers some poorly tested software and expect them to figure out where all the problems are. I think that is all wrong. You are the programmer and its your job to find most of the bugs before your end users get the software. Today, I don’t Beta test my software to find bugs. I have a program called a “PreRelease version” where a select group of users can purchase and use the software and provide feedback on what features are still needed for their specific situations. I add new features in steps during this program, but the discussions with users are not about all the bugs they find (because they find very few and I often find most bugs before they are even aware they are there), but they are about what features would help them solve problems. I want them to use the software in real world situations, so I can see what features I failed to consider would be required for their individual needs. I then add new features based on the feedback, but the debugging is my responsibility. As far as writing the software and being a debugger, I have to be the expert. But when it comes to improving the feature set of the software (new ideas), I have to be the “learner”. I have to listen to my customers problems. I have to see their needs. I have to try to put myself into their “shoes” (as the saying goes). Its kind of like an old time cobbler (shoe maker). He is the expert in making shoes, but he still has to measure the feet of his customers, he still has to put himself into their “shoes” so to speak (meaning he has to consider how they will use his shoes and the unique needs of each user).

Being a good programmer require some modesty and humility. Be willing to learn. Recognize that you don’t know it all. Recognize that others are effected by your work (for good or for bad). Don’t be lazy! Debug your own software, thats your job! Put yourself into the shoes of those who will use your software. Stop being a programmer for a moment. Be objective about your own work and consider the needs of those who depend upon your software.