I realized recently that three years into my professional software career, I’m comfortably out of the “brand-new career” phase, and started wondering what it means to make good choices to continue growing in my career, in the ways that are important to me (in an individual contributor capacity, at least for now). At a high level, the main things I’ve been thinking about are:
- How long is too long to stay at a dev job, particularly your first?
- What does it mean to be a senior engineer? How long does it take to become one?
These are subjective questions, of course, and so, so contextual. There is no one right answer. That’s what makes them so hard to answer, even for myself. And as someone who changed careers into tech from a more “traditional” career (I was working for a school district immediately before attending Turing — talk about bureaucracy and well defined ladders and pay scales!), this stuff becomes particularly baffling.
So I asked Twitter for help, and my Twitter community came through for me.
Adrienne Domingus@a_domingus
Careers and trajectories are confusing.
Would anyone be interested in chatting with me about mine (just looking for a fresh perspective outside my head and company)
Bonus would be someone with a non-traditional background in tech, with more years experience than me (~3) 💙21:51 PM - 26 Mar 2019
1
8
I had some wonderful conversations with people I have a lot of respect for. People from various backgrounds, length of tenure in tech, and perspectives. Most of the questions I asked were specific to the questions I’m mulling over in my own career, but I think the answers may be applicable to other folks also entering a more mid-level phase of their career and wondering what that means. This is my attempt to synthesize the high-level takeaways from those conversations, in hopes that they will be useful to others as well.
Seniority depends on context
I asked my manager recently what it would take to be promoted to a senior engineer. The answer I got surprised me — that I’m performing at a senior level in many ways already, and am likely to be promoted within a year. To reiterate: I’ve been a software engineer, professionally, for three years, with about one additional year before that of learning, and writing code most days, but not working on production systems. The idea that someone can be “senior” with three or four years of experience is surprising to me.
Everyone I talked to agreed on this: no two companies define senior in the same way, and job titles are less meaningful, industry-wide, than people would like.
I don’t “feel” senior. There are probably some other things to unpack there — this is not a post about imposter syndrome. But I am a good engineer. I spend a lot of my time reviewing my teammates’ code, answering their questions, designing systems and then, sometimes, turning it over to other engineers to actually build. So, okay, maybe that means senior.
But there’s also this: I was the fourth engineer on my team. This means that newer engineers who join, even if they have more years of experience than I do, will be hard pressed to have as much context about our codebase as I do. I’m a good engineer in general, but this makes me a particularly good engineer, in my current context.
As another data point — one person I talked with mentioned this thread by Sarah Mei, about the pre-existing communication skills that bootcamp grads come into their new careers with meaning they’re able to level up as engineers more quickly. This feels true.
Yes. SF now has bootcamp grads with 5 years' experience. Many are advancing faster than CS grads, due to pre-existing communication skills. twitter.com/sehurlburt/sta…07:20 AM - 11 May 2017Stephanie Hurlburt @sehurlburtIf you learn to code later, you'll be fine. You'll bring a wealth of other experiences to the table I wrote my 1st line of code 5 years ago https://t.co/Ljm9FoCYpE
“Stay as long as you’re happy, learning and paid appropriately!”
This sounds obvious when it’s stated that way. But with so many people talking about how it’s not bad to job hop — leave a job if you’re not learning, because you’ll be able to get a higher salary elsewhere, because the culture or work environment leaves something (or a lot) to be desired, it was easy for me to fall into the trap of thinking software developers should change jobs often — that it’s the only way to get promoted or salary increases. Those perspectives are absolutely valid. For a lot of people at a lot of companies, leaving a job probably is the only, or at least the best, way to accomplish their goals. If that’s you, by all means, leaving seems like a good option.
The point here (which now feels like I shouldn’t have needed someone else to say to me, but hey, I did!), is that given I am learning, and in a healthy work environment, and am being paid well, including regular and substantial pay raises — it’s ok to stay. It won’t hurt my career. Most of the people I talked to have participated in hiring decisions in their roles, and don’t see a long tenure at a one company as a bad thing.
Someone also posed this question: “ Do you want to be more senior or do you want the learning curve of being the junior person on the team?” I do think there’s a different learning curve from being on the senior end of the spectrum, and that itself is new, but the question is a good one.
“I’m a three-years-and-out kind of guy”
This is the flip side to the perspective above, and while I heard it less often, I did hear a similar sentiment more than once. The reasoning here is that even if you’re currently learning in your current role, there’s always more to be learned working in a new codebase, with a new team, and possibly a new tech stack. The exposure to different ways of doing things, different approaches to best practices, is invaluable.
The person who said this is currently a CTO, so clearly it’s worked out in his career. However, he also acknowledged that he’s a cis, straight, white man, and in his job changes every two to three years, he’s never had to spend much mental energy wondering if he’d be more or less safe or respected at the next one, and that folks who don’t have those privileges should take this approach with a grain of salt.
Miscellaneous Nuggets
And finally, these a few other things that stuck out to me from my conversations, that didn’t fit into the general categories above:
- One person I talked to, a principal engineer with more than 15 years experience in the industry, said he has about a 75% failure rate at interviews. Your takeaway from that knowledge might be different than mine, but what I hear is: even if you’re repeatedly rejected from jobs, it doesn’t mean you’re a bad engineer, and it certainly doesn’t have anything to do with your value as a person.
- Once you start the interview process with a company, even if you don’t think you want the role, it’s your job to get that job. At that point, the ball is in your court — it’s on them to convince you. This will help you hone in on what’s important to you, learn more about how other teams operate, and if nothing else, practice interviewing.
- Communicate. This is almost always good advice, no matter what question it’s answering. Ask specific questions — what it will take to be promoted, what will be expected of you once you are. Keep asking the questions until you get specific answers.
Career decisions are very personal, and no piece of advice is equally relevant to everyone. But I so appreciate the energy and thoughtfulness of everyone who took time out of their days to have honest conversations with me and provide new perspectives on things I’d been thinking about, and hope my high-level summary here can be useful to other mid-career or career-changing developers. 💙
Top comments (0)