Five Basic Skill Sets Needed to Become A Senior Software Developer

Before junior software developers can start advancing their career, there are some fundamental skills they need to have in place. This seems to be sort of magic for most, so I share here a way of thinking about developing yourself based on the expectations I have to my teams. By understanding the expectations we have to the more senior engineers in five key areas, as well as what the fundamentals are, you get a framework for how to develop your career.

Overall, most universities do a pretty good job at educating software developers and give them a good, basic skill set. But staying relevant and performing as a software developer means to continuously update your skills, in addition to growing through experience and “becoming senior”. If you search the Internet, you will find a myriad of suggestions for how to become a better developer. The problem is that the technical skill set of a good senior developer is highly contextual. On the other hand, many companies have less than helpful development frameworks that have been created to define whether you are at level 1 or 5 in the seniority pyramid, and thus what your salary level should be. Here is an example:

Works on projects and strategies of moderate to high complexity and scope
Anticipate, propose, and decide solutions through evaluation and analysis
Identify and recommend ways to improve on existing practices
Goes all the way to make sure delivered solutions are put into use

Quiz question: given your random, favourite US-based large software company, what is the seniority level described here?

Answer: If you are senior yourself and maybe have had managerial positions, you will pick up the standard keywords and you will probably be able to be approximately right (this is from a level 3 position in a six level framework). If you are a developer, not a manager, and maybe a level 2, you will probably struggle. It all looks the same.

So, for all you out there who either are level 1 engineers or don’t understand why you are not promoted to the next level, here is a primer in how I (and many other engineering leaders) think about software developer competencies and seniority.

The Five Basic Skills

First of all, there is not only one template for what a senior software developer is and isn’t. We need many different skill sets to develop good software. Important skill number one is thus managing your own development. The foundational ability here is to reflect over what you do, what you know, what you don’t know, and identify ways of doing things better every time you do something. An important part of this is to actively seek and get feedback from others. Junior developers have a tendency to try to do things on their own, afraid of showing that they don’t know. Senior developers are not afraid of asking questions, showing that they don’t know, and bringing in other people’s strengths to make the result better. Seniority comes with exposure to many different problems, their solutions, and seeing the pros and cons of each. You can get this quicker by reading a book, an article, but also by talking to colleagues, being curious about things outside your immediate project, contribute to a discussion in the team, or just invest that little bit of extra time when searching on stackoverflow to try to understand the bigger picture problem that is related to your immediate code problem.

As engineering managers, we look to senior developers to help grow other developers, both junior and senior. The important skill number two is thus growing other people. No matter how junior you are, there will always be things you have done that others have not. You can be serious about that PR review, offer suggestions or ideas in a respectful way, not by finding mistakes and pointing them out, but by using the PR as an opportunity to learn about how other people think about their code and problem solving (benefit for your own learning) and offer your own views and thoughts on what makes good code and problem solving. You can offer to be a sounding board for a peer’s approach to implementing a new feature, or you can request others to do peer programming with you. When you grow other people, you grow yourself. Understanding this early in your career is tremendously useful.

Many of the problems we ask senior engineers to take on typically don’t have one right answer, there are always trade-offs. Also, very often the right answer is not found in the technical implementation details, but in the bigger context of what we are trying to solve and when. A concrete is example can be choosing how to build an authentication system for your new mobile app. Let’s say you have identified Firebase as a very tempting service to use. Not long ago, Facebook social login was not supported by Firebase. A junior developer would jump into the implementation, present an elegant technical solution, and when done, the customer or product manager would ask “Where is the Facebook login button?” A more senior developer would tell the product manager that only Google login could be supported at this point and Facebook maybe later, and ask if this was ok. An even more senior developer would map out the pros and cons of Firebase and the other contenders, maybe reach out to identify roadmap plans, and then use the analysis to establish the set of priorities, the future priorities, and then make a technical choice based on that (a semi-senior developer would probably over-analyse though, so careful…)

Important skill number three is the ability to actively map out and understand the important factors for a technical decision, especially non-technical factors, and work with the stakeholders to suggest alternative approaches that satisfies the needs or even delivers better value. The more senior the engineer, the wider the context I expect you to consider. If you want to use Scala for your next project, I would expect a senior engineer to also bring up the question of long-term maintainability if we loose a Scala developer, cross-team collaboration, the need for code re-use across projects, and evaluate also the expected future needs for this project up against the pros and cons of Scala. Senior engineers also span the organisation and bring in non-technical people, as well as customer views. So the key here is the breadth of your experience, your ability to recognise patterns and typical outcomes, and the experience to sort out the factors that are important and avoid too much focus on details that may not have a big impact. Junior developers are known to be too focused on technical skills, like getting stuck in a certain code style or using the same programming language to solve all problems. Senior developers recognise that Javascript and Node.js might be a tremendous choice for backend services if your team primarily consists of Javascript developers and your backend requirements are very focused on the user experience needs of the application. However, if you are building database heavy large-scale APIs to support hundreds of applications and you will mostly recruit new developers, you may think differently as you will need database people, both for coding and operations, and they typically don’t code in Javascript.

Important skill number four is technical depth. A senior developer has deep knowledge in one or more technical areas and evolves this skill set to match the needs of the organisation. Here you have a tremendous number of options. If you are good at skill number one, managing your own development, you should be able to quickly move into new areas that are related to areas you already have deep knowledge in. If you love algorithms and optimisations, you can broaden your skill set from memory and CPU optimisations to databases (and different types of databases). You can be your company’s expert on C++ and stay current on all new language features, and expand your deep knowledge of languages and language design to other languages. You can go into protocol or system design and understand component-level patterns and dependency management. The options are endless, but do not fall in the trap of doing a little bit of everything for too long. Deep expertise comes as a result of countless hours of practice. As software engineers we are lucky and train a skill in many different ways, but you need to stay focused on a certain problem area for a long time to acquire the deep knowledge.

Now to something considered soft and difficult: social and people skills. Often there is a reason we are engineers. We like to focus on the things that can be improved, so we are often overly focused on the problems. We enjoy sitting in front of the computer screen for hours, so chit-chatting in the elevator may be a challenge. And solving hard technical problems means that our brains typically are very analytical, and we tend to focus on the tangible, technical problems, not emotions. But software engineers are also people, we have families and kids. We have hobbies (yeah, they tend to be flavours of what we do at work…), and the social and people aspects in the team are actually quite important to ensure that we create great software that delivers the right solutions to the right problems. Important skill number five is thus people and communication skills. Invaluable technical people are those who are capable of facilitating good team discussions and solve problems even better, who can talk to other teams and enlist their help or support, make the team have fun, or just be that person others can talk to. If you are both technical and have good people and social skills, you are so much more efficient in delivering what is ultimately the goal of every software company: deliver great products that solve problems for customers in a way they love and they want to pay for.

What Are The Level 1 Expectations?

Ok, so there is only one thing left: what do we expect of a level 1 engineer? With level 1, I mean the first couple of years out of school. You have the basic skill set, now you need to understand how to put it into practice in a team. You have completed level 1 when you are able to take most tasks from the backlog, break them down, understand the requirements and constraints, come up with an adequate solution, solicit the right input from stakeholders, including on PRs, implement it in a way that results in stable, robust, clean, and maintainable code, with tests, have done the supporting documentation tasks, considered security and operational aspects, instrumented the application properly for logging, metrics, and tracing, and brought the result into production without incidents and instability.

Basically, this is everything related to bringing a feature end to end into production. Of course, this is very dependent on the project you are working on, the toolchain, what your company values, and what the expectations are to a software developer. However, if you start looking at it, there are quite a few things to learn. You need to go from being able to use git, to actually understanding the main workflows of your team, not only the steps to do them, but when you apply each efficiently and without messing up for others. You need to understand each component of the toolchain, how to configure and adapt it where needed. Of course, you need to know the language used in the project, the code style, and understanding how to code and document in a way that allows others to fix bugs, continue your work, or re-factor later. You should also be able to do the more detailed grooming of the task, and understand the process of how to get from a one-liner to something that is ready for development. Unfortunately, many people get promoted without having this basic skill set and you can find quite senior people who have serious gaps in the basic skill set.

Different companies and managers value different things. I value developers who contribute to team productivity and who are not “hero programmers” writing code that only they can fix. Good backlog grooming, including UI/UX work like prototyping and usability testing, is key to team productivity. Also, I expect level 1 developers to understand how their code operates in production, how to ensure good security, as well as observability.

Growing Beyond Level 1

If level 1 is basically everything needed for doing a good job, how then to progress to higher seniority levels and more pay? The answer is that in most organisations seniority is related to your overall scope, reach, and impact, not the technical skill set.

Scope is the size of the tasks you are able to take on. As a level 1, I expect you to manage yourself, your task, the stakeholders of that task, and the technical deliverables. As a more senior engineer, you should be able to manage bigger projects, maybe more undefined, maybe across teams and that involve more developers, teams, and stakeholders. Scope can also be technical complexity or that the domain is highly complex or that the problem space is unknown.

Reach is how many people, functions, or priorities in the organisation your work touches. Reach can be a result of a project with a large scope, but if you have a key role on many different projects, your reach across the organisation is even bigger. You can also have a cross-cutting responsibility across multiple teams or even the whole organisation.

Impact is about how much you are able to influence the organisation that is within your reach. You can be a key contributor and have a big reach, but not be able to influence decisions much or just do things on other people’s request. Typically, your impact is related to your standing in the organisation, how you are able to communicate and network, as well as your competence and experience in the area. It is also related to have capable you are of mastering uncertainty and turning evaluations into actionable decisions, and how good you are at driving the actions into deliverables.

To sum up my recommendations to managing your career as a software developer, you should focus on five core skills: manage your own development, grow other people, actively understand and manage the context and consequences of your decisions, invest in deep technical expertise, and be good at interacting with people and communicate well. Then, choose your path to extending your scope, reach, and impact. It could be deep knowledge of an important code base to the organisation, or by honing your ability to get things done across teams. And a final word: make sure that the organisation you work for actually values what you want to do. If not, find another employer!