What‘s a Senior Developer? How do your recognize one? It’s a question done so many times that some people may find it like a meme. Some talk about years of experience, other people thinks that should know lots of technologies (no matter what). Even when there’s a lot of literature written about the subject, there’s no consensus in the community.
The “Senior Dev definition” is a problem as much as we need to label everything. We create new roles because they now have an slight difference with the classic ones. So now there aren’t web developers, there are Backend, Frontend, UX Devs, UI Engineers… The same with the junior/senior thing. But, in the end, we are all the same: developers. People with more or less experience who take bad decisions and turns code into products. That’s it.
Senior developers don’t exist, just “developers with some experience”.
So I’m not pretending to answer the question about what is a Senior Dev, not my motto, but I’m going to list a series of skills that a “developer with experience” should have.
1. Communication
An efficient communication may be the most important skill of every developer.
As a developer, you’re going to work with other people. Always. And with these other people you’ll find that you’ll have to talk. A lot. Every single day.
- Ask the customer about what problems has and how he uses your product.
- Show your code and explain it in few words to your colleagues.
- Let know your bosses some problem in the code that needs a refactoring or explain why that bug happened in production.
- Write to open source collaborators about some issue they have (and help them to fix it).
- Document every intern process that the code needs to be deployed in production.
Lots and lots of conversations are going to happen every day and you’ll need to know how to handle them to be short, clear and without ambiguity.
And not only that. Also is very important to listen, to understand your bosses, your colleagues and your customers before explaining yourself. Empathize is very important, specially if you want people using your product. You need to understand what frustrates your customer so much so you can fix it later.
How to achieve it?
Read a lot. Write a lot. Resume a lot. Prepare checklists with keywords before writing content or going to a meeting. The book “On Writing” by Stephen King it’s a good place to start.
2. Mentoring
Mentoring is the reason why you got hired or promoted on the first term.
If you want to create a great product, you’re going to need a team to build. It’s impossible any other way around. The “one-man-band” doesn’t exist in the real life and, if you want to go quicker, you’ll need more developers helping you. In a start-up ecosystem, the speed releasing new features is everything, specially if you’re in the first stages of the product. In a simple way: more features is more money.
You’ll have to sum to the equation a new variable: developers don’t born knowing, they have to be taught. Even the expert ones, everyone needs to learn more and you may have the knowledge they need. It may be ideal but, in the end, a good developer is who teaches others all he knows (and he also keep learning from them).
How to achieve it?
The only way to learn how to teach is teaching. Try to reserve an hour or two every day to help your colleagues or prepare an small course or conference every month. If your company doesn’t let you to invest that time in teach people, then they shouldn’t whine when the people gets blocked or goes away to another company.
3. Motivation
If mentoring is an investment, motivation is the tool to keep your coworkers in the company.
The first thing that’s going to motivate your coworkers is the salary and the perks that the company offers to them. That’s it. It’s kind of a taboo but we only work for money. Usually, you’re not going to have any possibility to change this stuff. But thinking that you don’t have any responsibility at all it’s a mistake.
In the end, the motivation can be affected by a lot of different things, from the work’s perks to the impostor syndrome. Some people may want to improve their career, some other may have a problem with a toxic coworker.
Having them motivated improve the quality of their work and reduce the chances of them looking for a new job. Even if you don’t want to, you belong to the problem and the solution at the same time. You’ll have to listen to them, know what are they aspirations and seek how can you help them to be happier at their work.
How to achieve it?
Create an environment of trust. Help you’re colleagues, talk to them to know their job related problems. Do monthlies 1-to-1s. Follow the rule “Praise on public, criticize on private”. Learn how to give feedback (Kiss-Kick-Kiss).
4. Technical skills
Technical knowledge is essential to do a good job.
It may be the most obvious skill but it’s always something that some people forget: your tech knowledge expires, even if you don’t want to. Every framework you use may be outdated the next year. Every library could pass away sooner than you think. It happens every time. There are abandoned libraries every day.
If you want to lead a team and even teach them you’ll need to know how they work. What tools are they using? How can you improve their speed?
There are two things you’ll have to do:
- Learn how everything in your area works, even in the lower levels (i.e. if you’re a frontend developer, you’ll need to learn how the JS engines works).
- Be updated every day: what it’s the other people using, what new technologies have appeared, etc.
How to achieve it?
Join developer communities. Subscribe to tech newsletters. Learn about the news of the libraries you’re using. Do MOOCs. Develop pet projects. Invest in yourself, spent between 10% to 20% of your work time in learning.
5. Customer focus
Seeking to solve user’s problems should be your first goal. In the end, your job depends on them.
Sometimes we forgot that we develop “solutions to real people” . That’s it. Every talk, framework, language or IDE has the final goal to make “somebody do something”. We tend to blame the user. We say: “they are using our app badly”, we cross our hands and keep going. Don’t let me start explaining how bad are these behaviors.
If the user does something wrong is usually because you didn’t do a good job earlier. If the user doesn’t understand how a system works is because you didn’t explain it well. Be part of the solution, not the problem. And, please, stop blaming the users.
How to achieve it?
Empathy. Don’t be afraid to validate your wireframes and designs with the customers or even asking them feedback. Do A/B testing. Measure what are they using. Communicate everything. Develop always with the customer in mind. Define use cases before coding.
6. QA & Code Review
Code review and QA is part of mentoring and customer focus: in the end you’re teaching and ensuring the quality of the product.
The usual mistake when starting to work for a company as a tech lead or a senior developer is believing that your main work is develop new features.
Wrong. Even when developing must be in your daily tasks (you have to avoid to get rusty), in the end you have to train a team of developers and ensure the quality of the product.
The best way? Let them develop the features (if they’re ready to do them) and keep yourself in the shadows. Don’t worry about the quality, you’ll be always there to be a safety net. Spending more time in helping and reviewing the code of your colleagues, the faster they’re going to be.
How to achieve it?
Use Git as source control and implement a system of Pull Requests. Let your colleagues to review your own code (and admit suggestions). Be humble. Learn how to give feedback.
7. Delegation
Knowing when you shouldn’t do anything it’s important: it allows you to avoid micro-management and burn out your coworkers or yourself.
When you start having some responsibilities, you also begin to try to have everything under control. You know the rule: “If you want something to be done right, you have to do it yourself”. There’s no worse quote.
Delegation is the mother of growth. Yes, with more responsibility comes more failures. And failures are necessary to learn. Your Junior developers need to learn the same way you did, and if you look back you’ll see a path with some success and a lot of mistakes. That’s what has created a great professional as you are.
You’ll have to know when somebody is prepared to get new stuff: analyze a feature, manage a project, suggest a refactoring. Delegation means also freedom, motivation and trust. They feel bigger and they work better, and you’ll be happy because your main goal is to create an awesome and solid team.
How to achieve it?
Build the trust with your team. Let them do challenging stuff, handle projects, take decisions and fail. Help them make a career plan. Listen before give your opinion (or avoid to give it anyway). Let them take decisions, even if you don’t agree.
