The prevailing wisdom is that software careers are short. Matthew Heusser suggests an alternative perspective—that the short life of a tech career creates additional options and, toward the end, may even be worth letting go of.
I’ve been writing lately about the modern technology career. These jobs require a great deal of ongoing education, yet the ladder seems too short. By mid career, the way forward is unclear and we run into age discrimination.
Age discrimination is more than just a bias. There are system forces at play. My Windows development experience in Visual C++ 6 is not as relevant as it used to be. At the same time, my experience and lifestyle costs have increased since my twenties. With experience comes an expectation of more pay, but new technologies emerge and the technologies of previous decades become less relevant. Is it really any surprise that finding a job gets harder after ten or fifteen years of experience?
It's easy to be envious of those new graduates of MIT, Berkeley, and Carnegie Mellon. They get to go work for some hip company like Yahoo, Groupon, or Google with its office ball pit. But, perhaps we have the story wrong—or, at least, we may be looking at the wrong side of the story.
Let's Change the Discussion
What if we looked at the software developer's first programming job not as the goal but rather like residency for a doctor—the first step on the ladder? After the residency, you get to specialize.
My friend Tessa Welsh once told me that even though she began with a programming job right out of college, her goal was project management (PM). She had to take a programming position because she was fresh out of school and could not get a PM job. Four years later, a PM position opened up at her company, she applied, and she’s been a project manager for ten years now.
For some, programming is a calling, but for many more, it might be a one part of a much more complex career. If the half-life of a programmer is ten to fifteen years, then in ten to fifteen years half of all new programmers will have moved on to something else.
Possible IT Specialties
Many of those chicken-and-egg experience jobs go to former programmers. It's not just line management and consulting, but also technical writing, teaching, business analysis, and sales. Don't envy the new graduate for his one opportunity. Feel sad for him. It is unlikely that he can get started in security or IT auditing work, performance testing, or recruiting without the kind of experience and contact network that take years to build.
So, yes, the programming career ladder may end in ten years, but that does not mean you have to fall off. The top of one ladder can lead to the bottom of the next. The important thing is to pick a direction (or perhaps a few) early enough to have some real alternatives.
But I Want to Stay Technical!
If half of programmers will be gone in fifteen years, then the other half will still be around. Half of those who are still around in fifteen years will still be around in thirty years. So, if you want to be part of that half, that’s fine. There is nothing wrong with that. I even have three practical suggestions.
The simplest thing to do if you'd like to stay technical is to pick a domain where technology does not change much. Within fifty miles of my house, there are four major shops that retain programmers writing with COBOL, CICS, and MVS. Long tenure is common and the work is routine, but it is relatively stable. However, trying to pick which technology won't change much is tricky. Today, embedded C/C++ and Java seem to be the most enduring options.
If you want to stay in programming but like change, you could invest heavily in professional development. Bob Martin, the author of Clean Code, suggests that programmers invest twenty hours per week learning new technologies. You might not spend twenty hours, but, between discretionary time at work and a small investment at home, staying current is not as daunting as it often appears.
The third way is to create your own software company at night or, alternatively, contribute to open source projects. Selenium, the popular web-testing framework, actually started as personal project to automate testing of the open source billing and expenses tool that Jason Huggins was working on at ThoughtWorks. The billing and expenses application is long gone, but Selenium led Jason to a job at Google and later became the technical cornerstone behind the company he started, Sauce Labs. At Sauce, Jason may have quite a few worries, but I doubt that his employment tops the list.
Advice for Testers
My general advice for testers is to look for transfers within a company to something that is at least new to them. It might be customer service management, recruiting, development management, or project management. If they want to stay in testing at one company, I would look into either becoming a subject matter expert or, possibly, becoming closer to the programmers and thereby more valuable. That might mean writing code, but, more likely, it will mean learning to read code diffs and knowing enough about those changes to predict which features will be impacted by a code change. A final option is to specialize within testing, in performance, security, or possibly internationalization testing.
Planning for Change
"Responding to change" is a theme of extreme programming. How we react to change establishes who we are. It determines our destiny.
Instead of picking one thing to do, you might make a small list of six things that you could do, along with an experiment to find out if that sort of work is for you. If you plan experiments and revise the plan every three to six months, in two years you might find out that you are qualified for several jobs. Then, the problem will be in deciding which one to pursue.
Come to think of it, that's a pretty good problem to have, isn't it?
User Comments
I know *many* older developers who are thriving, who work in "strange" languages, such as Lisp. Or, they worked in robotics their entire working lives. Or, telecommunications, or machine vision, or security.
Why? Because they really enjoy the technology or the subject matter domain. These people who now are in their, ahem, 50's and early 60's have *actively* pursued positions and companies where they could develop in these technologies. At first, they happened to be in the right place at the right time (Cambridge, at the MIT AI Lab or some other place at MIT). But then, they learned how to pursue further opportunities. Or, people like me, who did not go to MIT, learned how to pursue such opportunities.
Technical people need to learn to network. Jobs will not drop in our laps. We need to try open source projects and see if we like them. If we never try other possible technologies, how can we tell if we like new things.
Your advice is spot on, Matt. I hope other people read this.
I'm surprised you didn't talk about the role of lead designer/architect. This is a vital role that none of those smart (but inexperienced) guys out of MIT are qualified for yet. Using your Doctor model... this is one of the surgical specialties. Others include very specific domains, like I/O drivers, operating systems, real time process control. There are narrow ladders for people who want to stay geeky and keep climbing. Good article.
As someone who has been a programmer for a lot longer than 15 years, I think that the paragraph about programming being a calling has a lot of validity. Conversely, the short halflife also has a lot to do with the fact that many people use programming as a springboard to do something else, like management.
Programming is a skill which many intelligent people can do, and it pays pretty well. Unfortunately, that means that many will seek jobs in this area who really don't have a passion for it. In addition, classical promotion pressures tend to push people who want to avance into a management track. I find it sad that people who really don't like to do this are in it because they have not found another profession that can sustain them. To be fair, a lot of the appeal of programming is the leverage which computers can provide in solving problems, and management is also about using leverage to solve problems - but with people and organisations.
This article also discussed the problem of technology obsolescense on a programmer's carreer. In my case, I found that most languages and UI platforms become obsolete every 8 to 10 years. I found that by focusing on the tools and techniques that suffered the least, I could leverage my experience the most. I found that databases were a constant in all the systems I developed, and old knowledge is still useful longer. I became (mostly) a database developer/architect, and found that my longer experience helps in that area.
Lastly, keeping it fresh is important. Every time I work in a new industry, I gain new business knowledge and become familiar with new tools. I also have taken an interest in biotechnology, and am persuing a masters degree in bioinformatics. I have also taken on a new mission in life: I want to do science and fight disease.
In conclusion, I would say: if you really like programming, you can be a programmer for as long as you want to - but that means keeping it fresh by making it part of a lifelong learning process. Having a mission helps too!
I have been in programming more than 55 years and I still am employed and I still enjoy it.