A Long View of the "Short" Technology Career

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?