Becoming a Senior Engineer
Becoming a Senior Engineer
Aspire to become a senior engineer? Read on for an in-depth romp through the career path.
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
When I first began programming almost 14 years ago (not counting the QBasic I first learned), it was a fun hobby, a class in my high school learning Java, which grew out of my interest in web design and computer graphics. A few years later I was in university taking a major in computer science, which transformed my hobby into the focal point of my studies, and just four years after that, in what now feels like the blink of an eye, I was doing it full time, and suddenly it was my career path. Looking back, it’s now easy to see how I was grinding the metal of my understanding in computer science into a hardened, sharpened edge, but in many moments I distinctly remember thinking, “I have no idea what I’m doing.”
I’m an avid Quora user as someone who answers a fair number of questions. Something I’ve noticed is that there are certain questions that seem to appear without fail almost every week: “What's the difference between a Junior / Intermediate / Senior developer?” “How can I know if my knowledge level makes me a junior, middle or senior level developer?” “What is the main difference with a senior and a mid-level developer?” “What's the difference between a mid-level and a senior developer?” “What is a Senior Software Engineer supposed to know?” “Software Engineering: How do I know what I don't know?” and on and on and on. This is just a small sampling of many similar questions, and they all have different answers, some far more different than others.
This week I set out to answer that question, at least in part, which is motivated by a need for standardization and is the first step in a larger project to define career development plans for my team at PCH / Media. We’ll use the following rubrics for self-assessments, to help guide engineers towards work that they’ll find fulfilling, and in evaluating potential hires. I started by putting together many of these answers and using resources like fellow Bostonian Sijin’s programmer competency matrix, which you’ll see a lot of in my own developer rubric. At Liquid in particular (and on my last team at DataXu), we are interested in people who want to excel in all parts of the stack, and as a result every item in the developer rubric is valuable to us. Check out the rubrics here:
You’ll notice immediately that I combined some things, added context and specific examples to certain categories, removed others entirely, and, I think most importantly, added categories related to soft skills and personal development. This is because being an engineer is more than writing code, putting together components, and writing documentation. It’s the process of taking something complicated and making it simple for our consumers and partners. One of the wisest, most concise pieces of advice that I have ever received was that “simple is hard,” and as a result the more complex something is the better we must be to make it easy. It’s an exercise in constant technological evolution, one in which, as we grow, we become more actively involved for our respective organizations. It’s teaching, mentoring, and encouraging more junior engineers to want to be better. It’s the stuff that applies to any career that I so often see missing in these answers. Adding the soft and hard skills together I ended up with, well, a lot of requirements; four pages, to be exact. So how does one actually go about tackling all of these subjects, whether moving from junior to mid-level or mid-level to senior?
The answer won’t surprise you: take a kernel of knowledge, something in which you have achieved mastery, and grow your knowledge around it. Once you begin to nucleate knowledge around the core of your understanding you’ll find that, much like Newton’s first law of motion, it will become a part of your process and remain so. Start with something you understand deeply and then you’ll be able to move effectively to other areas of knowledge. The same holds true for the ops side of the house, for which I have also included a rubric. But how long will it take? That depends on you. I don’t hold to the idea of ten-thousand hours, or some number of years’ experience, but rather the experiences from which an engineer has been able to learn. The trajectory of your understanding is entirely dependent on your attitude and the amount of time you will devote to improving your skills. By constantly challenging yourself to learn more and do more with that knowledge you’ll be able to tackle harder and harder problems.
Opinions expressed by DZone contributors are their own.