Lots of readers wrote in with questions and comments about How many years to senior engineer?. Here's some additional thoughts.
Jake shares a great post from Charity Majors – The trap of the premature senior
If you haven't read it, Charity's argument is that real seniority comes from working on several teams, seeing lots of tools/techniques/design patterns/workflows, and proving yourself in those environments. It's easy to work your way into a "senior engineer" title on your first team, without having these necessary experiences.
PS: you can read and share this online
Funnily someone else shared this with me the weekend before I wrote mine. Wish I'd seen it years ago when I was falling into that same trap 😅
Seeing (and interviewing) others in this trap inspired the Senior Mindset Book. True fact.
Chen asks if I ever wrote about my journey to "the valley".
This is probably the most comprehensive writeup with some links to earlier writings: How I sponsored my own greencard
We also talk about it in this interview here: Swizec on DevJourney
Andy points out that I'm bad at math. You need
ceil(log2(N)) yes/no questions to prune a decision tree or reduce a search space. The best questions halve your search space.
sqrt(N), which comes from verifying prime numbers. If a number is indivisible with every prime up to its square root, it's a prime.
John and Chas point out that my proxy criteria – 3 years on a codebase, 2+ companies – loses something important. Shouldn't you look at how the person is performing?
Yes! Yes you should.
Game recognizes game, as they say. Engineers know who's getting shit done on a team. They know who's slacking, they feel who's doing magic, they can see if the code is good or bad or if you're causing headaches. This is why engineering managers should understand engineering, not just management.
If someone performs at a senior level, they should be promoted. Regardless of all other metrics.
But that's also how we get people falling into the trap of the premature senior as Charity says. Get hired straight outta school or bootcamp, work for 3 to 5 years, do good work, get promoted.
Then you change teams or companies and it all falls apart. Everything you thought was true doesn't transfer to a new environment.
You start using a new framework and all your intuitions are wrong. You use a different work process and your best habits fail you. You change architectural philosophies and everything feels weird and unnatural.
Seeing those different ways of solving similar problems is important. That's what makes you senior.
You don't need to change companies for this, changing teams in a large company should do it. Or you can wait 10 years to work through a few large refactors and hype cycles.
Finally John says: None of this is sufficient if you do no introspection.
Yes! Experience plus thinking about what you learned 💪
PS: Aaron mentions that working at a small startup forces you to learn broader skills than you'd ever need at a bigtech. Yes! But you also have fewer mentors to learn from.
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️