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.
Pick a specific, modern tech that you want to become versed in. Establish a toehold in that community by joining the right Q&A sites, attending user groups, reading blogs, etc. Then seek to create an actual, open source application for some useful purpose using that technology. Building a useful thing will allow you to focus the questions you ask in the community and the learning materials you acquire and use. You want to be able to combat the pigenholed reality you currently face by showing some future hiring authority an actual app you built in Javascript or Scala or whatever.
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:
No Fields Found.
I tend to have a foot in both camps when it comes to being responsible for career development. I certainly spend plenty of my own time outside of work reading and writing code, but I also spend about 30 minutes of my 8-hour work day catching up on RSS feeds like this one. I do timebox it, though, to keep it from eating up my morning, and occasionally I’ll pass along an article to the rest of the team that benefits us all.
That seems reasonable enough to me. And, if I were paying for W2 development labor, myself, I’d consider it a sorry state of affairs if I couldn’t leave it to the individuals to sort out how to work/warm-up/whatever effectively. Some people will do a coding exercise in the morning to get going. Some will read before and after lunch. Some take breaks through the day.
Fact of the matter is, no one is going to concentrate on extremely intense problem-solving activities for 10 4-hour blocks per week, week in and week out.
I personally think you’re certain to be a much, much more effective developer in the remaining 7 1/2 hours for your effort, more than enough to offset the 1/2 you spent researching.
I’m going to copy-paste stuff from Chapter 1 of “The Clean Coder” (Uncle Bob) here. I’m not sure if I totally agree, but that’s his view about it, anyway: “Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer. Some employers are willing to buy you books and send you to training classes and conferences. That’s… Read more »
Definitely not a mystery which camp Bob falls into. I’ve read the book and was thinking about it a bit as I wrote this. I think his perspective is entirely realistic (and nearly identical to mine). It’s nice when I can find situations that I get paid to learn, but I view the fate of my career and my wallet as entirely my own responsibility. Forget any sense of entitlement, either — I just wouldn’t trust anyone else with something as important to me (and, really, only me) as my skillset. Not sure about his last paragraph, though. I work… Read more »
I believe the justification for his posture is two-fold: if you are a “true craftsman”, that means you love what you like, so that 20 extra hours would be “almost” like a hobby (well, in principle). Also, this super-discipline of accepting the responsibility on self-education comes with the incredible benefits of “Saying No Professionally” that he beautifully and correctly explains elsewhere in the book. That saying Yes/No thing was the most enlightening part for me, with immediate positive impact in my employment relations.
For what it’s worth, that book was one of the most influential on me that I’ve read in my career, so it’s hard for me to find much fault in it. This is doubly true for me, personally, since I am one of those who loves the tech and does it for hobby and for pay. I suppose I’m just trying to empathize with as wide a swath of folks as possible, and I do consider it quite possible to be a competent, responsible developer that doesn’t do it for the love of the game.
Adding to it: I see a certain problem and an attitude that some of such seem to espouse – blame someone else for my condition. We have a choice always. Waiting until the employer does something isn’t quite wise. End of the day you are losing your time – your career. Not the employer.
I fail to see the problem with being the VB6 guy. You’re helping your company. And you aren’t becoming an beginner of any form, you are the VB6 guru in your company. Losing touch with let’s say Python? So what? How’s that a problem in a position where it isn’t important anyway?
That perspective of being a VB6 guru (also like being a Mainframes guru) is a pretty interesting take as long as you are in fully secure job and there are opportunities elsewhere that can appreciate you and take you in for being a VB6 guru. But in many other cases where you ought to be learning and keeping yourself up-to-date. This applies to most professional careers (engineers, doctors or pharmacists) – lest you do out of date and get into issues in your career in the future. On the other hand- “People without a vision perish” – a proverb by… Read more »
Well, for the purposes of the post, the problem was part of the premise: the person asking the question viewed the position as a problem. (And the part about “expert beginner” was a reference to a term specific to a series of posts on this blog from prior years) More broadly speaking, I don’t think it’s a problem, per se, if the person in question is content. But I would personally be worried, in that position, about putting all of my eggs in one basket. I’m a consultant in business for myself, and there’s a term used to describe this… Read more »
Hi Erik, I haven’t seen such a well written article and it was so in time for me. Have been thinking of this for quite some time. Many do struggle with this issue – your take seems very practical and wise to me. God bless you.
Thanks! I’m glad you found the post beneficial.