What makes a great senior software engineer? That’s the question I always ask managers and senior engineers when I meet with them.
This post discusses the traits of the excellent engineers I have had the opportunity to work with over the years.
1. Empathy
Simple: do not be a brilliant jerk. No one enjoys working with one.
Your teammates are human and have feelings – do not hurt them. No matter how brilliant you are; if you are a jerk, people will avoid interacting with you. Eventually, you will become the ‘brilliant jerk (BJ)’, the ‘respected’ guy on the team that no one wants to work with.
This means being open to opposing ideas – seek to understand what people say and see their viewpoints. Even if you disagree, you can state your thoughts in a respectful way; there is no need to belittle or point fingers.
You do not need to ‘win’ every argument, conserve your energy and emotional strength for more important matters. The trick is to find the core set of high-impact important issues to concentrate on, these are the ones you put your foot down and fight strongly for.
2. See the end to end picture
Farmer: I see a lot of trees
Pilot: I see the Amazon
Astronaut: I see South America
Seeing the big picture is a criteria that distinguishes junior engineers from seniors. As a junior, it is easy to become immersed in implementing some small piece without seeing the big picture. A senior engineer sees how that piece fits into the system, the business need and extension areas.
See the continent, the forest and the trees!
As you go up, do not blindly start coding gung-ho; such approaches will cost you money, time and effort (fixing bugs, reverting code, redesigns). Seek first to understand the full story and see the big picture.
Discuss to get more information about usage, corner cases and expected behaviour. The outcome is better-designed software that is resilient to bugs and easy to extend.
Spend some time thinking about the trade-off between risks and benefits. For tightly-coupled code, a small refactor can trigger an avalanche of downstream changes or break some remote component. This also applies to jumping on the latest fad without fully understanding its design roots; you might not even need that hadoop system.
Senior engineers try to isolate risk and keep the system always running. It is not just about shipping features – it is about shipping features optimally.
3. Crisp Clear Communication
Have you heard of any brilliant scientist that could not communicate?
Concise clear communication is an important skill that most engineers unfortunately lack. Software engineers spend a lot of time discussing designs, explaining architectural decisions and convincing people. They have to go to meetings, attend service reviews and send emails. A lack of good communication skills makes it difficult to get ideas across.
Senior engineers tailor their communication to the target audience. They use the appropriate vocabulary and terms to get their ideas across and can express their thoughts to disparate groups. Thus, designers, program managers and their peers understand them.
The good news is that you can learn how to communicate. A heuristic follows:
- Know the desired communication outcome
- Gather your thoughts
- Create a logical sequence for articulating your thoughts
- Express your thoughts using the sequence in 3
- Know when to stop – no point trying to convince someone who has already closed off their mind
- Practice, practice, practice
Learn to get your ideas across convincingly and persuasively – it is key!
4. Sangfroid
Sangfroid: self-possession or imperturbability especially under strain
I met with a high up director when I was about to join PowerBI in 2015. He told me that great engineers have the confidence to take some risk.
Everyone likes a confident person! A confident engineer can motivate teams and colleagues toward achieving a goal. Even if they end up in unfamiliar terrain, past experiences and challenges will have equipped them with the confidence to pull through.
This year, I was working on some critical core of our SaaS offering and no matter how hard I tried some mistakes always slipped through. I was a bit demoralized after one incident and asked A, a senior engineer with nearly 20 years of experience. His advice was thus:
Humans make mistakes and that’s normal, that’s how you learn. What’s bad is making the same mistake twice and not learning from it.
That made my day and I got to realize the difference between learning and building confidence. Do not be too worried about mistakes, rather be ready and fortified to handle them when they arise. That’s sangfroid…
5. Disciplined to know and choose what matters
Time is limited but the amount of work that needs to be done is not. How do you prioritize and deliver the things with optimal impact? What matters to the business is delivering high-quality high-impact outcomes consistently over time.
Choose the tasks with disproportionate impact and do them done first. If your web service is down, what matters most is mitigating issues and getting it back up; deep fixes and reviews can come immediately afterwards. This also applies to working on features that have little business impact – really? If something doesn’t matter, is it worth it investing a lot into that?
A senior engineer approaches non-coding tasks (e.g., unit tests and documentation) with the same level of seriousness as writing code. These tasks, which are multipliers of value, are just as important (if not even more important) in the long run.
I set up a continuous delivery system via git hooks in 2013 for my team. Pushing to the ‘prod’ branch would update the Amazon Web Service VM we had running in about 2 minutes or so. The naïve me did not write a single line of documentation; I felt it was not needed for three reasons:
- I had it all in memory
- I could always Google for it
- I was the only one handling administration and automation duties
As expected, I got confused after some time trying to understand how the system was set up. That was something that documentation would have helped fix.
Some activities are value multipliers – they save you time and effort. They also make it easier to bring on new developers.
Whatever you do, choose wisely and then do it well!
Conclusion
When can you say you are senior? I will give a few heuristics:
- When you can lead a huge development project end to end and work across multiple teams to achieve your goal.
- When you can work independently
- When you are known as an expert and your views reveal deep wisdom, tact and insight.
- When you can communicate clearly and express your views
Oh, there are a few other aspects I didn’t cover such as estimation and having the right computer science basics.
Thoughts?
Related
The related posts below show the evolution of my views over the years and make for interesting reading.
CodeKraft 
3 thoughts on “What it means to be a Senior Software Engineer”