Becoming a Senior Engineer (Part 2)
Becoming a Senior Engineer (Part 2)
If you're trying to advance your career, this revised set of rubrics will help you determine what you should know and how to conduct yourself.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
In my previous article (Becoming a Senior Engineer, Part 1) I explored, in brief, the strategy for going from junior to mid to senior software and DevOps engineer. The conclusion? Practice, practice, and practice more. Today, I want to revisit the topic from a new perspective, which is one that is sorely overlooked throughout the growth and mentorship of engineers.
Since I wrote the article, over 20,000 people have read it (including the guest spot on the media.pch.com blog), and I’ve gotten a tremendous amount of feedback, most of which has been extremely positive! PCH Media has also adopted this strategy for career progression in other parts of the business, and it has been used by our parent organization as well! One of the biggest pieces of feedback I received was that there wasn’t enough focus on the personal. There’s one subject on the interpersonal, and a strong concentration on technical ability, but the squishy, hard-to-nail-down personal categories were missing.
As an engineer (and as an engineering manager) I like to avoid the abstract — the philosophical — when dealing with questions of ability. This is because these sorts of abstractions often favor those who have been similarly enculturated, and often disfavor those who are different from the author. More to the point, those things are not often measurable, which is antithetical to the purpose of measuring someone’s ability in order to ascertain their current skill level and identify areas of weakness in order to help them grow.
Taking all of this into account, I tried to develop a set of additional categories that encapsulate personal responsibility, maturity and self-awareness, and some hard-to-define (but technical) categories, like adaptability and agility. I recognize that these are far from perfect, and like any skills assessment, I urge you to take these with a grain of salt. These rubrics:
- Are useful in getting a ballpark estimate of an engineer’s abilities, whether they are a software engineer or DevOps engineer.
- Can be used to identify skills gaps. It is up to the engineer, as well as the mentor or manager, to find ways to fill these gaps.
- These rubrics are as much about the journey as they are the destinations.
- Are not definitive, or in any way all-encompassing.
I also want to note, after much feedback, that an engineer need not satisfy every category of a given column to be considered in that column. As an example, a senior engineer may have never worked with NoSQL because their business has never had a need for NoSQL. In other words, as with everything, context is required.
There are two categories in particular that require further explanation: “self-awareness” and “problem ownership.” These two categories were born of a need to define, in more certain terms, a developer’s emotional maturity. If you’ve worked in a technical industry then you know how often managers are willing to gloss over personality defects of engineers in favor of skill. There have been several books on the matter (check out “The Inmates are Running the Asylum” if you want a rather outdated but humorous, and sometimes poignant, look at poor software development and some of the personalities therein, circa 1997), and most of them talk about this character type as the “cowboy.” This is the haughty, self-righteous, egotistical, hacker. The guy who’s great at his job, so we ignore his personal hygiene or his emotional immaturity or his unevolved communication habits and fiery, religious-like beliefs regarding VIM or EMACS, Systemd, or OpenRC, Rails or PHP or Haskell, and so on.
I wanted to address this quite explicitly (hygiene aside) from the viewpoint of adversity and self-perception. How someone reacts to adversity, whatever form that happens to take, is a key indicator of their future success. When a developer runs into problems with their code, or a problem is highlighted in their code, how they react to this, even as a junior dev, tells me how good a developer they will inevitably be. Those who react aversely to criticism or critical feedback will never be great. Likewise, those who can’t deliver that critical feedback well will never reach their full potential. In the same vein, those who don’t take criticisms of themselves seriously, or who fail to understand themselves and their perception in the workplace, will never be able to grow, to learn, to better themselves.
Below you will find the latest version of the Software Engineering and DevOps Engineering rubrics. As always, I welcome additional feedback and hope that these serve some use to you in your life and/or business.
Opinions expressed by DZone contributors are their own.