It seems arbitrary the way engineers are given their titles. From the moment you start in the field you long for that glorious Senior title. Most engineers, at least those with no management or founding ambitions, view it as the pinnacle of success.
But how do you get it? If it can’t be measured, tracked, or valued concretely then we’re just making it up. I’ll concede it’s a bit ethereal but it’s not arbitrary. After 11 years in the industry, working with other engineers of all levels, I‘ll tell you what I see: Your engineering level is the delta between your knowledge and your experience.
Knowledge & Experience
Let me define these in terms local to the context. Your knowledge and your experience are opposite sides of the same coin. They are the same statement made once in a postivie and the other in a negative. Knowledge means you know how to do a thing. Experience is to know how NOT to do a thing. You can gain knowledge through a variety of educational methods, it’s information you learn. You can only gain experience by doing something wrong, by making a mistake, or by failing.
Some extraordinary people have the ability, to a higher degree than others, to learn from other people's mistakes. This skill is not common to engineers but it’s a superpower if you have it.
On your first official day working as a software engineer you have zero experience and an overflowing amount of knowledge. That knowledge may have come from university courses or — as in my case — YouTube. You are a Junior Engineer on this day because you have too much knowledge relative to your experience. That's right, I said it like it's a problem because it is.
Junior Engineers believe that they’re right. They’re wrong, they just don’t know it yet. They don’t know it because they don’t have the experience. When you have experience (again, mistakes and failures) it will hit you over the head reminding you it’s possible you could be wrong. Junior Engineers, having an abundance of knowledge and a total lacking of experience, often don’t even consider the possibility they’re way off course.
I’m not bashing my juniors out there, I was there once. I remember so clearly standing in a small meeting room, around my third year as an engineer, marker in hand, waving furiously at the whiteboard, and arguing as though my life depended on it. I was convinced, beyond reason (as I can only see now), that users MUST have the ability to choose their own username and that the system would fall apart if they were forced to use their email to log in.
Looking back now, it was so trivial…
That Senior Engineer, Dave, let me have my way and I was wrong. For our use case, there were many pitfalls with the username system. Dave saw them coming, he tried to warn me, but I wouldn’t listen. As we worked through the project Dave was kind enough to point this out to me.
Although I regret the decision, I’m thankful because it provided valuable experience. I now understand the pitfalls of a username-based account system again. I did it wrong. That’s experience.
You might notice if you're a critical thinker, that a username-based account system isn’t necessarily wrong. I know. I’m not saying I’m correct in my feelings. The value of experience doesn’t come from how it changes your opinions, it comes from how it teaches you that you could be wrong. Nobody is a senior engineer because they have all the correct opinions.
Many times over my career, when having an argument, I thought back to that whiteboard with Dave and how I believed beyond reason that I was correct. It makes me question what I currently believe and consider the possibility that I’m wrong.
Having more Experience
Nobody wants to be a mid, being lost in the void between junior and senior. It’s a second-place price reminding you you don’t have what it takes to make senior. Once you have enough experience to question your knowledge you are officially a Mid Level Engineer. This makes it a genuinely important step and stage.
You’ll know you’re there when you think you know the answer but you look up alternate solutions anyway. When you’re in an argument you won’t cling to your opinions like they provide the oxygen you require to take breath.
More Experience than Knowledge
You’re a Senior Engineer when your experience surpasses your knowledge. At this point, you’re more likely to recognize a faulty belief than not. In the job that you do, you have more lessons sourced from mistakes and failures than you do from textbooks and blog posts.
There is an important assumption I’m making here that's important to recognize. The technology industry contains near limitless information available to be learned and absorbed as knowledge. Your knowledge and experience are vertical restricted, they don’t apply to the entire industry.
I’m a fullstack web developer sort of engineer. I’m familiar with clouds, API design, frontend javascript engineering, and other stuff you’d expect from a web dev. Around these topics, I’ve built up a lot of knowledge and experience. If I decided to join an embedded programming team at SpaceX, writing the C code that's loaded into the microprocessor on a servo that controls the pitch of a rocket's arms… my wealth of experience would be worth nothing.
The point, senior engineers are senior on particular subject matters. If you’re young and wondering if you should go deep in one area or go broad in many keep this in mind. It’s possible to be a true fullstack engineer and go deep in both front and backend for example but as I can tell you, it might take up most of your twenties.
dFor the last few years, I’ve maintained that there has to be a title above Senior Engineer. It simply doesn’t make sense, based on my experience, that Senior Engineer is the ceiling for an individual contributor — or anyone else who works hands-on in the code. I’ve seen engineers who operate at a whole different level and recently I can say I’ve joined them.
I’ve always kept my hands deep in the code but over the last four years, I’ve been a tech lead (in different capacities and titles) leading senior engineers. What I’ve found is that it’s impossible to be completely right. You’re always wrong, if not now, then sometime in the future.
The problem is that businesses change, customers’ needs change, markets change, products pivot, engineering teams and their expertise change, and so on. All this means that what we build as engineers will eventually, one day, have to change.
This is another level of realization that requires a lot of experience over time to see. Choosing AWS Lambda instead of GCP Cloud Run as infrastructure won’t be the right choice if AWS goes bankrupt in ten years. There are things that are out of your control that you can’t predict.
As a final-level engineer, you identify the things you can control and predict and build your software around them. Everything else is an externality that your system should be abstracted from to allow for quick and easy change.
How do you abstract away elements as deeply connected and ingrained in your application as the underlying infrastructure of framework? That’s for another article.
Relativism: What’s the point?
A note about being wrong and right. Sometimes you’re wrong… but sometimes you’re right. Not all ideas, designs, solutions, or implementations are equal. Some solutions are better than others.
Knowledge is the gas pedal, driving you forward in an argument. You have facts, code samples, articles, best practices, and a whole chapter from a Martin Fowler book on your side. These things fuel the thought, the instinct, that you’re right. They drive the pedal down and the argument forward.
Experience is the break, a lifeline to slow and stop the argument. Memories of previous mistakes and a healthy fear that your solution won’t actually work bring clarity and make an opening for you to consider an alternate viewpoint.
If you can’t intelligently argue for both sides of an issue, you don’t understand the issue well enough to argue for either.
- GBlink’s Dad
Sometimes you’re right, and when you are, push. The team, company, and project depend on the correct decisions being made. Sometimes you’re wrong, and when you are you won’t be able to see it if all you have is knowledge driving you forward into an argument.
How do you concretely evaluate someone’s knowledge and experience? I’m not sure yet. I’m working on it. For now, I just know this is the way.
