The Humble Senior Developer

5 key traits that make a senior developer a great asset to your organization

By Alen Kosanović, Senior Software Engineer, SEO, Tripadvisor

While conducting interviews at one of my previous jobs, I asked my manager: “How come we never get to interview Senior Developers?” He explained that we were only considering mid-level and junior engineers and interns. This surprised me since I thought senior engineers are the biggest catch in the pool of engineers. Instead, he said that senior engineers are already made, and that they can be “hard to bend” and may not adapt to another company’s work environment.

While the answer also had a financial aspect (senior engineers being more expensive), I couldn’t help but recall several instances where my team and I had to collaborate with engineers who out-seniored all of us. Many of them were, in fact, difficult to work with. For example, our team had certain practices we believed were the best but that didn’t align with the senior engineer’s experience. For the sake of this example, let’s call him Ben. We tried making our case, but Ben considered our way of doing things wrong and messy, and he just wouldn’t…bend. Eventually, we realized the path of least resistance was to adapt to his way of working.

Was my manager entirely correct? Are we, as senior engineers, really that hard to bend once we’re made?

Ben is just one of many senior engineers that I have worked with; I’ve also worked with senior engineers that were an absolute pleasure to work with. For most of them, it truly felt like they were trying to understand and help, and not to steamroll everything we were doing. Their approach reminded me of those movie scenes where a traveler arrives in a foreign land bearing gifts, a gesture of humility and respect. There is a certain kind of humbleness to it. Since I am now a senior engineer myself, I’ve started reflecting on what kind of senior engineer I want to be.

In this blog post, I’ll draw from my own personal experiences to describe 5 outstanding qualities of a good, and humble, senior engineer.

I once asked a senior engineer (let’s call him Homer) a quick question on Slack, and he suggested having a quick call. What was meant to be a brief chat, ended up being a lengthy call about a certain aspect of the new architecture. I felt slightly uncomfortable since I knew how valuable his time was. The vibe around the call was: This part of the architecture is important for you to understand because you will need it later. He wasn’t trying to instruct me on how I should do my job, but rather on what important aspects I should consider and why they matter.

I appreciated several things about this call:

• He was willing to go back to the whiteboard with me even though he probably had more important things to do.
• He wasn’t there to show off his knowledge or presentation skills; he wanted to make sure that I understood something important.
• He gave me the freedom to implement the solution that I deemed to be correct.

We should never disparage another person’s work. Even when a codebase is a non-standard mess or when another developer’s work does not meet our standards, we should approach it with professionalism and respect. Ben often criticized other people’s code, calling it a mess. At first, it seemed fun since I also had high standards and I was never on the receiving end of Ben’s comments.

As you get older however, you realize that not only is that kind of behavior arrogant, it also shows a lack of understanding. Every codebase was started with good intentions; nobody sets out to write messy code. A codebase becomes a mess due to tight deadlines, shifting team priorities, acquisitions and mergers, special requests or for a myriad of other historical reasons. Writing code is hard, maintaining code is even harder.

I am not saying you should never share your frustrations with others. Instead, I’m suggesting to be mindful of how you present yourself when doing so. Are you coming across as being arrogant, or are you handling yourself with professionalism?

Imagine you are struggling with an unintuitive in-house deployment tool. You are sharing your frustration with a senior engineer. Which one of these statements sounds more professional?

• This whole thing is a mess. Chaos. Why didn’t we just use Kubernetes? Who implemented this garbage?
• I’ve had my fair share of struggles with this tool too. It was built back in the day when Kubernetes wasn’t widely adopted.

By disparaging another person’s work, you are cultivating a culture of arrogance within the team. It suddenly becomes acceptable to trash another team’s practices just because they don’t align with your own. Trust me on this, nobody likes collaborating with a team like that. You want to be on the other side of that. You want to lead the kind of team that others speak highly of, one known for being easy to work with. That starts with showing respect for other people’s work.

I was once tasked with investigating a serious problem. When I presented the solution to the team, a mid-level engineer disagreed with my approach and proposed an entirely different solution. My cortisol levels immediately started rising, and I felt the urge to push back, thinking to myself “He doesn’t have the experience that I do!” Luckily, I caught myself in the moment, paused, and suggested that we list the pros and cons of each approach. While outlining them, I eventually calmed down and realized that my colleague had actually presented a good case. In the end, we chose his approach since it was more appropriate to the situation.

I had become used to being the most senior engineer on the team; the one with the most experience and the one people turn to for advice. I had started to favor my own opinion over those of less experienced engineers, even when my own opinion wasn’t always the best one. Having a team of developers who can challenge your decisions is a good thing; it helps both you and the team grow.

Although questioning and commenting can be a good thing, there is a fine line between trying to help make things better and trying to demonstrate how technical you are. We all know that one engineer who smothers you when asked for an opinion or a code review.

I was one of those. I remember feeling proud when I could point out something like, “This public method could have been package-protected.” It felt like I was doing my job, like I was adding value. At the time, I was a mid-level engineer, new to the company, eager to prove myself and share the best practices I’d learned.

As I grew more comfortable in my role and more confident in my skills, I started commenting less frequently on method level details, and placed more emphasis on aspects that might affect the business. ‘We might want to track the duration of this job, as it could help us troubleshoot issues later’.

One might say this is a natural progression for every engineer. And while that’s true, I’ve seen high ranking engineers trying to justify their rank by excessively commenting on low-level details. If we need to prove our value, it should be by providing the right level of support that the person or team needs.

I was in a meeting, alongside Homer, where I noticed a significant issue in the design. I raised my hand and expressed my concern. Unbeknownst to me, Homer had already spotted the issue and had a solution ready. His response really impressed me. He started by complimenting me for noticing and speaking up. He fully agreed with what I had said before outlining the solution that he had in mind.

Giving me full credit for the idea made me feel valued. Many of us would have said something like, “I was just about to say that!” as if trying to take credit for being first. It’s often better to recognize the contribution and take the opportunity to compliment someone. A genuine compliment can go a long way.

A byproduct of letting others take credit is stepping back from the more exciting parts of development, like researching new technologies or kicking off new projects, to take on the less glamorous, but still extremely important aspects of the job.

At a previous job, I was involved in an exciting new project that many of my coworkers couldn’t wait to get started on. The problem was that somebody needed to keep working on the current project.

Even though I was the more experienced and capable developer, I realized that the opportunity would mean a lot to my younger peers, and would help them to develop some of the skills that I already possessed. Because I was fully confident that my peers would do an amazing job, I stepped down to let them do the coding.

I was happy to help when needed, however by stepping back I feel like I had a greater impact on the team. My peers felt more valued, learned more, and in the end, were much more satisfied with their work.

Ultimately, being a senior engineer isn’t only about technical expertise and making technical decisions. It’s about fostering a team environment where everyone gets to contribute. It’s about knowing when to step in and when to step back. True leadership involves guiding others without micromanaging, offering support when needed, and creating an environment where people can grow and succeed. Ultimately, the journey of a senior developer is not just about mastering code but also about mastering the art of mentorship, communication, and leadership.