It's mid-year review season and my manager asked "Hey Swiz, what do you think how many year's it take to be a senior engineer?". You might be curious too.
Now I don't think my manager was asking for guidance, that's not my job, they were gathering opinions. Get a feel for the vibe from experienced people in the org and see how it aligns with their thoughts.
This is a common decision-making tactic. Ensures you're not a crazy person :)
Here's what we discussed:
Years is a bad metric. It can be a decent proxy, if you have no other information, but what you're looking for is some sort of wisdom. Experience.
Someone with 1 year of experience 10 times, does not a senior engineer make. And in the right environment, an engineer can suffer through 10 years of experience in 1 year.
The latter is rare, the former all too common.
We both agreed on this. But how do you measure experience? How do you know it when you see it? 🤔
I think this is tough, if not impossible.
But it shines through in how you approach problems and the questions you ask. Experienced engineers ask really weird questions that help them prune that decision tree (or solution design space) in their mind in large swathes.
They aim to ask the fewest possible questions to design the solution. Fun side note: You need
sqrt(N) yes/no questions to decide how you'll build something that initially has N possible solutions.
This process can be frustrating to everyone around you. Might even make you look stupid.
Another tell is that as you gain experience, your language shifts from abstract to concrete. You go from "Such and such design principle ..." to "This one time I tried ...".
You make decisions and suggestions based on personal hard-won experience, not lofty ideals from a book or tutorial. Pay attention next time you talk to someone and you'll notice the difference. Are they quoting books and articles or direct experience?
The best engineers (and PMs, and business leaders, and managers) support their experience with research. The Skin in The Game approach to wisdom – follow your experience, but verify and look for patterns.
Decades of experience, supported by research.— Swizec Teller writing a book on software rewrites (@Swizec) August 15, 2023
that’s the good stuff
I think the minimum to be a senior software engineer is that you have:
- worked in at least 2 companies (or vastly different teams)
- worked on 1 codebase for at least 3 years
Working in multiple companies teaches you the difference between general principles and company/team/codebase specifics.
Working on the same [production, commercial] codebase for a few years teaches you the difference between software engineering and programming – what works over time.
It is important that both of these come with real stakes. Fiddling with a side project that your livelihood does not depend on doesn't count.
Followup post with reader questions and comments 👉 More on how many years to senior
PS: yes side-projects count a little. I give them a 25% multiplication factor, 50% if there's paying customers. Having real stakes changes how you make decisions.
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 ❤️