For me, the phrase ‘senior software developer’ has always been quite a vague term. Is it simply a developer who has more than five years of work experience? Or is it a developer who learns all day and becomes a programming wizard? I have thought about this very often since I have grown more and more into this role and into the maturity of a senior. For me, the responsibilities of senior software developers can roughly be summarized in the next few paragraphs. I will also include some book suggestions in every paragraph to give you a chance to immerse yourself deeper in the topic.

Be Responsible

One of the most overlooked requirements for a more experienced developer is being responsible for their own failures. They should avoid passing responsibility off onto other teams, the requirement engineers, or the lead developer. This ability is a key trait for self-improvement not only as a developer but also as a human being – no one likes eternal victims. I can really recommend the book Clean Coder by Robert C. Martin on this topic. It was such a good read, and the chapter on professionalism, in particular, had a major impact on me.

Know your stuff

Programming and producing hard-to-maintain and hard-to-read code simply won’t work – not if you want to develop your skills and your career. To improve, you have to dive into the ocean of available knowledge and learn lots of theoretical stuff about software engineering. The easiest way to accomplish this is by reading the classics of software development. There are a huge number of books available, but I especially appreciated reading those by Uncle Bob, Eric Evans and Steve McConnell. For an overview of relevant literature I can recommend this list from John Somnez.

The other possibility would be watching online courses on relevant topics. One thing that I don’t really like about video courses is that the course creators are very often not as interesting or as entertaining as the well-honed writing style of a good and well-established author like R. C. Martin. The other thing that I can’t stand about video courses is the longevity of the information. I always feel that information from books is much easier to remember than from a video source.

But it is not all about programming technique. Techniques from other disciplines like software testing, project management, rhetoric basics or software security are very useful for operating effectively while working on a typical software development project.

Generalize and Abstract

The most popular and obvious skill for senior developers is the ability to generalize and abstract. With this ability it is possible to abstract complex low-level information and generalize it with more generic and easy-to-use interfaces. It depends on the knowledge mentioned in the previous section of this blog post, but also needs lots of practice and experience. It is important to learn when to apply which technique to reach a point were the abstraction is effective. The number one priority for generalization is improving the maintainability and readability of the code base. Sometimes it happens that a compromise of the two is necessary. Nonetheless, it is never advisable to apply generalization without improving one of the two previously mentioned aspects first.

I can recommend information about software architecture from, for example, Clean Architecture by R. C. Martin, design patterns and their correct usage from the Gang of Four book, domain-driven design from the book by Eric Evans, clean coding guidelines from Clean Code by R. C. Martin, and also how to write side effect-free code by simply adopting the principle of using state as little as possible. (Pure functions for the win!)

Quality matters

Quality should always take priority over an earlier delivery of code. The term in the context of software development simply means that the stuff works in a stable way and as expected. To guarantee this, the software has to have well-defined requirements and a comprehensive test suite.

When there are unclear requirements, it’s important to communicate and ask for them to be refined further. Inexperienced developers very often simply ignore unclear directions in requirement documents and produce software that is basically garbage. A responsible senior developer has the final goal in mind and strives for good software that works for the user. It should definitely not be his final goal to write software that only works on a technical or an ‘as mentioned in the user story’ level. It doesn’t matter whether the garbage produced is his fault or someone else’s.

The other very important quality factor is testing. Software testing is a very big field and lots of stuff can be done wrong. First of all, as a developer it is important to unit test the produced code. But also, support for software testers is very important and a key factor in a successful delivery of features. If these two key areas aren’t respected, the solution is very often – as already mentioned – garbage, and produces more problems than a longer development time.

If managers are trying to push through unrealistic release dates, the team has to develop the necessary people skills and learn how to negotiate in the right way with the management. On this topic I can recommend the book Clean Coder from R. C. Martin again.

Be a mentor

Something that took far too long for me to grasp was embracing the duty to undertake mentoring for younger junior developers.

I think lots of developers can relate to this scenario: a junior is obviously struggling, and a more experienced developer looks at the problem, solves it, offers a few brief explanatory sentences, and continues his own work. The junior tries to absorb the information and then also continues his work. However, to fully understand the problem he has to know more about the context and gain an in-depth knowledge of the problem domain. Lots of more experienced developers are neglecting this. The result is that the juniors are basically struggling all day, inefficiently wasting a lot of time, and losing the joy of programming.

Source: Timeless meme from the internet

Some people might argue that the junior should learn this stuff at home or in his previous education. This simply isn’t true. Everyone was at one point at the beginning of their career and needed time to grow into his or her role and area of responsibility. In my opinion this was the fault of the more experienced developer: it is his duty to improve not only the code base with new features, but also to support his team and his teammates. With the above-mentioned method, the senior is simply curing symptoms and not attending to the root of the problem.

And everyone knows: fighting the symptoms will never address the root cause. The single correct move would be to introduce the junior to what happens behind the scenes. Now he or she learns the ins and outs of software development. This may mean that the senior has to leave his own task for a while and pair programs with the junior. Another possibility would be that the senior takes time to discuss some task-relevant topics for gaining a collective and coherent image about the product being created.

In this way, I personally saw real improvement not only in the productivity of my team, but also in our overall motivation and drive for working together on the collective goal.

Again, Read R. C. Martin’s book Clean Coder. It was a real inspiration for me.

Refactor

Since the publication of the book Refactoring by Martin Fowler, the process of refining software after its delivery has become more and more important. Particularly with the rise of automated unit tests, the process of refactoring fits perfectly into the software development process and enables continual improvement of the code base.

Summary

There may be other points that are relevant to the key responsibilities of a senior software developer. For me, these were the most important revelations I had over my past few years of coding experience. These boil down to the following list:

  • Learn the concepts
  • Learn to apply them
  • Respect quality
  • Be a mentor for the less experienced team members
  • Refactor where necessary and useful

And I don’t know if my subliminal message came through, but I will simply repeat it again. Clean Coder by R. C. Martin is so good, and I think every maturing software developer should read it.

I hope that you have appreciated this article and I would love to read any feedback in the comments or in e-mails from you.