Recently I've taken part in some discussions about different roles in Web Development and wanted to share what being a Senior Developer means to me.
More Than Just Code
In the past, I had the opportunity help developers deal with the transition from contractor to employee. This transition often results in a perceived reduction in productivity. I say perceived for a reason. As a contractor, tickets or stories are the primary metric; sometimes the only metric. While still important as an employee, other metrics come into play. This requires a change in the way we think about the role, or we miss the value we add between the lines of code.
Starting Fresh
When you're new to a codebase – especially as a contractor – you solve this ticket. You focus on the details provided to you because you likely can't tell if something is missing. When you make a fix, it is for that exact issue or functionality. Being new can be helpful because lacking preconceptions or outdated recollections of the code can prevent bad assumptions.
As you become more familiar with the code, you start seeing repetition and patterns. You might recognize "eras" of different code and make connections. You start to see the risks of some solutions.
Experienced Thinking
As you move toward a Senior Developer role, you build on that experience. A ticket might make you ask, "This again...how do we never have this kind of problem again?" Maybe you find a solution. Maybe you reach out to a Senior, Manager, or Architect, or even the whole team for support and perspective. Even if you can't complete that solution, you usually learn something and can share it, add comments, or create a ticket for the next developer to come back to.
This thinking starts to show up even when a ticket isn't a recurring problem. Is this likely to happen again? Is it happening elsewhere? Is it like another issue? We should link those tickets and document the connection. Make sure we re-test the other issue once we fix this one.
The mindset involves asking the extra questions. Why do we need this functionality? What's the goal? If we trim down the scope of development, how do we know what is most important?
Recognizing the New Role
There are more meetings, documentation, and status reports. It's tedious at times, but these provide extra value as you build your skills. Commenting the reason for an approach or linking tickets to show how a change could impact many workflows can take a few minutes now but save immense time and stress for someone down the line. Sometimes that someone is you.
As a Senior, other developers will seek out your time for support. You might even schedule training, peer programming, or knowledge transfer sessions. Those might feel like a productivity sink at times, but a stronger team of developers means better code, fewer bugs, and improved productivity for everyone.
Design plays a role, too. Not everything is up to an Architect or Designer. Maybe there's a different data structure or interface element that makes more sense. Asking those questions might be worthwhile, even if they come well after planning and documentation. Perhaps it's nothing, but what if it changes how someone thinks about the problem and improves the design or speeds development as a result? Development can be very collaborative, and Web developers are often uniquely positioned at the convergence of many different disciplines, so we are often in a position to start the conversation.
Of course coding is still a big part of the role. But even as you eliminate distractions and focus on the code, your experience will be there. Thinking about reusability or flexibility of some helper functions. Considering the side-effects of a change.
The Approach
Becoming "Senior" isn't about writing more code or fixing bugs faster, it's about writing better code and fixing causes of bugs. It's about the approach. It doesn't always work out how we want, but we try and refine and talk about it so everyone can get better.
Your Thoughts
There are many ways to view the differing roles. Even if you disagree with my perspective, I hope it helped you think about your ideas of a Senior Developer role, and I would love to hear what it means to you.
Top comments (2)
Well said. I certainly agree with everything you said. I like that you approached "senior" not as a clear definition of checkboxes that have been checked, but simply as collection of skills that have been fine tuned over time.
There is definitely not a hard and fast definition of what it means to be a senior developer/engineer anywhere I have ever been. It's always different and subjective. Some seniors are more technical, and focus much more on the code and it's maintainability. Others are more team focussed, working more on the people who are writing the code than writing it themselves. And still others focus more on process because they've become skilled at seeing the "big picture" and connecting the dots that will make people and teams more aligned and efficient.
Very nice post! Keep up the great work, and I look forward to reading more from you in the future!
Great work here man