Too old to program

(Cross posted from my java.net blog)

I was drawn to E-Surfer's recent weblog entry that asks the question: "Could I Still Pursue Software Development Career When Getting Older?"

E-Surfer's "friends" warn him that:"when getting older I would not be competent to pursue software development because of slowness of thinking, difficulty reading and writing, and so on."

I will be 48 years old on my next birthday, and I have been professionally programming since I got my BSEE degree from Rice University back in 1980. I freely admit that my memory is not what it once was, but I am pretty sure that "slowness of thought" and "difficulty reading and writing" will never be the primary reasons that someone leaves the programming profession.

I started programming when many programmers were also digital logic designers (hence my electrical engineering degree). While I was in school, the 6502 microprocessor and the Z80 microprocessor became widely available, and almost everybody that I knew was wire-wrapping chips together on perfboard to build their own "personal computers".

Cheap microprocessors transformed the world, and resulted in an explosion in the number of professional programmers.

An odd personal side effect of starting my career at the dawn of the PC age is that I have always been one of the oldest programmers at every company where I have worked. I was dealing with being "the old guy" before I hit 30.

For me, the biggest obstacle to staying in the programming profession has been the frenetic pace of change. Programmers must continually learn new lanquages, new operating systems, and new devices just to stay employable. For example, in '85 my MSCSE focus at the University of Texas at Arlington was on computers that were optimized to execute Lisp. Lisp programming positions were always few and far between, so I relied on assembler, Pascal, 'C' and FORTH to pay the bills. By the 90's, C++ was on the scene, and along with it the need to leap from structured programming to the OO paradigm (thank heavens!).

The advent in the mid-90's of the Internet and Web-based applications once again negated much of what I had previously mastered. Along came Java: first applets, then servlets and JSP, and now a plethora of client and server side technologies (most of which have something to do with XML).

My point in relating all of this is that programmers must commit themselves to life-long learning. With the possible exceptions of a few safe-harbors (like mainframe COBOL), practitioners must keep abrest of changes and be prepared to discard their tools, languages, and paradigms every 2 to 3 years (at best). With the dawn of EJB 3.0 will you ever again use the esoteric EJB 2.0 home and remote interface knowledge that you needed to pass the J2EE certification exam?

I have never been "put off" by the demands to learn new things, but I do get very cranky in the realization that much of what I must learn is about reinvented wheels rather then better wheels. I have probably learned over 20 ways to implement what is essentially a modal dialog box. Where's the value in that?

Rather then failing health and mental accuity, I think burn-out is what does most programmers in. I think we just get tired of fighting the same old battles and move on to other things.

Fortunately, I believe that the profession is on the verge of getting much, much better (in terms of sustainability). As I've blogged before, adolescence is over and the industry is maturing. I do not expect the pace of change to slow, but I do expect that the nature of the changes will be more manageable.

Much of my optimism is pinned to the renewed interest in Service Oriented Architectures and Business Process Management.

Programming has long suffered from two major faults:

1. The mappings between requirements and implementations have been vague at best
   


2. The elements of our programs are too tightly coupled to each other (and to languages, frameworks, etc.)
   

With SOA (done right) the business services that programmers develop will be accessible to clients that are clueless about the implementation.

With business processes running on BPMN engines the mapping between the business process and the requirements will be crisp (and language neutral).

BPM and SOA will be good for the professional programmer because they will bring to the foreground the skills that are not tightly coupled to specific languages, operating systems and devices.

Programmers are problem solvers. Programmers are logical thinkers. Programmers can figure out why it doesn't work. Programmers like to build new things and make old things work better.

Perhaps some folks think that limits programming to young folks, but I respectfully disagree.