FWhen I started at my first programming job, I could spend most of my time in front of my laptop coding. Meetings rarely appeared on my agenda.
In fact, I had so few meetings that I was happy when I had one. It meant that we could gather in a meeting room altogether, often we had some snacks and there were - sometimes heated - discussions about our product. We set the directions for the future.
The more time passed by and the more I grew in my career, the less I could code because I was constantly invited to some meetings.
I despised this situation,
With time, I realized that it's normal.
While I believe that we are invited to way too many meetings and we should reject/delegate/ignore a big part of them, still as senior engineers and beyond, we'll have to spend a significant part of our time at meetings, calls, or we'll have to reply chat and e-mail messages.
As a senior engineer, you're not only there to code.
As a senior engineer, one of your most important tasks is to communicate.
While I was pondering over this, I also found some other developers sharing similar observations.
On the one hand, it's definitely what I've seen in other people's careers. The sad part is that management rarely explained this clearly and it lead to some frustrations. Probably also because the type of communications can also differ so much. Something that we are going to discuss further in this article.
On the other hand, I also found other bloggers mentioning the same. Take this figure from Gergely Orosz, author of The Pragmatic Engineer blog.
He visualized what I felt and knew in my bones. The more senior you grow, the less time you spend on building software.
What does a senior engineer do - apart from coding?
On the image, there are two other categories; working with other teams and other activities.
In my experience, both of those are mostly about some form of communication.
Therefore communication is almost as important for a senior engineer as building software and for a staff-level engineer clear and effective communication is the most important. Of course, the ability to write good software is still necessary, but it's not satisfactory.
Let's see now what kind of communications senior engineers have to do and why are they so important?
The different forms of communications where are going to discuss are
- Documenting
- Teaching
- Explaining
- Giving directions
- Saying no
Documenting
It's often a neglected item in development teams, but for maintainability, it is crucial to have up-to-date and detailed enough documentation.
Yes, the agile manifesto says that working software is more important than comprehensive documentation. But it doesn't mean that documentation can be completely neglected.
You don't have to document all the small decisions and keep a log of every meeting. But architectural decisions should be tracked and the code should be documented too.
The latter is a quite controversial topic and I also have my own opinion on it. I do agree with those who say that code should be preferably self-documenting with well-named entities and (unit) tests. Still, I think that some comments are useful and even needed. At the same time, code comments should never state what the code does, but they should reflect why certain decisions were being made.
As a senior or staff engineer, you must show an example in every area of your job, this too.
If you have problems with writing, practice it. Observe how e-mails, memos, minutes are written and volunteer to do the same. Or start a blog and see where it will lead you ;)
Teaching
Teaching is about effective communication.
Some would argue that it's also about motivation. It can be in some cases, but I don't want to teach and mentor people who need to be motivated. Hence I skip motivation out of this equation.
It's the responsibility of senior developers, it's our responsibility to teach the next generation of developers. Don't get me wrong, we should stay humble and also learn from others. We all have different backgrounds, different experiences, we can all learn from each other.
Yet, it's normal that seniors can and have to teach a bit more.
Many organizations make teaching part our official responsibility. Often, they assign senior(ish) developers to newcomers as buddies, tutors, or mentors.
While sometimes, it's only the naming that differs, I find that buddies and tutors are usually coming from the same team and their role is to help the newcomers' integration to the team and to provide all the necessary information so that they can perform their job well. Mentors, on the other hand, can come from other areas. They have often only a superficial understanding of what their mentee's team do and they focus more on upskilling, on helping to reach the next level than focusing on the integration to a given team.
If you have the chance to benefit from mentorship, take on it, it can easily give you the right inputs to reach your goals!
Yet, teaching can and will happen even if it's not officialized.
You will teach - hopefully, good examples - through your code reviews, you might deliver some knowledge sharing presentations, or just by chatting with one or another.
Don't think that people will seek you out only for technical topics. I'm often asked for career advice or how to deal with certain people, certain situations.
After all, it's not a surprise, as we saw, the more senior you are, the more you have to deal with non-technical problems, so others will seek your advice on those topics too.
Explaining
When you teach, you mostly educate peers being on a similar or lower level to you and with a clear reason. Others should be able to perform the same activities that you teach.
But there are situations when you'll have to share your knowledge in a different way, with a different purpose.
Sometimes, you have to share your knowledge, you have to explain certain things without the need of teaching the other person fishing. You simply have to reason why something is the good or eventually the bad solution.
You have to work with both technical and non-technical people and you have to be able to articulate your points clearly, not based on your level of knowledge, but based on the knowledge and background of your partner.
That's the most important point, you have to be able to use the level of granularity that is expected by your colleague. You have to explain in a way that is understandable by your partner and in a way that he also finds interesting enough to listen to it.
When you argue about which database technology to pick, your teammates will be highly interested in how to make a query, while your engineering manager will be interested in some technical details, for sure, your business counterpart will not be interested in those, but rather in how one or other impacts the customer and the expenses.
When you explain, think about what is important for the other party and focus on those.
Giving directions
A slightly different form of communication is giving directions. A good manager doesn't want to be the smartest person in the room, a good manager doesn't want to make the decisions based on his or her knowledge, research and hunches.
He wants to get directions, recommendations. As a senior developer, you should be able to give those directions. Either in oral or in written form. Express your main points clearly, be able to get into the details of the advantages and disadvantages and dare to tell what are the open points, things that you don't know, things that you haven't had the time yet to get into.
It is at least as important to share the unknown as the known. Maybe others know those parts, or if not, you'll know in the team what has to be researched, what has to be focused on in the next steps.
At the same time, let's not forget that we cannot know everything. We cannot master all the details, Yet, many try to paint a picture of themselves that shows a person who knows everything.
Be honest, share what you don't know and it will even increase your credibility.
Saying no
As a senior developer, sometimes you'll have to go a bit further than sharing your opinion. After all, you're the expert. If you're convinced that something would not work; if you're convinced that something is unethical; if you're convinced that your management or the business unit is taking a disastrous path, you have to stand up and say no.
No, that's not okay. No, that's going to fail. Repeat your reasons and tell them you're not willing to do that.
This courage implies a couple of things.
You can rarely play this card. If you're a person who thinks that he is always right, probably you should not play this card at all. If you're someone who is never ready for compromises, don't play this card either.
But if you're a reasonable person, remember this point.
If you're ready to say no, it also means that you should really mean it. You should be ready to stand up and leave.
If neither party can be convinced, you have two choices. You do what you were told to do but without you believing in it or you stand up and leave.
You know which one is the right choice.
If you want to be someone who can say no, you need to be good enough to always have options on your plate.
In any case, don't forget that maybe you don't agree on something and you decide to leave, but it's only business. Such conflicts should not be about personal matters therefore the consequences should not affect personal relationships either.
In theory. Still, we should keep that in mind.
Conclusion
Being a senior developer is not only about coding. Even if it hurts to accept this, the more senior you are the less your responsibility is about coding.
The further you in your career, even as an individual contributor, the more you have to communicate. Both in oral and in written form. Communication has many different forms - and I don't speak about the before mentioned output channels. Sometimes, we have to document, sometimes we have to teach others to pass on our knowledge. Other times it will be enough to share the key points but for people who have different jobs, for people who care about different aspects.
Also, the more expert you are, the more you know, the more you'll be expected to give directions and even to raise your voice and say no if necessary.
In future articles, we'll break down each form of these documentations and I'll share ideas on how to get better at each.
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let's connect on Twitter!
Top comments (0)