What does a Senior Software Engineer do?

Published April 27, 2020, 6 min read, tagged as: careermentorship

In a previous article, I talked about what I do as a Director of Engineering. After reading some of the fantastic conversation on Hacker News and Twitter as well as talking about it with some friends, one of the most comment questions I got asked was, "how did you figure it out?" The truth is I'm still figuring it out. Career development is a marathon not a sprint. One of my mentors once told me, "the only way to eat an elephant is one bite at a time." What he meant was there's a lot to learn to be an effective leader but the only way to do it is by learning from your experiences one day at a time.

This had me thinking about my own journey and what I did in previous roles. As before, I decided to mind map my accountabilities and then go in to what I did to contribute to my team for each of these. This one was difficult because titles mean different things at different organizations, so I tried to sum up what I feel are the responsibilities I would be expected to do at this level at any organization. This is definitely up for discussion.

Project

Execution

This one is the most obvious accountability. Even as a senior on my team I was expected to produce code. What wasn't so obvious was how little time I would get to focus on my own outputs compared to my previous roles. I was suddenly expected to do so much more than just code - I had to review other's code, I was mentoring and pair programming with less experienced developers and I found myself in a lot more meetings.

The biggest lesson for me to learn was time management. I started planning my day the night before so that I could hit the ground running in the morning, and psychologically this helped me combat my imposter syndrome because it made me feel more prepared for the day.

Architecture

As a senior developer I found myself not only responsible for taking a set of acceptance criteria and executing on them, but also for helping architect solutions. This could be as simple as leading grooming sessions or as complex as spending time writing comprehensive discovery and design documentation. Either way, the time spent improving the quality of life for my team increased significantly.

Expertise

As you continue to grow, the expectations put on you tend to grow too. To me expertise doesn't mean knowing the answers, instead it's more about knowing the questions to ask, or sometimes just knowing how to search for the question.

I stopped feeling stressed out about this when I started accepting that I don't know everything, and that's absolutely ok. The most important contribution to your team at this level is confidence, because it's contagious.

How did I balance my imposter syndrome with confidence? I realized that every problem has a solution. Changing my "I have no idea how we're going to do this 😨" mentality into "ok let's figure out how to do this 🤔" helped inspire trust and confidence in the people around me and that trust helped me stop fearing failure.

Ownership

Elevating myself out of my own contributions and focusing on being a good citizen to the people around me helped me start making better decisions. In programming there's endless ways to do something, but usually there's only a handful of ways to do it thats right for the situation.

One example I've seen of ownership in actions and how decisions can effect people in different ways came when a feature request was made that needed some sensitive data to be stored. A decision was made to store this data as an environment variable which from a developer perspective made sense. What was missed was the added complexity to testing in different environments, especially if the person testing doesn't have the skillset or access necessary to make the changes they need to on their own. Once this was identified, instead of passing the problem off to the QA team to solve, the developer decided to go back and re-architect the solution, understood the effects on their team mates and implemented a better solution.

Reviews

A recurring theme as a senior was how much time I would put into focusing on the outputs of the rest of the team. Whereas less experienced developers would often focus on their own feature my code reviews provided valuable insights and context into impacts on the rest of the project or team. This helped catch bugs early and were always fantastic teaching and learning opportunities.

People

Mentorship

Mentorship at this level was both implicit and explicit. Spending time with other developers was great to raise the standards of the team and to get a pulse on what they need help with. People skills, emotional IQ, and empathy are essential for ever member of a successful team, but as a senior I also had to develop the ability to read a room, learn to listen and understand priorities. I had to use my experience to identify which skills and characteristics are necessary to be successful and guide less experienced developers through how to refine these skills.

The implicit factor came in the fact that I had to always be aware that my actions are being observed by everyone around me. It's one thing to preach good behaviors, it's another to demonstrate them at every possible opportunity.

Pair Programming

Pair programming is another factor that goes hand in hand with mentorship. It's an opportunity for everyone involved to learn and contribute. The time I spent pairing with others to white board, solve or execute problems went up significantly when I took on more senior responsibilities.

Building this skill helped me a lot because it forced me to think and explain every decision I made. I went and looked up standard design patterns and best practices so that I could explain what I'm doing as concisely as possible. I knew most of the theory already, but by putting formal names and explanations to them it helped me dig deeper and understand the "why" as well as the "what" for a lot of these concepts.

Experience

I would argue that experience is the most important part of being successful as a software developer. Once you've "been there and done that", it's much easier to approach a problem objectively and take educated guesses about what will work and what won't. There's one important lesson here though. It gets really easy to start bulldozing your opinions on to others, but thats very rarely how it works. People don't like being told what to do, and they definitely don't like being surrounded by know it alls. I found that by bringing my idea to the table, supporting it with context and being willing to compromise was the best way to create a healthy team culture. Sometimes I just had to let people touch the wet paint before they figured it out themselves.

Onboarding

A good onboarding process ensures every member of your team gets it, wants it and can do it. Although theres a lot of shared responsibility, my job as a senior engineer was to make sure every developer understood the technology that fell under my domain. I had to make sure that everyone understood the tech and design choices, felt inspired and understood what they can contribute and were able to do it.

Process

Management

Developers do their best work when they’re inspired and empowered. This starts with setting up the right processes that enable them to focus on getting things done. As a senior developer I was always thinking about what the best way to do things is, and challenging us to see if there are better ways out there. It was always about finding a balance between "if it's not broken don't fix it", and not getting comfortable with where we are. Teams are dynamic. Things are always changing and processes need to keep up.

Standards setting

Becoming a senior developer is a major milestone for every developer. To make it to this level you've likely been practicing and perfecting your skills for years. But this is just another step in the journey, not the end goal. Everyone that hasn't reached this level yet is watching you and trying to figure out what makes you different from them. It's really hard, especially when you haven't been doing it for long to see past your own accountabilities so theres usually not that many points of reference. I had to learn to demonstrate competencies beyond just technical acumen and set a good example for those around me.

There's a lot of different interpretations about what makes someone a senior. For some it's all about experience, for others it's about career length. For me personally, it's about elevating yourself to think outside of your own contributions. Moving up the org chart is a chance to influence more people and that responsibility should be used to improve the overall quality of the team.

As a manager I now understand that it's not the best contributors that tend to get elevated, its the ones that help those around them to also be better contributors. By doing this I've managed to combat the effects of the Peter Principal on my team and increase the accountabilities for those that are truly able to be successful with them.

I tweet about this type of thing a lot. If you enjoyed this article, you may enjoy following me.