index.md 6.8KB
title: Senior developer slug: senior-developer date: 2016-10-17 lang: en chapo: That is the moment you realize you are more valuable than the code you produce.
Defining “senior” is an ongoing and surprisingly difficult process, but we do it because it’s business-critical for us. Without a clear definition of “senior developer”, we have no clear path for our own employees to get there. We have no concrete way to evaluate people joining the team, no way to hold ourselves accountable, and no way of improving the process.
*The Conjoined Triangles of Senior-Level Development* (cache)
There is a moment in your developer career when you wonder if you’re senior enough to depict yourself as a senior developer. This is not at all a matter of how old you are (cache), neither how much you’re being paid. This is more related to how many and diverse experiments you made, how many different peers you helped onboarding a project, how easy it becomes to transmit your knowledge, how much confidence you accumulated and how fast you can admit you’re totally wrong. Actually, this is all about the fluidity you can have with a team within an evolving complex context. That is the moment you realize you are more valuable than the code you produce.
You’re here to speed up the learning process but not too much, otherwise your fellow companions are totally missing the potential failures and are pursuing without accumulating knowledge. Going fast is useful only if everybody within the boat is aware of what has been tried before and what was wrong (and right!) for that particular journey. It can only be achieved with a ton of communication.
When you’re lucky enough to be part of a team of highly skilled developers, you know that everybody will still progress technically because it’s part of the team’s DNA. Besides some long-running trolls, you know that the hard part will not be about technical capabilities anymore, the team is confident enough on that side to learn quickly if necessary. The hard part will be to consider the team — present and future — as a whole. It requires a tremendous amount of empathy to make the right social decisions.
Senior team members should be expected to spend half their time mentoring and helping others on the team get better. Their job isn’t just to be the code hero bottleneck.
Here the important word is bottleneck and I think that better than trying to reach the senior label individually, it has to be gained as a team. It’s way more challenging to be part of something bigger than yourself. You can mesure how “senior” a team is by how good it is at reducing bottlenecks and sharing responsibilities.
Finally, it also creates social problems as well. Bugs that span multiple services and require many changes can languish as multiple teams need to coordinate and synchronize their efforts on fixing things. It can also breed a situation where people don’t feel responsible, and will push as many of the issues onto other teams as possible. When engineers work together in the same codebase, their knowledge of each other and the system itself grows in kind. They’re more willing and capable when working together to tackle problems, as opposed to being the kings and queens of isolated little fiefdoms.
Choosing carefully which trends you’re following is key. Some are particularly destructive for the social interactions. I already talked about GraphQL, I think that microservices are even worse. This is a particular case when there is so much tensions within the team that you need to separate people and their products to still be able to deliver some value. A senior developer has to be inclusive in his productions and reactions, sometimes at the expense of speed or relevance.
The last step is to write about it. This could be a blog post, a book, or a conference talk. When I write about a topic, I explore the edges of what I know, the edges outside of what I needed to initially implement the idea.
*How do I learn?* (cache)
One part of becoming a senior developer is to be able to go just a bit deeper than the average developer and be able to share it. That’s a tiny advantage that makes all the difference. Sharing can take many forms, from blogging to giving a presentation or pushing some code on a repository. The end-result is not the most important (except for ego maybe). The moment you dig into the concrete issue and spend some time on it, the process of acquiring that knowledge and being capable of transmitting it. That’s the key point.
We are knowledgeable and productive, yes, but we also understand that we may actually know fewer (useful) things than we did at a prior point in our career. A non-trivial amount of our knowledge has decayed, and we may not have had the time to accumulate enough new knowledge to compensate.
[…]
We realize that it’ll require real effort to just maintain our level proficiency - and without that effort, we could be worse at our jobs in 5 years than we are today.
The combination of our knowledge decay being extremely fast and our knowledge accumulation rate being quite slow leads to burnouts and endless questioning. Both being quite destructive on the long term. Senior developers are survivors. The ones finding a steady pace in their learning and a clear balance between theory and practice on a day-to-day basis. The ones taking the time to transmit their experience and to be kind enough (cache) to reduce the pain for newcomers. The ones avoiding depression and dead-ends like management and entrepreneurship. The ones escaping the craftsmanship and perfection rabbit holes. The ones considering themselves not senior enough to push the limits of its definitions. What is your one?