What makes a senior developer?
The soft and hard skills that make a great senior developer
Introduction
The age old question of what makes someone a senior developer. There's always been a lot of talk about what's the difference junior, mid-level, and senior developer with many different perspectives. Today I'll go through what I've seen in my experience as the key pieces to becoming a senior developer.
What it (typically) is
Before I start, as a younger senior developer, I thought it would be good to give my perspective on this question generated from my observations. It's something I continuously ponder and always love to hear different opinions on this so feel free to drop a comment with any differing opinions!
Think about end users
While junior developers are concerned about a programming task and mid-level developers are working on a new feature / project, senior developers are typically thinking about how this connects to the business.
While it's nice to have the coolest tech and fastest response times, it only matters if you're meeting a user's demand. This can mean not worrying about premature optimizations, refactoring, or unnecessary scaling issues. Senior developers can take feedback or a set of requirements, design the necessary system, and build it. They understand the entire software life-cycle and are always tinkering on the most efficient way to ship things.
Understand the system
To think about end users properly, a senior developer must understand the whole system. This differs depending on what they're in-charge of (frontend, backend, or full stack). For a backend, this would mean knowing how the APIs, database, and micro-services interact and the reason for using each. Additionally, as new asks come in, knowing the system allows you to know the best way to build an efficient solution.
Think about maintainability
A pitfall I've seen time and time again is to use a new shiny or "easy-to-use" technology only to find out it's horrible to maintain. While junior developers worry about getting their code to work, senior developers are thinking how any new functionality or project will affect them in the future. This can be anything from use of one-off scripts to generate crucial information (and someone always having to run it) to a technology that doesn't scale well with user growth. Having this foresight will save everyone headaches and typically allow products to scale efficiently on a relatively small team / budget.
Think about code quality
While I may be bias as I love some readable code, I do think code quality is crucial to think about when building maintainable systems (a core responsibility of a senior developer). For code quality I think there's two parts to it, creating the right standards for your projects (unit testing, linting, and formatting) and having these standards checked automatically before new code enters productions.
This piece can also tie into teaching / mentoring as you'll force your junior and mid-level developers to abide by a higher standard and become better developers themselves!
Understand the pros and cons of different technologies
All technologies have their pros and cons so being mindful of these will allow you to choose the right tool for the job. Being a senior developer means you're comfortable with different technologies and therefore different tech stacks. Knowing which type of database to use or what infrastructure to use for your API, can greatly affect how much your project will cost and how performant it will be as it scales.
A great example of this is the difference between when to use an RDBMS database like Postgres compared to a NoSQL database like Google's Firebase. While a lot of people are attracted to Firebase for it's minimal setup and easy operations, it lacks relation as well as many aggregation queries. If the application is relational in nature, there will be a lot of make-shift summary queries and slow "joins" as the database scales. Seeing this from the beginning will mitigate a lot of future headaches for the whole team.
Teach and Mentor
One of the last main pieces is being a person that your teammates look to for advice. By having a wide range of experience, you should be able to guide them whether it's career concerns or a tech problem. Additionally, as you teach you'll also cement your understand of different subjects better and grow as a developer yourself!
Favor boring tech in production
Before this sounds like I'm in favor of Java and using raw HTML, let me explain. I'm not 100% sold on the ideas explained in the famous boringtechnolgy.club BUT I think it's important to use mature and battle-tested technology for most applications. While it might be fun to build side projects with Remix or vlang, senior developers worry about what happens when things break. With these newer technologies, there are more unknown unknowns which means more chances of this bleeding edge tech causing business problems when your application crashes and no one understands the error.
Play with new tech
While boring tech should be used for standard features / issues in production, playing with new tech is vital to continuing to grow in a senior position. Newer projects typically point at what is wrong with existing technologies so it's typically one of the best ways to learn what are the cons of your current solutions. Additionally, some new tech becomes mature tech (recently things like React, Vue, etc.) so by having your finger on the open-source pulse, you're not scrambling to catch up when a new technology becomes an industry standard.
Summary
Thanks for reading! If you think anything should be added or something is misleading let me know! If you want additional reading on this subject, I'd recommend the boringtechnolgy.club read mentioned above. It's a fantastic look at why maintainable code is important in practice and is quite entertaining.
For more information about automated code quality or readable code, check out my previous articles: