As being responsible for quite a few developers and teams at my current role and in the past, juniors often came up with a question similar to this one: “What do I need to be a senior developer?”. For most of the graduates from school or university, this is a purely technical question. They expect an answer like “learn Spring 5.1.9 and React” or learn about microservice architecture and K8S. Getting to know the frameworks, learn how to code – this is what you learn during your nightly coding session, at university or your udemy course – this is where our passion is. It’s necessary, but not sufficient. This blog post focuses more on the soft skill part because this is what separates good from excellent developers as developing software is a team effort and therefore, soft skills matter. If you want to read more about the “hard facts” I can recommend this table: http://sijinjoseph.com/programmer-competency-matrix/ 

Here at viesure, these are the skills we expect from everyone considering themself as a senior engineer.

Giving and taking feedback

For junior developers, usually, it is pretty easy to accept feedback from others. They do not have that much knowledge and experience and therefore, happily accept feedback given by more seniors as they think they are more skilled than they are. As time is passing by, accepting others opinions and solutions to problems seems to become more and more difficult as we consider ourself as experts and “it has always worked this way”, and we start to ask if the other person is even qualified to give feedback. Real senior developers know that they can learn something from everyone – even or especially from juniors because they have a different view on the same topic or ask challenging questions. Senior people also do not force their opinion on others but know that getting the support for a solution is as important as the technical quality of the solution itself. Therefore translating their knowledge and their experience into a language others can understand is an important skill. Senior developers also do understand that there is not only a single solution to a problem and that they can come to a better conclusion during the feedback process, combining the knowledge of many others and the person receiving the feedback. Giving good feedback also includes the understanding of different contexts of the involved people. Therefore a solution in one context may not be the right one in another, and as we all have different knowledge and background, that shapes our context. Ask for advice – even if you are sure that your solution is the best. Challenge your solution! Even if you stick with or solution, it makes it more thought trough.

Not being driven by feelings – be fact-based

We, as engineers, are passionate about our tools and frameworks. We love what we do and how we do it and its art, not engineering. From time to time, developers came to me, very excited, to convince me to switch some tools, for example, lets change build server because this other build server is that awesome. The reasons are different and mostly a combination of missing features: “the current tool is slower or has some lousy user interface, …”. The main difference between junior and senior people came when I asked them to provide facts to justify the switch. Senior people can give figures and numbers about what the meant to be slow and a list of comparison between the features combined with possible workarounds using the current tool. They manage to get their emotions out of the conversation and focus on a fact-based discussion. This approach is essential as if you don’t follow this approach you will be switching from one tool to the next and so forth; as there is no rational reason to keep one or go for the next. No matter what you do, as a developer – its engineering and not art. It’s about facts and not emotions.

Be a senior team member

In former times, hacking/developing was mostly a lonely task sitting in front of your computer and getting some code done. Times have shifted: software or products are not built by one person anymore – its a team effort. Therefore hacking code is just one necessary qualification. Being a valuable team member goes far beyond that. For example: Share your knowledge with others and improve your skills to transfer knowledge. It’s not about how good you are – it’s about how good the team performs. Train your skills in conflict management – teams sometimes tend to talk themselves into a bad mood even if there is no apparent reason. You can be the person recognizing that behaviour and stop it. Get better in challenging decisions. It’s not your task to make the decision process difficult or even prevent them from happening, but it’s your task to ask questions nobody else has thought of and include the answers in the process.

Look beyond your area

Junior people normally optimize locally. They optimize so that they are fast and what’s best for them. This behaviour is understandable, but as more senior, you become your context of optimization should grow. Senior people start to optimize for the team or even the whole company instead of just going for their advantage, and this means sometimes getting less done for themself and do tasks that have more leverage on the overall team performance. For example, instead of implementing a feature go and prepare a talk about efficient use of shortcuts in your favourite IDE or coaching of junior developers.

On the shoulders of giants

Some developers, regardless of junior or senior, want to do everything on their own and are unable or partly unable to build upon previous work or knowledge from others. This can manifest in not accepting provided templates, code snippets or not asking for help or advise on topics others are more experts in than themselves. This behaviour is understandable: Some think of “asking for help” or “reusing others code” as being unable to solve the problem themselves and experience this fact, therefore as a form of attack on their competence. Some want to solve it from scratch on their own. A senior developer sees things differently: He/She wants to get things done and learn. If you have the chance of learning from an expert, it gets you started faster and gives you insights that may have taken you some time to figure out on your own. In the end, you are better of asking for help and advice, because it gets you faster where you want to be. To know what you don’t know and how to get help and advise is a quality an excellent senior developer must have as it helps to come to a better and faster solution to problems. In the end, this is how a developer gets measured.

There are a lot of great resources out there to get better on these topics, and it does not take much time to improve in these areas, but it takes quite a lot of effort and practice to master them:

Summary

There is even a saying showing the relationship between hard and soft skills: “Hired by skill fired by personality”. It’s a little bit tough but accurate. The more senior you become or, the more responsibility you get they more soft skills matters. It’s not only about you, writing better code or developing faster, it’s also about bringing value to the team, and this includes a wide range of different aspects mentioned above. Mastering these points separates being great from having excellence.