On being a senior developer
On being a senior developer is separated into multiple parts, feel free to read the first part On being a senior developer: introduction if you haven’t read it yet.
This time I want to look at skills, knowledge and behavioral characteristics that I personally associate with senior software developers. This article is not the definitive answer for who is and who is not a senior developer. And it can’t be. It is my opinion of a large topic, and I am silly enough to provide it for you.
Let’s start with the fact that senior software engineers should know the principles of how computers and networks work. Seriously, how can developers take confidence in their code if a computer or network is just a black box to them? Knowing the fundamentals of things like CPU, disks, memory or network protocols is essential for senior-level knowledge. And this goes hand in hand with understanding what operating systems are for and how applications are run on them. For every role, the depth of knowledge might be different, but engineers should know why their laptop can execute their code and their toaster cannot.
Programming on senior level means the ability to implement and invent algorithms and ability to write good code using a particular development stack. Development stack is everything from programming languages, libraries, frameworks, version control systems, all sorts of development tools to software systems such as databases and message brokers. In other words, seniors should be able to solve difficult problems with quality code, while utilizing other software systems and tools in a smart way.
Code from senior developers will be easy to understand and elegant. The code will be efficient and optimized for the occasion. It will be reasonably secure, avoiding common security issues. Seniors will have good reasons why they wrote a code in a particular way and not another. They strive to write code that will last a long time, not code that will have to be fixed soon.
Another difference between beginners and experienced developers is in the ability to quickly dive in and work with large and unfamiliar codebases. My reasoning behind this is that if a developer has seen many different systems, he should have an easier time getting to know and work on a new one. The same happens with debugging. When debugging a hard problem, like an intermittent bug, it really helps if people have solved a lot of problems before. That’s because they will get more ideas on what could have gone wrong.
Senior developers should also have some experience in software architecture, to be able to design and build larger software systems. They should know how to separate concerns to improve stability or reduce complexity, or how components interact with each other. They can pick appropriate technologies; appropriate for the type of system or component and appropriate for the team and the company that will be working on it.
It is expected that senior staff brings new ideas, participate in technology choices, discuss bigger architectural decisions and continuously improve the development processes and tools at hand. Senior engineers should be able to lead development of a software component or write it completely themselves.
When it comes to testing, senior developers know different types of tests and when to use them. They know when to test something manually and when it pays off to automate it. Ideally, they already wrote many different tests and have some opinions on preparing test data, using mocks and organizing test suites. They should be able to prepare a reasonable test plan for a software component or feature. Experienced developers will not leave basic verification of their code to QA team, and especially not to their customers.
Seniors understand how much documentation and what type of documentation is needed for any piece of code or system. They understand the intent of the documentation, why they do it and for who. Documentation is their friend, not enemy. Dogmatic approaches like “there has to be Javadoc annotation for every method” or “code is documentation and we don’t need anything else” should be avoided.
Experienced developers can analyze business requirements from non-technical people and turn them into technical specifications and a plan that can be followed by less experienced engineers.
In software estimation, developers should understand what estimates are and how their team members or clients work with them. I believe that estimation is a skill that can and should be practiced. It should at least lead engineers to ask more questions, make better specifications and be in agreement about the work with people around. Senior developers know a range of estimation techniques and use them appropriately.
There is also other type of skills, related more to the type of application or business domain. This might include things like user experience design for GUI-heavy applications or knowledge that comes from writing application in a specific domain or some other specialized knowledge. This broader knowledge, that can even go outside of programming, or outside of the software development world, can be very helpful and for certain type of roles it might be more than appropriate to have it.
Seniors have also good overview and insight into software development as a whole. They know about things like software development processes, dependency management, release management, deployments, running applications in production, distributing applications, and many others disciplines that are essential in delivering software today.
As we saw, software development consists of broad range of activities, even if we talk only about activities concerning programmers alone. Writing code or thriving in office environment is just a small part of what we do as programmers. Some programmers feel bad when they don’t write code. They spend their days analyzing something, bug hunting or helping support with customers and cannot wait until they get to code again. Senior engineers realize that software development is not just about writing code and approach it from that perspective.
Social and organizational skills and attitudes
Senior engineers take responsibility for their personal productivity. This means that they work according to priorities and deadlines that they have agreed to. They are good about organizing their work and communicating progress. Senior developers should ask relevant questions, seek help and discuss possible solutions before investing too much time into something.
They also strive for team productivity. That means that they optimize for good team output, rather than their own only. They do things like mentoring and helping other team members, optimizing developer experience, investing time in documentation, etc. They strive to be the people that others want to work with. Good working environment is the foundation of productivity. Red flag for people who are overly negative, pushy or arrogant.
This leads us to communication that goes beyond just attitude. Good developers should write and speak clearly to avoid misunderstandings and present ideas in an organized matter. This is important for creating tickets, filing bug reports, contributing to documentation, and any interaction with people really. One way to judge senior people is to see how they argue, how they defend their ideas and persuade others. They should be able to speak up and provide their opinion but still keep their cool and be team players.
I think it is also worth to talk about engagement. It provokes a question whether developers can do senior-level work on assignments without being truly engaged? Can people produce good software if they don’t care so much about the team, company or product? Perhaps they can. For me, talking about senior-level work is talking about excellence. And excellence is hard to achieve without passion and engagement. How can we spot it? Engaged people don’t hesitate to share their opinion or volunteer to do things that they don’t have to. They help to make the whole organization or product better by doing more than their job’s responsibilities. They naturally want to over-deliver a bit and go beyond what is specified.
I think that continuous improvement needs special attention. By continuous improvement, I don’t mean reading Hacker news several times a day, or trying out a new programming language every quarter. But we should recognize that there are always things to learn and learning something new every now and then is important. It doesn’t even have to be planned. It is sometimes enough to have a state of mind that is open to learning new things. It is about not avoiding the work that would require learning, or avoiding work because “it is not their specialization”.
In hiring junior developers, many people look more for their attitude and ability to learn than their hard skills. I think that we should judge senior people on their attitude and ability to learn as well. And after all, aren’t senior people just those beginners that never gave up and never stopped learning?
Senior engineers are typically not passive developers who only learn what they are shown at work, they question their work and seek ways to improve it next time. They practice new things, take courses, do side projects, seek and share knowledge in software development communities or teach others. And since we are talking about learning, finishing university never hurt anyone… Okay okay, maybe this one hurt a little bit.
Overall I think that good senior engineers develop craving for mastery and craftsmanship. And this is their driving force to actually care about software development and doing it well.
The problem with seniority is that it is not linear. It doesn’t go from A to C to Z. There are numerous disciplines to master and people develop and progress in each individually. What I described is more like an ideal to strive for, and not only in technical mastery, but in attitude and other skills as well.
So who is a senior developer and who isn’t? In the end, every company, every team and every person will have to decide for themselves where to draw the line.
Last updated on 5.8.2018.