Senior Engineer or Senior Citizen? How Can Vintage Tech Workers Age Like Fine Wine?
Senior Engineer or Senior Citizen? How Can Vintage Tech Workers Age Like Fine Wine?
Experience in some careers is viewed as universally positive, but that's not necessarily the case in tech. Why is that, and what can you do about it?
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
This week, my photo theme became “animals” for absolutely no reason. But I stumbled on a few animal photos I liked, so they all got chosen. And then instead of my normal 2 photos, I put in 4 photos. Because I felt like it.
I’ve repeatedly had older tech workers ask if I could write a bit about how to navigate the challenges of being far too old to do technical things. I pointed out that everyone knows that tech workers need to get to upper management before their brains start to slow down. Preferably in their early 30’s, while they have a tiny bit of competence left.
Less tongue in cheek, I’ve worked with successful, competent, skilled tech workers in their 60’s, and similarly have worked with people who struck me as far past their prime. As a tech manager, the first is someone I wanted to lean on heavily. The second was someone I didn’t enjoy managing because everyone knows you might be sued by the old person if you decide they’re not working out.
What’s the difference between success and failure?
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Competence in your old age.
Ashley literally had a Commodore 64 sticker on one of her monitors in her office. She’d told me stories of how she was excited by the Commodore 64 launch, as it was a vast improvement in whatever platform she’d been programming before then.
By the way, how did she get an office? She was a senior engineer (both the job title, and her age), which was a level 6 position. In our organization (due to overcrowding), senior engineers didn’t get offices. They were all in cubicles. When I joined the team, I asked her how she’d gotten an office, and she just laughed. She absolutely loved bending the rules. I never did get an answer to that question.
It was a Friday afternoon, and things were in the process of exploding. I hurried over to Ashley’s office.
“Hey Ashley!” I said, jumping into her doorway. “Could you take a look at a Sev-2? It looks like we have some type of memory issue going on.”
She nodded, and swiveled in her chair to face her command station. I’d normally call an engineer’s desk a workstation, but she had 7 monitors in a massive 3D array in front of her, scrolling status updates, graphing metrics, and displaying the weather for a few foreign countries (I think she just ran out of things to do with that 7th monitor).
One of the monitors flashed, became a terminal, and she typed out a brief command. A text version of the latest emergency ticket scrolled on the screen. As a side note, this makes no sense because our ticketing system is a web system. She should have pulled up a webpage, but she apparently made some type of script to turn our ticket system into a command line tool. Of course she did.
She read briefly. “Ok, I have an idea of what’s going on.” she said. “Hold on a second.”
She typed swiftly, and two different monitors began reacting. One popped up a few graphs of what looked like memory usage across multiple hosts, and another began scrolling the results of various terminal commands, what looked like some type of memory dump, and a few log greps.
“Ah, looks like our cache got polluted.” Ashley frowned and shook her head. “I know what happened. I can fix this temporarily, and then we’ll need a few code changes. I’m just going to run a quick script to get our servers fixed.”
Matrix like bits flew across the screens. She was apparently moving binary cache files around the servers using a quick script she’d banged together in bash. The 7th monitor said that there was a thunderstorm in Hyderabad. A few minutes later, she nodded.
“Ok, fixed. Now I’m going to go chat with the team, and see if someone can get this code changed right away.”
She stood up and walked over to the other engineers on the team, to explain the situation, and what was wrong. She was quirky, but it was awesome to have someone so competent on the team. She didn’t have interest in a promotion (and at her level, it required some political steps she wasn’t interested in), but in her current role she was indispensable.
What was special about Ashley? Specifically, she had built her career and skills on lower level programming languages. She had no problem dealing with memory dumps, running shell scripts across hundreds of servers, and debugging lower level issues like memory leaks. While she could competently build Java services like the rest of the team, she had the cliché “hacker” skills down pat as well. Things some younger recent college grads tended to be less experienced with.
More generally, she never viewed a technical challenge as beyond her. When other engineers would throw up their hands at a mystery, it only made her more excited. Plus, with decades of work experience, she had a large mental toolbox for how to approach problems.
Simply old.
Daryl looked great on paper. Literal paper in this case, because the recruiter said (with a respectful shrug) that his most updated resume was only on paper. He had many years of experience on large systems, with long tenure (15+ years) at a couple of respectable companies.
As a side note, some amount of company change is usually fine, but when I see those resumes with literally 8 jobs in 6 years, it makes me nervous. Too much job hopping suggests that a candidate keeps getting fired. Fair or not, it’s certainly not a positive sign. Anyway, Daryl didn’t have those warning signs. So that was nice.
Part way into the interview, I got to my coding interview question. I explained the question, and asked Daryl to solve it. He looked uncomfortable.
“I can only code in C.” he said firmly.
“That’s fine!” I said cheerfully. “I know C. Plus, we assume, if you can solve a problem in any coding language, that you’ll figure out whatever languages we end up working with.”
Daryl unexpectedly shook his head.
“But I only code in C. Does your team use C?” he asked.
I frowned. It seemed like an odd question.
“We use many languages.” I said. “Primarily Java, but also some Python, Perl, scripting languages, and we have an older C++ application we’re looking at rewriting.”
“I don’t code in those languages. Is there a team here at Amazon which does C programming?” he asked.
“Many people have joined Amazon and didn’t know how to program in Java. While there are new concepts from C, there’s a lot of experience you can bring over and use on this team.” I said.
It was certainly concerning that he cared this much about the specific programming language our teams were using. If you’re not a programmer, you should know that programming languages are not like spoken languages. Almost all common languages have many shared concepts, commands, and ways of programming. It’s relatively easy to be “ok” at a new language within a day.
I once helped someone debug a Haskell program, not even realizing that it wasn’t a language I had used before. Most programmers end up using at least a literal dozen languages over their career. Absolutely, there are edge cases to languages / platforms that only experts learn, but there’s nothing strange about swapping languages regularly.
To top it off, Java (our primary programming language) is used by the vast majority of the industry, so being afraid to use it was a bit odd.
Daryl shook his head. “I spent over 30 years building C programming skills. I’m not going to learn something new now.”
I told him to solve the interview problem in C, and I’d talk to the recruiter immediately to see if there was a team which would fit his skills more.
He did fine, but not great on my problem. After my interview, I talked to the recruiter and quickly came up with a couple of teams at Amazon which used C (some networking teams), and would be suited for him if he did good enough on the current interview loop.
Another couple of interviewers expressed concerns that he repeatedly told them that their problems were not the types of problems he wanted to solve. We ended up not giving him an offer. No one was interested in creating a position for someone so set in their ways.
What was the issue with Daryl? He viewed learning as a one-way street towards a destination. He’d gotten good at a particular set of skills, and decided he was done. He was an expert and was determined not to go back to learning. No matter how we had prompted him, he’d only expressed interest in doing what he’d done for the last 30 years.