index.md 9.0KB
title: The role of a Senior Developer
url: http://mattbriggs.net/blog/2015/06/01/the-role-of-a-senior-developer/
hash_url: 903c160867
We work in a strange industry. There is a much higher need for developers than can be satisfied by new developers coming into the field. This is a problem that has existed for years, and it is getting worse as time goes on.
We have a serious shortage of talent to meet the demand, but our industry is really quite young . Most software projects fail. Nearly all of them come in over budget. The best guidance we have on this subject from thought leaders boils down to “These are some common ways we solve these problems, but our solutions frequently don’t work, so the only thing you can really do is try it out and see if it works for you”.
The reality we live in is that “Senior Developer” means a person who has been slinging code for more than 3 years. These people are put into leadership positions, and typically things play out as you would expect — quite badly.
This is my take on the terms we use in the industry. Really, putting people into 3 buckets is a huge over-simplification of the nuance, knowledge, and experience of progressing through this profession, but it is what it is. If we are going to classify people in this way, then we need to take time in the industry off the table. A person with 10 years experience is quite different than someone who has experienced the same year 10 times.
The stages of software developer growth
As programmers, we live in a world of complex systems and variables. It is incredibly challenging to simply execute a well defined and focused task, especially if you are not terribly experienced with the tools at your disposal, or the codebase you are working on.
This is the life of the junior developer. You are fresh out of school, and think you know everything. Suddenly, you are faced with the fact that what you learned about in school was actually quite poor preparation for the types of problems you are encountering. Things are more messy. Less theoretically pure. You are existing in a realm of compromises, and can never make assumptions about anything.
Dealing with this is really all you can focus on, and it is what you really should be trying your best to learn. Junior developers need a lot of direction, supervision, and mentoring because of this, or they can stay in this place for a very, very long time (I recently encountered a fellow who had been building software for almost a decade who I would say is still a junior). You can say that this period is really about acquisition of tactical, day to day techniques.
A junior developer is code focused, not development focused, and doesn’t understand the distinction. When a programmer talks about how they “would love coding more, if it weren’t for all the users”, I assume I am talking to a junior developer.
A good junior developer can be given a known task, and be expected to execute it quickly, and well.
An intermediate developer is one who begins to see patterns in failure (usually their own failure), and recognize that it takes a lot more than banging out focused tasks to actually build something that works, and won’t completely fall over the first time someone needs to change it. They have also gone through the unique experience of looking at something they were proud of writing a year ago, and realizing it was actually pure garbage.
An intermediate is someone who is looking for answers on how to build things The Right Way, and finding them through experimentation, literature, and discussion with other programmers. This level is really about learning the theory of building of software, rather than the theory of building code (which is learned in school).
Systems built by unsupervised intermediate developers are going to fail for completely different reasons than systems built by juniors. A junior will build a big pile of algorithms that sort of work. A good intermediate will build pages out of “Design Patterns” and “Domain Driven Design”. While those are great books for learning how to build large OO systems, direct application of this sort of theory results in over engineered systems that are flexible in ways that don’t matter, and inflexible in ones that do matter.
You can trust an intermediate to build systems that will work for far longer than a junior, but will lead to a different sort of disaster down the road. The sad fact is that the vast majority of not only senior developers, but team leaders are in fact, intermediate devs. Most do not realize this, and have the best intentions, but have simply never worked with anyone who is at a higher level.
Intermediates are quite aware of their role in their organization, and the value they bring. A good intermediate understands how using code to solve a problem is the means to an end, not the end in and of itself. However, they are still in love with ivory tower design, and are still on a quest for “The Right Way” to build software.
A good intermediate developer needs less supervision. They can be trusted to raise issues of code design, and play a valuable role in design discussions. They are also the “workhorses” of the dev team. However, further mentoring and higher level supervision is still vital.
A senior developer is intimately familiar with their own failure. They have written code both under, and over designed, and have seen both fail. They are reflective about the things that they do, evaluating their successes and failures when approaching problems with intellectual honesty. A senior developer has fallen out of love of the complexity which dominates the intermediate, and is obsessed with simplicity.
A senior developer stops classifying developers based on their knowledge, and instead understands that there is a spectrum of strengths and weaknesses. They are more intimately aware of their own strengths and weaknesses than anyone else could ever be, and strive to play to their own strengths whenever possible.
A senior developer thinks in terms of “context” when applying theory. They understand that there is no “Right Way” to build software, and that the only way to build good software is by adapting theory to fit the needs of the client, codebase, team, tools, and organization.
A senior developer understands that everything in our field involves tradeoff, and will look for what that is for design patterns, libraries, frameworks, and processes.
A senior developer thinks of more than just themselves. They are aware of how their organization and their clients work, what their values are, and what is both important and not important for success. When a ball is dropped, a senior developer will do what they can to pick it up. The phrase “this is not my job” is never, ever said in those situations.
A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.
While an intermediate will plow through days of boring work, a senior developer will take a step back and question what is breaking down to cause all that boring work to begin with. They will evaluate the cost of fixing root problems, and either fix them directly, or put things in motion so they will be fixed eventually.
A senior developer understands that you cannot do everything yourself, and that their primary role is to help their team get better, in many of the same ways they themselves strive for personal improvement.
A senior developer understands that leadership is not about power, it is about empowerment. It is not about direction, it is about serving.
If you do not have at least one senior developer in a leadership role on your team, your project is doomed to fail. A team of great intermediates will get you very far, but the days of the software you are building are numbered, and the end result is either closing shop, or costly / risky rewrites. A senior developer is the only person fully qualified to choose technology and platforms, so not having one from day one will hurt you.
This is a giant over-simplification
The reality is nobody fits into these buckets perfectly. I am just tired of the “years of experience” based classification. Years of experience tells you something, but is almost pointless information without a lot more context.
More than that, our industry values wicked smart young guys fresh out of university. Those people are valuable, and necessary, but so are people who have 15-20 years experience in the field. We need to stop hiring according to stereotypes, and start really thinking of team and organizational talent composition. If everyone on your team thinks the same, you are doing your product and your organization a disservice.