Escaping the Legacy Skill Quicksand
Editorial note: The readership of this blog has been growing steadily, and I very much appreciate that. Thanks for reading! An enjoyable byproduct of this is that a lot of my posts these days generate a good deal of discussion in the comments. The only downside of this is that it’s growing harder and harder for me to respond to all of them. Disqus sometimes batches my email notification, and there are days when people are commenting on half a dozen or more different posts, so I lose some in the shuffle. For my regular readership, if I miss something you say, please don’t think it’s for lack of interest. If you really want to get my attention or thoughts on something and you don’t see a response, feel free to email me or reach out through the site’s reader questions section.
Now, speaking of reader questions, let’s do one of those. I was originally going to do a ChessTDD post today, but tornadoes were ripping through the Louisiana countryside like a vengeful wolverine today. The end result was that I didn’t really have the time or guaranteed power to sit at my recording and development desktop. I’m going to paraphrase today’s question so as not to have anything identifiable in there.
I’ve been working at a product company, focused mainly on specific, entrenched database technologies. This is causing me to lose touch with current languages and trends, and I’m worried that I’m getting stuck. How can I avoid being stuck and becoming an Expert Beginner? Can you offer tips on learning new languages and exploring other technical things?
First of all, let me say this. Asking yourself, “am I becoming Expert Beginner” is like an inverted Catch-22. An Expert Beginner wouldn’t engage in this sort professional introspection. That said, it is certainly possible to become pigeonholed into an unmarketable, aging technology. I’m sure someone out there reading is, and has for a long time been, “the VB6 guy” and that person is nodding ruefully. That’s a position that becomes harder and harder to climb out of.
At the core of this discussion is a debate I’ve seen play out an awful lot among people in the software world: is it up to your employer to help you stay current or is it up to you to do this in your spare time? I’ve seen this debate play out most ferociously in the context of the mildly pejorative “9-5 programmer” used to describe people who are in it for money rather than the love of the game. One side says “real programmers do it all day for work and all night for fun” and these folks are more likely to say that keeping current and managing your career is your business, to be managed on your own time. The other side says, “programming is a job, and part of the deal with a wage job is that your employer empowers you to stay current.”
Option 1: Get Your Employer to Level You Up
I’ve always viewed this as a false dichotomy and also needlessly adversarial. It’s as though the employer’s gain is your loss and vice-versa. Why not work out scenarios where it benefits both you and the employer for you to learn?
This really isn’t as hard as it may sound. For instance, I have a client right now for whom I’m doing some work, and part of it involves working with a framework that’s brand new to me (i.e. I’m learning on the job as part of a freelance delivery project). I wasn’t cagey about this. When laying out some tech options for the approach, I found one that seemed to be the best fit, feature-wise, but cautioned the client that it’d be a more expensive option, done through me, because I’d be slower with it. The client likes my past work enough that this was deemed acceptable.
Now a client has extremely little personal investment in a vendor. An employer is heavily invested in an employee — paying for benefits, worrying about unemployment insurance, etc. If a client is willing to agree to terms where one of the technologies I’m using is new to me, getting your employer to do this should be comparably easy.
The important thing here is to look for mutual win scenarios. Is there a modernization play here that the company may be interested in? In other words, do they use the legacy technology only because it’s just never been the right moment to start the long process of modernizing? If that’s the case, think of a small, tactical slice of functionality that could be modernized and propose it as a pilot, to be done by you part time. It’ll be somewhat slow going because you’re learning, but you’ll be able to take what you learned, turn around, and teach it to the rest of the team.
I can’t possibly speak to all possible scenarios, but the key here is to come up with one that (1) involves you learning some new stuff and (2) benefits management in some way. Coming to a manager and saying you want to learn new stuff for the sake of career development may work, but it’s ultimately asking a favor. Coming to a manager and saying that you want to learn some new stuff because here’s how you believe that new stuff will help the company and/or the manager… well, that’s powerful.
Option 2: Do It In Your Spare Time
Now it may be that the shop in question has avoided modernization not because it’s risk averse, but because its actual strategy is to shave cost to the bone by simply not modernizing. As long as those old, green screened AS400s haven’t exploded, you’re going to keep patching their software. Once they explode, the company gets sold off for parts and everyone goes to do something else. Or, maybe it isn’t that dramatic, but the idea is that the status quo is a strategy and you learning Swift isn’t a priority for anyone.
Now comes the “do it in your spare time” option that the “for the love of the game” programmers criticize the “9-5 programmers” for not being willing to do. But, here’s the thing — it doesn’t matter which of these you are. If you’re the former type, doing it in your spare time is no big deal. If you’re the latter, then think of it as a temporary investment. And, in neither case, should you go out and try to boil the ocean. This learning isn’t generalized information seeking for the advancement of human knowledge. It should be targeted and focused.
Doing things in your spare time is necessarily a time-sink, so also identify what your’e going to displace. It’d be great if you currently waste a lot of hours watching reruns on TV or something, because you can just not do that. But, if you’re busy, you’ll need to shave hours from somewhere. That’s obviously going to be quite personal, but one thing I’d suggest is that you scale back your hours at work to the minimum to focus on this. I don’t believe in misappropriating company time in bad faith, but that doesn’t mean you have to sink 50 hours per week into a dead end tech (which is likely also to mean a dead end job). It is entirely likely that your new, open source venture is going to be more beneficial to your career than a few pats on the back for extra hours at work.
Option 3: Get a New Job
Whereas doing it in your spare time favors the “love of the game” programmer, this one is the “9-5” programmer option. It is unfair to spontaneously ask an employer to pay to level up your skills to no benefit, but you’re not negotiating from a position of strength with an established employer. You would be, however, negotiating from a position of relative strength with a new employer (I might cynically argue that negotiation of initial work arrangement is the only position of strength you’ll have until you threaten to leave or resign).
So you can go out job hunting a bit, being picky about it. You’d want to start somewhere that they have you working with more modern technologies. The ideal way to bridge this gap is to look for positions that call for your existing skills alongside some new ones, but you could even make a total jump under the right circumstances. Keep in mind that asking a prospective employer to take a leap of faith on someone not familiar with some of these technologies is an ask, so you’ll have to offer consideration — take a bit less salary, ask for less PTO, start without a title advancement, etc. Think of learning new things as one of the perks they’re offering, and barter accordingly.
This is a long game. You might not get any offers for a while, but time is on your side if you do option 2 in parallel with this one, overlapping the skill you’re learning with the jobs you’re seeking. Don’t rush it, particularly if your existing situation isn’t bad. Sooner or later, the right thing will come along.
Option 4: Non-Technical
I won’t speak to this at any length, but I will point out that this option exists. Over the years, I’ve seen a lot of people stage victorious retreats from the technical. Usually this means some kind of management role, preferably line management, but often dotted line product/program/project/etc management. In some organizations an architect role counts here. Often, in a degenerative technical situation, this is deus ex machina granted when frustration threatens to set in with a tenured employee.
It’ll Work Out
Which brings me to a concluding thought, particularly since this wound up suddenly getting way longer than I intended. Whether it’s someone coming along and offering you some kind of supervisory/management-y role, or whether it’s a new project that comes into the company’s door unexpectedly, or whether it’s a job offer out of left field, something will happen. It’s easy to be convinced that you’re stuck and that with each passing day your market value atrophies more and more, and that becomes sort of a psychic prison. You won’t be there forever. But don’t leave it to fate. Figure something out with your manager to let you level up. Do things in your spare time. Pursue better jobs. The more you prepare and work for it, the sooner that stroke of ‘luck’ will come along.
If you want to ask me a question to answer with a post, please do so: