A while back, I wrote about the stages of your software development career where I laid out a simple way to think about the general steps that most developers will find themselves in during their careers.
The next set of articles started to dive into these stages, such as transitioning into a junior dev role...
...and looking at becoming an intermediate developer.
Before I started this series, I touched on the difference between a lead and senior developer. So far, this is my most enjoyed article on dev.to!
Now, it's time to have some more fun and take a closer look at what makes a senior developer, along with some tips for aspiring senior developers!
Who's A Senior Developer?
To recap from a past article, a senior developer is really marked as someone who:
- Is competent in the core technologies used in his/her company
- Usually has some specialization
- Has a handle on high-level architectural concerns and design
- Should have a number of years of experience (something you just need to gain through the school of hard-knocks)
- Experienced building "full" real-world solutions
- Actively mentoring and coaching other developers on their team
The last point, I would say, is the best indicator that someone is a senior developer.
If you've proven yourself trustworthy by:
- Showing you can solve tough technical problems
- Demonstrated yourself as a good communicator
- Having real-world experience that frames many of your decisions
Then, your co-workers will look to you as a leader and coach.
Becoming An Adult?
My article about becoming an intermediate developer compares the intermediate developer to someone who's entering into puberty - but for their career.
The senior developer is like someone who's grown up, become an adult, and can take care of themselves. Their life is not as erratic, spontaneous and experimental.
That's because, in many cases, they've already "been there and done that."
They've learned from their mistakes. They've had many experiments and have formed a solid foundation for their lives, as it were.
Life is not as fantastical when you become an adult. But you do understand the world much better, and you understand that there is a huge world beyond your own perspective.
Just lay that analogy on top of the software developer, and you get a sense of what a senior developer is like π.
Senior developers are more cautious, thoughtful, pragmatic, practical and simple in their approaches to solving problems.
They've learned what works, what doesn't, what might be too abstract, not practical enough, useful, effective, etc.
Seniors are confident in what they know due to their experiences. But they also have a grasp on the fact that there's so much they don't know about.
Breadth And Depth
You might have heard about the idea that a senior developer's skills ought to be "T" shaped.
This means that they have a fundamental understanding of many topics (the top horizontal part of the "T"). But there are one or more areas where they have a very in-depth knowledge and skill set.
Senior developers have wide-reaching knowledge about what tools and techniques solve specific problems.
Breadth
For example, I've never had to build a production-ready distributed microservice system. But I'm aware of what problems this architectural approach solves and I know about different ways to begin thinking about how to structure them.
I've never had to use event sourcing in a production-ready application. But I know what kinds of problems it solves.
Just a few weeks ago, I recommended to my dev team the options of using some graph database tables to solve certain performance issues. I've never built a full system with node/edge tables, but I know what problems they solve!
Again, this is a key trait of a senior developer:
Senior developers know what solutions are available to common/re-occurring programming problems.
Depth
On the vertical part of the "T", there should be some specific areas where a senior developer is very skilled and knowledgable. Many times, this expertise is directly related to a specific role they have.
There should be some specific areas where a senior developer is very skilled and knowledgable.
Either way, a senior developer is an expert in something, and continues to grow in other areas too!
This might be specific areas like system architecture, a particular programming language, a programming paradigm (OOP, functional, etc.), a certain set of technologies, security, performance, or even just having extensive knowledge of a specific industry!
P.S. This article is originally from YourDevCareer.com where you can check out more articles and resources to help accelerate your career growth!
Zen
As a junior developer, you're still learning about how to build software. Things that come to mind are:
- What patterns are available / when and how to apply them
- How to deal with business requirements that are given to you
- How to estimate your work
- How to connect various systems together
- Etc.
Senior developers have gained experience building solutions, managing complexity, dealing with confusing business requirements, applying design patterns, etc. Because they've done these things so many times, over and over, they can solve many common problems "by heart."
A senior developer can look at a problem that a junior or intermediate developer is facing, see the patterns involved in that problem, and they know - based on patterns they've become accustomed to - the general way that the solution ought to be discovered or implemented.
A senior developer uses common patterns to discover the general path to a proper solution.
If you are looking to become a senior developer, this "zen" can really only come from having real-world experiences where you've learned from failures, successes, mentors, etc.
You just need lots of practice and need to do these things so many times that they become imprinted into your brain!
And of course, how long that takes depends on the intensity, variety, etc. of the work you do during your job.
As a side note: if your job is not challenging, then chances are that you will not grow very quickly.
An Example
Using my own journey as an example, my first job was being part of a team that was building a new software system which dealt with automotive manufacturer finances in a new way for that industry.
I quickly had to deal with a very large codebase, got my hands dirty in front-end, back-end, database programming and everything in between!
After growing for a couple of years, I was asked to help build a new white-label platform for insurance companies that allowed people to apply for life insurance using the web.
Being in charge of building the entire web portion of this project really caused me to grow. I learned so much! Including what not to do π.
This project had really complex business logic (that had already been developed and was ported to this project). It was very difficult to understand and manage. This made me seek out patterns and tools around how to manage business logic in software.
I spent a lot of time (after hours too!) learning about topics like design patterns, architectural styles and domain driven design.
Once I started using these techniques, patterns and principles in my own code, other developers would come to me and start asking about them!
Because I took the time to invest in learning about these patterns and techniques, today I'm constantly helping my team with these kinds of architectural and code organization concerns.
Some Tips
What can you gain from all this? Here are some tips for becoming a senior developer that can be gathered from what we've gone over:
- Figure out what tech stack you really want to be skilled with and learn it in-depth
- Read every day! (This will help you become a better reader and just help you learn every day)
- Try to take on those really hard yet valuable projects that are offered to you
- Remember that experience comes with time - there's no other way!
- Remember the concept of the "T" shaped skills set
- Map out your skills and figure out which ones you want to really dig into and which ones you want to learn the fundamentals about
- For skills where you want to know the fundamentals, the most important thing to understand is what problem(s) does it solve?
- For skills that you want to dig into, consider mentoring or high-quality training material (think Pluralsight)
- Most fields will benefit from knowing design patterns (again, the most important thing is to know what problems each pattern solves)
- If your current job isn't challenging, consider moving on to something more challenging
You might notice a common theme among some of these: learning techniques and patterns are mostly about knowing what problems have solutions to them.
Skilled senior developers can point out specific problems, remember what techniques or patterns can solve them, and learn or re-learn how to implement those solutions on-the-fly whenever needed!
Further Resources
Here are some of my articles that could be used as starting points for digging into topics which I've found helpful in becoming a senior developer:
- 6 Ways To Implement The Strategy Pattern In C#
- Refactoring Legacy Monoliths Series: Parts 1, 2, 3, 4
- Async/Await For The Rest Of Us
- .NET Core Dependency Injection: Everything You Ought To Know
- Introducing Gate Classes
- The life-changing (and time-saving!) magic of Feature Focused code organization
- Fluent APIs Make Developers Love Using Your Libraries
- Where Do I Put My Business Rules And Validation?
Thoughts? Have More Tips?
Do you have any more tips for aspiring senior developers?
Have further questions?
Leave a comment!
Keep In Touch
Don't forget to connect with me on:
You can also find me at my web site www.jamesmichaelhickey.com.
Navigating Your Software Development Career Newsletter
An e-mail newsletter that will help you level-up in your career as a software developer! Ever wonder:
β What are the general stages of a software developer?
β How do I know which stage I'm at? How do I get to the next stage?
β What is a tech leader and how do I become one?
β Is there someone willing to walk with me and answer my questions?
Sound interesting? Join the community!
Top comments (18)
$.02 - If someone wants to be a "senior developer" they should pursue goals as described in this article and measure themselves by achievement of those goals.
Don't measure yourself or others by a job title. In many places everyone has the title of Senior Developer or higher. It means a) they've worked there for a few years or b) when they were hired they negotiated for a higher title.
It's pervasive and unlikely to change. We just need to be aware of it. It's usually harmless, but in some cases a newer developer (I never use the term "junior" because we're all adults) can have his or her growth stunted by following the examples of senior developers who stopped learning years ago right after they figured out how to throw together really bad code. They're called expert beginners. It's a lot easier to avoid becoming one if you realize that the phenomenon exists.
π― I was there and had to do exactly this - learn on my own and set my own expectations with where I wanted to go in my career.
A good rule of thumb is to look up to people who have already achieved what you want (which shouldn't be simply the title of "senior developer").
Want to be a competent senior dev? Look in the broader community for people who are considered great seniors devs.
It's true, there are SO many developers who stay with the same company doing, mostly, the same stuff and are given new titles just because they've been there for X years.
Erik Dietrich (@daedtech ) has written about this phenomenon while identifying a career-path 'black hole' of the "expert beginner": daedtech.com/how-developers-stop-l...
Sweet - thanks for the link! I read this one in a galaxy long ago but will be re-reading. Erik's stuff is gold π
Thanks for the mention!
I total agree. Great Article!
One thing I think you are missing. I'm sure you thought this was obvious but I want to point it out. A senior developer creates quality software consistently. Your not a senior developer if your code always has problems.
Depth and Breadth is key in my opinion also.
Thanks Kyle! I would agree, there should be high degree of quality software being produced. You can be senior in title, yet not in actual competency.
As others have noted, that is VERY common in our industry (and in other industries too I'm sure π)
"Their life is not as erratic, spontaneous and experimental"
Ouch :-(
π Some people seem to have issues with this statement, which is only a metaphor after-all lol.
But, it's true... if you've gained meaningful experience and have had the chance to experiment then shouldn't you have learned from those experiences?
Shouldn't you be able to approach solving problems in a less spontaneous way?
And way up the scale, shouldn't we be learning about (mental) systems that help us to manage problem-solving so we aren't just throwing random ideas at problems?
I get your point but let me say this: you develop a framework for problem solving as you advance in your career, which can sometimes constrain you. But that's why you have to keep being open to experimentation. That's how you actually grow and improve. Otherwise you can easily fall into the "use the hammer for everything" problemβ¦
Def. π― But that idea itself (let's get meta...) is part of a problem-solving framework itself π.
I agree that a very rigid way of solving problems everywhere is def. going to constrain you 100%.
But even in times of experimentation, your experience should guide you in knowing:
So even the process of experimentation itself has some over-arching framework that you implicitly and explicitly are aware of - which, in the end, should be informed and improved by your past experience.
That's a bit more philosophical than most would like π.
James, very comprehensive. What's your view on visual-based (data-modeling) programming tools? 'Low-code' as Forrester calls it.
Thanks! Visual data-modelling is fine as long as it's restricted to database models (I find). They are helpful to build out your tables, relationships, etc. fast and get a handle on the overall structure.
However, what I find is that a more "code first" approach is, in the long run, a way better and maintainable way to approach building software.
This would be more in-line with a Domain Driven approach. Your data doesn't drive your code, but your code (with very rich domain models) drives your data storage/models.
I think it was Martin Fowler who once talked about working on a project where they literally ignored the database for a project, building all the code and focusing on modelling the business domain well. For the time being, they just stored everything in memory (or perhaps just to a plain binary file...something like that).
Only at the end of the project did they "plug in" a real storage mechanism.
I think that type of approach is best. And I don't think visual modelling works that well with building out code architecture, classes, etc. (although perhaps there are some tools that DO work well? Just as long as you aren't focusing on data, but on modelling the business domain ala Domain Driven Design, etc.)
Thanks for the insight James. Forrester Research shows low-code platforms growing by 50% year on year at present. outsystems.com/ and mendix.com/ are current market leaders. Outsystems developers seem to like it a lot. Do you think that's because they're... not very good developers and use it as a crutch or perhaps it actually makes a bunch of things easier, so they can focus on the more creative / challenging parts that require new coding?
If I took Ionic Studio as an example (since I'm currently leading a project building an app using ionic) - this is great.
It's great to work with the UI and build it out fast.
That being said, (I've never used ionic studio), there's probably a lot of manual tweaking that needs to be done to the generated UI code.
Now, when we talk about non-UI stuff like making API requests, auth logic, caching mechanism, network detection, etc. I would think that's best handled best manually.
I personally see lots of value in building UIs like this, but when it comes to the code that is generated....well, I don't expect it to be that "great". And even if it is, there will still be lots of other non-UI stuff to get done.
So, can a dev team use one of these tools? Sure! But like you said, if used by entry-level devs...should we expect a performant and maintainable product in the end?
These do look like great tools for building (probably) more simple straightforward apps. And there's a place for that, sure. But the trade-off is that any complex logic that is needed by the app, or perhaps unconventional experiences probably won't fit.
Especially for mobile apps, that are usually more simplistic than, lets say, a web app, I have no real big issue in general.
But you'll still an API on the back-end to hook into to do all the "heavy lifting".
Thank you so much. So interesting!
Nice article.
Thanks!