Senior(+) engineer. One of the most coveted titles in our field. There are endless articles on the expectations of these engineers. Naturally, these are written by other senior+ engineers. On realising this, I had a thought
What would the expectations of a senior+ engineer look like from a non-senior+ engineer?
Fitting the bill of that description, I decided, I should write about it! Turns out, they're not so different from what is already in the public domain. However, I thought I would motivate them from my perspective. I can't speak for everyone but I think the themes will be largely applicable. I hope you
find it valuable.
Know it all
I'm only trolling you 😆 There is no expectation on you to know everything. All of us are on a learning journey. If you don't know the answer to something, that's perfectly fine. Pointing me in the right direction is often good enough. The best part? I have an opportunity to teach you something. We all grow together.
An uncanny sixth sense
At the core of being a senior engineer is having good intuition. Developed through a mix of experience and the ability to critically evaluate past successes and mistakes, it's an important piece of what separates seniors from the rest. Remember that time you avoided a sub-optimal design decision because you started seeing all kinds of red flags? That's your intuition saving the day. You're able to evaluate trade-offs, have a good feel for why certain designs will/won't work given the context you're operating in, base your decisions off decent assumptions in the face of incomplete information and so on. These all help in aiding your decision making process and guide yourself and your team to make more informed decisions.
This is one trait I appreciate immensely. Anyone who knows me knows I love asking technical questions: Why do our APIs follow this specific design, why do we use microservices, why don't monorepos suit us, when should we trade off quality for speed and so on. These kind of technical questions have no definitive answer. As I've said before
The quickest way to go from junior to senior engineer is to say "it depends" when anyone asks you a technical question. You're welcome05:58 AM - 22 Feb 2021
They are all contextual. However, as someone who hasn't seen enough of this play out through my own experiences, it is great to be able to ask and get back well justified answers. I've found this to be one of the most valuable ways of learning for me. It helps me bootstrap my own intuition and opinions.
Deep thought enables great work
Keeping the tweets flowing, we have another one by yours truly
Increasingly convinced that one of the leading traits of great developers is thoughtfulness18:04 PM - 07 Dec 2020
I hold the belief that the art of writing code is more a function of design than anything else. Once you have a design, e.g an API interface, a suitable distributed algorithm, etc, the act of actually implementing it in code is often rather straightforward. Even for complex pieces of software this applies. We've gotten better at writing concurrent software because we've designed better concurrent primitives, as an example. This is to all say, at the heart of great engineering is thoughtfulness. Engineers (and teams) that spend significant portions of their time thinking through their solutions tend to produce higher quality work. This makes sense - barely ever is the first idea we have the best one. Being able to take a step back, conjure up and evaluate alternative solutions and then pick the best one given the constraints and context is such a valuable skill. All too often, we find ourselves mashing our keyboards without even thinking about the soundness of our API interfaces.
I find this trait valuable for the same reason I find the first valuable: I get to ask questions and learn from your thinking. It's always a great learning experience when something is implemented differently to the way I would have imagined it. Being able to talk through your thinking and getting justifications/opinions that challenge my own help me develop my thinking. In fact, one of the most important lessons I've learned is that there doesn't always have to be a strong justification for making a certain decision. Sometimes, "it's easy and it works" is really enough.
A human message broker
Much ink has been spilled on why it is necessary for engineers to learn to communicate effectively. At staff+ levels, this is likely to be one of the biggest expectations outside of technical skills. As technical people, this is often a really difficult skill to pick up and improve. Computers are simple. Humans, not so much. However, it cannot be underestimated how valuable a skill it is. Unfortunately, it's not as simple as putting words on paper or speaking about the matter at hand. This is what I believed initially. Over time, I've realised there's more to it: being able to build consensus on ideas/topics, being clear on outcomes and what they mean (we underestimate how often people have different ideas of the same thing), being clear on what success looks like, being able to storytell, being able to articulate the reasoning behind certain decisions and so on. These are all facets of being able to communicate effectively.
This is particularly relevant for me because I've been trying to learn how to communicate better within a technical context. I've found this to be rather challenging, however, I have grown considerably by watching how seniors (and even execs) communicate their ideas and concerns. To give a concrete example, one mistake I used to make routinely is vouching for a certain practice, for example, using type annotations in Python, in the name of "best practice". Best in class open source projects are using type annotations, we should too! This is poor communication. It doesn't even answer the first question you should ask yourself in this situation
What problem does using type annotations solve for us?
It's easy to have good ideas. It is significantly more difficult to justify them. Being able to communicate effectively is a necessary piece of being a great engineer.
May the force be with you
Part of seniority is enabling others to do their best work. People who do this are force multipliers. This is especially relevant at staff+ but even at senior. There are countless ways of doing force multiplying work: mentoring juniors/mids, bridging communication with the business and technical teams, delegating work, leading teams/projects, amplifying others work, helping team members get promoted, driving initiatives across teams, being involved in hiring. These have a large impact on your team and the organisation at large. It is often this work that moves people up into more senior positions, especially when it has organisation wide impact.
As an aside, check out the StaffEng podcast. It is one of the best places to gain insight into real-life stories of the journey to staff+ engineer
From a personal perspective, it's great having force multipliers in the team. The best part for me is actually just witnessing it. It is amazing to see senior+ engineers doing great work, caring about the org and making a positive impact. It's simply just inspiring.
Oldest comments (0)