These days it seems like every business is trying to double as a software business. As a result, there is an ever-increasing demand for developers, programmers, or software engineers. The most sought after software engineer, the senior software engineer, is the hardest to come by. The relatively low supply and high demand caused a gap in the market. Top companies swallowed all the true senior engineers. Companies unable to compete increasingly had to make do with second-tier individuals, but they still called the best they had senior software engineers. This practice seems to be destroying the meaning of the title.
As a business or manager who needs to employ engineers, you have to understand what you are looking for when hiring senior software engineers. This will both help you select the correct people for the position, and help you clearly decide if you need a senior for a specific position in the first place.
As someone who works in software, or who wants to work in software, it is important to know what you should be working towards. Simply spending time in a position is not the way to become a senior, you need to actively, and consistently, work on your skills and attributes.
In the first half of the article, I will look at what makes an engineer a senior. This discussion serves to highlight what should be expected from senior engineers and serves as a goal for the second part of this article that deals with how one becomes a senior.
What Does it Mean to be a Senior Software Engineer?
At a fundamental level, the more senior an engineer, the more complex the problems they can solve and the wider the scope they are able to consider in coming up with their solution.
Four broad strokes descriptions of the levels of growth follow. At each level the concept of a problem is used, this is meant to refer to both a broken piece of code as well as functionality desired by a customer that is not currently available in the system.
In the beginning, a professional should be able to solve the problem they are faced with effectively and in the time available to solve the problem. For this solution, they look at the specific system where they need to do their work. The solution is expected to be well tested, sufficiently documented, and performant enough to meet the scale requirements agreed with the team. Most businesses seem to think this is the level of performance you can only expect from a senior when in actual fact this should be the baseline.
On the second level, the problem at hand is not only solved to the specified standard but the solution is done in such a way that future problems can be solved more easily, or future pieces of functionality can be added with less effort. The solution also takes on a form that is easy for someone other than the engineer in question to understand, extend, or debug. In terms of context and scope, the team, current and future are kept in mind, as well as the complete system being worked on.
Moving beyond the second level into the third the scope becomes the whole group of engineers, where the level three engineer solves problems in a way that enables the rest of the organization to solve their problems better. This sometimes entails developing tools, libraries, or workflows that make all of the engineers working in the business better. The individual at this level keeps the goals of the engineering part of the business in mind at all times, and make sure that whatever they do serves these goals. In terms of complexity, creating artifacts that not only solves the current problem but can be reused so similar problems are also solved.
On the highest level, you want people who are able to serve the business needs of the organization. These individuals still solve practical problems, and they still write code, but at this level, they deal with issues that impact the business as a whole, on the level of the business as a whole. This includes finding more cost-effective solutions or preempting customer need. They look after the future of the business and the culture of the company. They function comfortably across different parts of the system, and empower parts of the business. This ranges from the ability to improve the accuracy and quality of the product and development process to simplifying or automating business processes without the request originating from the individuals who are served. People at this level should pull the whole organization into a more proactive mode.
Beyond the Conceptual Level, Senior Engineers have these Attributes and Skills
If an engineer is going to function at level three and four in the previous section, they have to be masters of the tools used by the engineering group. They also need to be well versed in both the domain in which the business operates and the context of the business in the said domain.
At this level, professionalism is a core characteristic. Engineers should not require special handlers to get them to do the work that needs to be done, quite the opposite. They are the ones interacting with both the product and ultimate customers and tease out the work that should be done. Finally, they proactively set about doing this work, often without any substantial impact on project timelines, because they are able to identify and use leverage points in work already done to add disproportionate amounts of value. Where their work would have a major impact, both the impact and benefits of the work are communicated clearly to the relevant parties. Only upon consensus do they proceed.
By the second level engineers will have developed a keen sense of taste in terms of design, architecture, and structure of solutions and code. For engineers on levels beyond that, the refinement of these tastes never ceases. As they become ever more proficient, their skills match their taste more closely. The ultimate manifestation of this balance between skill and taste is the ability to move from a poorly designed system to an envisioned alternative without having to throw out all the bad code and starting from scratch.
The ability to work with people of all skill levels and technical proficiency, teaching and challenging each individual at an appropriate level, together with the ability to communicate in both clear technical and layman’s terms are the final set of skills that an engineer needs to master to fully move beyond level three.
There is one thing that is really hard, if not impossible, for people to train. This is the pure joy that some get from the act of writing code, and solving hard problems. Without this deep passion, an individual will rarely be able to put in the extra time needed to grow an intuitive sense of quality and understanding that is needed to function at level four.
If your interest is limited to what senior software engineers are like, and what you could expect from such an individual, the following section might not be of interest to you. If, however, you read this section and are now left wondering how do you get to level three or four, read on.
How do you Become a Senior Software Engineer?
A master of any craft needs to master the tools they choose to use. This is no different for the master software engineer. Before you can truly move beyond the very first level on your road to becoming a level four engineer, you need to pick a set of tools and work hard to master them. This includes the set of languages you will choose to use on a regular basis, the editor and debugging tools you will use to create and understand programs, the operating system(s) and platform(s) your code will function on, and the version control system that will be used during development. There are a number of guides and lessons that will take you from zero to comfortable in programming, but that seems to be where it ends. The details of progress in terms of the basic tool usage are beyond the scope of this article, but I suggest you read Peter Norvig’s thoughts on the progression here [https://norvig.com/21-days.html]
It might seem odd that you need to learn your tools and or programming language so deeply that you have no more need to lookup implementation details, surely that is why we have searchable interfaces, and more tutorials than developers. Why in this world of instant access to information do you need to memorise incantations? The simple answer is flow. When you need to stop writing code to look up that small implementation detail, you rip your focus away from the expression of a solution to the diffused seeking for a trivial answer. It takes a lot of time to get into flow and thus the price you pay for losing focus is not a trivial matter. The better you are at getting into flow, and remaining focused, the clearer you will be able to express a solution, and the better your code will be.
Since you need to look beyond the context of the specific system or problem you are working on, you need to train yourself to think about the bigger picture. Early on it is helpful to ask yourself constantly how this change or that addition will simplify or complicate the future, how can it go wrong or be abused, and how will this increase the chances of user error.
On the highest level, you want to be a tool maker. Tools that enable yourself and others to do better work with less effort. Open source projects are a good way to get exposed to the mindset of tool makers since these projects are often used by many people in vastly different contexts. Expose yourself to these mindsets, integrate what they do that makes them effective, and note where things go wrong or cause frustration. Also test your ideas with these people, since they will often happily show you flaws in your thinking.
Start and maintain your own side projects. Try out new technologies or ideas in your free time in a real-world pet project. If you are trying out a new language or framework, you will learn the most from trying to build your project in the spirit of the language or framework. See how these foreign ideas can work in your regular context, and if it can’t, why not? You want to seek out opportunities to sharpen your mind, to clarify your ideas, and improve your taste.
Help junior developers get up to speed and productive as soon as possible, think about the things they need to. Learn to begin adding value to the team, and how they should progress from there. Then, structure and sequence tasks for them to help them level up a lot faster than they would have done otherwise. Also, discuss architecture style and scaling decisions and trade offs with these same junior team members, question them and guide them to reaching valid conclusions on their own. Your goal is to teach them to think like architects and senior engineers long before they are in the role themselves.
Write down how a piece of legacy code you have to work on should work, and then define all the small steps you need to take the code from where it is to where you see it going. Now find ways to balance the need for new features and functionality with these smalls steps, constantly adding and delivering business value while taking the whole system forward. To leave the code you touch better, it is important to change with an ultimate vision in mind.
Write documentation for other developers on your team, put the things you know, or think you know in writing, this forces you to really pin down the scope and depth of your understanding. The try and teach these thoughts in tutorials or meetups, this will force you to dig deeper.
Level four software engineering is a journey, a joyful and exciting adventure, not a destination. As long as you are on the journey you will remain a level four engineer, the moment you think that you have arrived, you are no longer a level four engineer. That is what makes it hard.
Is there anything I left out? I would love to hear your thoughts on what makes a senior software engineer, and how to walk the path to becoming one.