Programmers: Before you turn 40, get a plan B

Welcome to geezer town, junior.

While researching my recent article, “Age discrimination and Programming Jobs” , I discovered a 1998 Op-Ed piece from The New York Times that cited some startling statistics from the NSF and Census bureau about the longevity of a software engineering career.

[S]ix years after finishing college, 57 percent of computer science graduates are working as programmers; at 15 years the figure drops to 34 percent, and at 20 years — when most are still only in their early 40’s — it is down to 19 percent. In contrast, the figures for civil engineering are 61 percent, 52 percent and 52 percent.

RetiredProgrammerButtonI find the defensive tone of the article and the use of dubious sampling of only computer science graduates to support its conclusion undermines its credibility. In a lot of ways, the Government has been very slow to grok the software engineering trade. In this study it completely ignores the significant number of working programmers who either earned their degree in another discipline or never finished college.


 Still, smart money seems to concur that the software engineer depreciates only slightly more slowly than the machine he or she toils behind as exemplified in this 1996 comment from Craig Barrett, then President and Co-founder of Intel.

The half-life of an engineer, software or hardware, is only a few years.

Sure, the guy’s a suit, but more importantly he was (at the time) a 57 year old former engineer publicly reinforcing the discriminatory notion of expiration dates on other engineers. It’s scary as hell to think that such an influential industry insider thinks that a programming career is roughly the same as a professional basketball player’s.


My take on the issue

Considerable accusatory ink has been dedicated to the age discrimination problem in technology, but I suspect it may be an inevitable consequence of the rapid pace of change that defines this field.

Consider the following:

  • The market value of an employee is primarily determined by experience in technologies relevant to the employer.
  • Software engineering reliably undergoes a major technology shift at least every 10 years.
  • While a technology shift doesn’t completely negate the skills of veterans, it certainly levels the playing field for recent grads.

Now put yourself in the shoes of a prospective hiring manager using a newer technology like Ruby on Rails for which nobody other than David Heinemeierhas more than about 5 years of experience.  Sure, that extra 10 years of C++ experience is a positive differentiator for the veteran over the upstart with the same 3 years of Rails experience.  All things equal you’d naturally hire the guy with more total experience.

However, all things are NOT equal. Those 10 years of C++ experience made the veteran candidate progressively more expensive as they leveraged the value of that experience in jobs requiring C++. The problem is that the marginal utility of that extra experience must exceed the marginal cost of hiring the veteran to justify paying the premium.

Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes, and this presumes that the manager even has the luxury of paying extra to get that experience.

Even if the veteran prices himself competitively with a younger candidate, the hiring manager has to consider the implications of bringing in someone taking a big pay cut. Will they have morale issues from day one? Are they going to change their mind after a month that they really do need that extra cash and leave? It’s a sticky situation.

The unfortunate truth is that unlike other forms of discrimination that are more arbitrary and capricious, age discrimination can often be a result of objective and sound business justifications. I’m not trying to justify it as an acceptable practice, but just trying to describe the pickle it puts the manager in trying to make a sound business decision without compromising the ethical and legal obligations of the company.

So what’s your plan B?

Assuming you aren’t fabulously wealthy, accepted to clown college, or the fatal victim of a Red-bull induced heart attack by 40 a mitigation strategy is in order. Here are some viable options.


Work for the one person who would never discriminate against you.

No. Not your mother. You! If you aren’t the entrepreneurial type, consider a consultancy. For some reason that I don’t completely get, a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.




Give in to the dark side and go into management.

I’d argue that a career in programming does precious little to prepare someone for management, but clearly management thinks that everyone including technologists harbors a deep longing to “graduate” into their ranks. I think it a fallacy that no one would continue to design and build software for 20 years unless they had no ambition or growth potential. However, people like me that respect such dedication to the craft are in the minority. Maybe it is best to just stop fighting it, but consider the following before taking the plunge:

  • Mid-level managers often make very little more, if not the same as high level engineers.
  • It gets progressively harder to keep up with new technology because you don’t work directly with it.
  • Meetings, politics and dealing with unrealistic requests will pretty much become your life.
  • You may try to avoid it, but management-speak will creep into your vocabulary (did you notice my “paradigm” comment earlier?)
  • Even when it isn’t your fault, it’s your fault.
  • Even when you make it succeed, your team should get the credit.
  • Being the wunderkind as a technologist is much easier to do in technology than management, you’ll have to check your ego at the door.
  • You will be forced to make decisions that affect people’s personal life (pay, bonus, firing, etc.) and this is hard to stomach sometimes.
  • It is very empowering, enjoyable to be able to set the agenda and sometimes say, “No. We ain’t doing that shit.”
  • Computers are predictable, people are complicated. You will eventually fantasize about robot employees.
  • Mentoring can be very rewarding, but also very challenging.

The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment.
-Theodore H. White.

You’ve got a cash cow, milk that sucker!

I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time some snot-nosed kid invents a new way to run byte-code. You have invested a lot of time and energy mastering the technology you use, and your experience differentiates you. Money follows scarcity, and snow-birding on an older technology, if you can stomach it, may just be the way to protect your earning potential. The industry turns on a dime, but is slow to retire proven technology. It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades.

Selecting A Primary Programming Language

A question that I frequently see in technical forums and other places that programmers congregate asks for guidance regarding which programming language that someone just starting out in software development should learn first, or specialize in. Although it is asked in earnest by novice programmers hoping to mine the collective experience of the veterans, such subjective questions on religious issues are not likely to garner useful or consistent answers.

It’s like asking a group of people about their opinions on abortion. The issue is so polarized that you are likely to get a fairly dogmatic answer that reflects the worldview of the person answering without much context, at least not any context that integrates more than one ideological view.

How NOT to select a programming language

First, let’s get some of the WRONG reasons out of the way for choosing a language to specialize in. Almost every time this question comes up, the person asking either implies or explicitly specifies that the criteria they are most interested in are (A) earning potential; and (B) employment trends that indicate the marketability of the skill.

Don’t select a language based on earning potential

It is true there exists disparity in the average salaries of programmers based on the language they use. Aside from the ~$20K disparity for VB.NET, that I think has more to do with the baggage of the Visual Basic name than the real comparative value of those programmers, most of the popular languages are averaging within $5K/year of each other according to the numbers I found on (click image for more detail) and there have been several lead changes over the last few years.

Salary Trends by Programming Language for Austin, Texas

Salary Trends by Programming Language for Austin, Texas

It is also important to consider that salaries tend to spike for technologies as they near obsolescence because it gets harder to find candidates with experience in those technologies and are willing to risk sitting in the COBOL chair when the music stops.  I think the next major victim of this will be C++, but not for at least another decade or two.

A more important consideration is that these salary numbers are just averages and should only be used to get a general picture of the market for various skills.  In my experience, the level of experience and competence in a particular language is more deterministic on salary than the choice of language itself.

The premium for a programmer in their first job out of college in C++ might be tempting, but I have observed that discrepancies based on specific languages tend to converge over the course of a career and are much less pronounced for veteran developers.  As such, it is probably more useful to focus on mastering a language than picking the right one.

Don’t select a language based on marketability

Looking at the number of available jobs is perhaps the worst way to pick a programming language. This field changes too quickly for it to be wise to make long term decisions on short term trends. There are numerous examples of labor markets glutted with people who embarked on a career path because of a shortage was that drove up salaries when they started college. By the time those people graduate along with the 75% of their class who got the same diploma, the market once strapped for talent became excedingly competitive and consequently less desirable.

.net, java,,c#,c++,ruby,python Job Trends graph

 How to select a programming language

This is the easy part. Pick the one you like best! You are far more likely to invest the effort required to master a language that you pick by preference than one selected for purely monetary or competitive reasons. That said, the language you select shouldn’t win by default, but rather should be selected from a pool of at least 3 languages for which you have had some exposure:

  • Still in school?  Try to select courses that give you exposure to several programming languages and at least two platforms (Windows, Apple, Unix, etc.) You can hedge your bet by learning C++ which is extremely similar several other languages and will reduce your learning curve, but don’t use that as an excuse to learn just one language.
  • Early Career Programmer? At this stage of  your career, it is fairly safe to make a major platform shift when taking a new job. Employers tend to be more forgiving on lack of experience for a specific language on entry level positions if the candidate can demonstrate competency at programming in general.
  • Tenured Developer?  This is a much tougher situation. At this stage of your career, a lot of your value is often built upon experience in your primary language. Making a jump, for example from Java to C#, is likely to set you back a few notches on salary because of your relative inexperience in the specific language.

What types of projects do you want to work on?

Another factor you should be aware of, is that your choice of language is going to play a big role in the types of software development projects you will work on. The following are gross over-generalizations, but should give you a rough idea of the most common projects associated with each language:

C++:  System Programming, device drivers, computer science-y projects.
Java: Commercial Software targeted for Linux and Windows as an afterthought, Web development.
C#: Commercial software targeted exclusively to windows, Web development.
VB.NET: Internal Development, Systems Integration, Web development.
Visual Basic 6: More likely to involve commercial software development than VB.NET, but mostly maintenance work on legacy/cash-cow systems.
Ruby/Perl/Python: Scripting, Web development.

Culture Considerations

Although Hollywood  likes to lump us into broad stereo-types of nerd or hacker, depending on which way the pendulum is swinging about how hip it is to be a computer guy, we know that there is a rich diversity of subculture among us that don’t automatically co-exist peaceably.

The choice of a programming language is a lot like picking a table in the high school cafeteria. It will label you and go a long way towards determining what type of people you will have to put up with all day. I’d suggest familiarizing yourself with the culture of the language(s) you are considering through newsgroups and user groups before making a decision on a language.

Still can’t decide?

Is it all the same to you? This isn’t a good sign. If you don’t have a strong opinion about such a critical aspect of what you intend to do for a living, I’d question whether you made the right career choice to go into this business in the first place. Don’t you know there is a platform war going on out there soldier? Pick a side, get out there, and fight!

Final Thoughts

You really can’t go too horribly wrong on picking a language unless you select one on the verge of extinction. It may be slightly easier to make a little more money or find a job more quickly with some languages, but no matter which you chose, you will eventually find work and at a good wage if you invest the time to master your craft.

The bottom line is that you should follow your bliss when making any career decision. You are simply going to spend too much of the prime years of your life at work to do something you that don’t enjoy.