“Hi, my name is Doug and I am a coder.”

Coding was not an immediate addiction. I first met a computer in 9th grade – a timeshare system that I accessed via teletype. We used an early form of BASIC, and while I thought I saw some promise, it was nothing that really interested me.

In college, my initial experience with computers was a course that taught elementary COBOL. We had to use punch cards and my final program never ran. After running it a number of times (and each time, bringing the mainframe down, much to the horror of the students waiting behind me to get their card deck read), I simply wrote a note to the professor that the code looked correct to me, but the deck seemed to drop the computer each time I had it read, and rather than risk my life at the hands of angry geeks, I was submitting the program deck without any output. I never heard back, but I did get a B.

A number of years later, I worked for a company that sold and serviced photocopiers. When the first Franklin computer (an early Apple clone) showed up in the office, I was hooked. My addiction was further fed by buying my own Atari 800. The interactive nature of the personal computer was totally different from the mainframe I had previously experienced; I discovered that I really enjoyed creating code. It took a while, but I slowly moved from selling and servicing photocopy equipment into developing software.

Is there coding life after 40?

I was about 40 the first time I was told I should not continue coding. A well-meaning vice president at my company pulled me aside at a party and told me that I was getting too old to code. He had been a coder himself, knew that he was getting too old, and moved over to sales. He was sure that I should be moving over to another part of the business. I told him that perhaps not only did he have a problem coding when he reached 40, he probably had the same problem at 38. I said that I was perfectly happy as a coder, and had every intention of continuing as long as someone was willing to pay me.

The next time I noticed this phenomenon was when Ed, a good friend and excellent coder, was encouraged to move into a management position in order to advance his career. The company apparently had no career path for a really good developer with more than five years of experience. You simply reach a point where there is no hope of any salary increase beyond the normal cost of living adjustments, no matter how capable you are as a software developer. I have seen the work that Ed has done, and he has raised the game of software development in that organization to a level that would have been unimaginable only a few years earlier.

I got to thinking about all of this when I read a column in the January 2005 issue of Software Development magazine by Howard Adamsky, titled Save Your Job. His basic points can be summarized as follows:

• Do not plan to write code for your entire career.
• Learn to communicate effectively.
• Develop people skills.
• Move into the “people” part of the business.
• Learn how to sell.
• Consider consulting.

There are a number of good ideas in Mr. Adamsky’s column. Certainly, I have paid attention to effective communication. I maintain two blogs, have spoken at the SD Expo conference (interestingly, sponsored by the folks who publish Software Development magazine), and have written all or part of a number of books. I like to think my people skills are acceptable. Since the .com disaster, I have worked as an independent consultant, developing primarily web and mobile applications, with the occasional mobile web application thrown in.

I used to be a sales person, and while I kept food on the table, I did not enjoy it and have no interest in doing it again. I also have no interest in moving into the “people” part of the business and becoming a manager. I understand that someone has to do it, and although I’ve often complained about the truism that those who do not understand technology are the ones who manage it, I do not feel the need to become a manager in an effort to right that wrong.

Mr. Adamsky’s first point about not planning to write code your entire career as a solution to keeping your job rubs me the wrong way. At first, I thought perhaps he was making a distinction between being a coder and a developer, a distinction made very well by Mike Gunderloy in his excellent book, Coder to Developer. Mr. Gunderloy differentiates a coder – someone who understands the syntax and semantics of one or even a number of computer programming languages – from a developer – someone who can turn out a full application with all the required supporting details.

If I was a COBOL-coding drone who just translated detailed specs into executable code, I recognize that I could easily be replaced by someone willing to work for a whole lot less. But, reading the column, it was obvious that Mr. Adamsky was talking about both coders and developers. I quote:

There’s little future for someone who only programs. Code is a commodity that can be created by other people for less money – much less. Think of coding as the beginning of a career – a great place to start, but not what you want to do for your entire professional existence.

Consequences of inexperience

What is the likely consequence of everyone following this advice? I do not think we really need to speculate a great deal; in many respects, what he is proposing has mostly happened. Folks like me who enjoy coding are told we are too old. Folks like my friend Ed are told that coding is a dead-end job, and that if he wants to advance in the company, both in terms of prestige and salary, he needs to become a manager and leave what he loves to do, and what he does so well. I go to a gathering of the Microsoft MVPs or ASP Insiders groups and see that I am one of perhaps five or 10 percent who are older than 45. What is the consequence of having the vast majority of coders at (relatively speaking) the beginning of their careers?

One consequence is that a large part of the coder workforce is recently out of college, and as Joel Spolsky describes in the wonderful foreword to Coder to Developer, they are convinced they know everything they need to know about software development. The sad fact is that they do not. They are not bad people; they just do not know what they do not know.

Jim Rapoza, in the Tech Directions column of the January 10th eWeek, talks about saying “no” to bad code. He talks about all of the things that cause bad code, and the reasons that software companies seem to do nothing to solve the problem. One of the most maddening things for people outside the tech world is dealing with software developers. When a user describes a problem, developers often say that it is “impossible.”

Many years ago, I would hear about a problem a user was having with one of my programs and I would often say “that is impossible.” Fortunately, I’ve worked in organizations that did testing by watching what the user is doing via two-way mirrors. I’ve seen the impossible happen. I hope that in the last 10 years or so, I have become wise enough to never say something is impossible, but rather to say “I have not seen that, but let’s step through exactly what you are doing.”

Serving the user

I firmly believe that much of bad software comes from a lack of imagination over how software might be used in ways different than those we anticipate. While our industry should not underestimate the value of a newly minted computer science graduate’s enthusiasm, it should also not underestimate the value of a somewhat less enthusiastic, but seasoned, interested and experienced coder.

Certainly, many coding jobs can be moved offshore to coders who will work for a lot less money. Coders who do not keep up on the latest changes in technology and software development will, and should be, left behind. But, the work these sort of coders do is not the work I am interested in. I work off site for a number of clients, both locally and in other states (in one case, in another country). While there is some overhead associated with getting me up to speed with what they need in a new or remodeled application, my clients benefit from my relative physical proximity (in most cases), common language, idioms and experiences, and 20+ years as a coder.

We do a disservice to users of our software when we encourage coders to leave the field when they become experienced, and force the real superstars into management if they want to advance.