& Continuous Learning

Over my career as a software engineer, I've worked with numerous engineers with varying levels of experience and influence. The ones I looked up to and wanted to follow in their steps were what I like to call the Samaritan Senior Software Engineers, or Samaritans for short, who truly lived up to their titles and demonstrated not only strong technical skills but also had an attitude that made them a pleasure to work with. I took inspiration for naming those engineers from the English expression of a good Samaritan, which refers to 'someone who gives help to people who need it.'

The key attribute that made them exceptional was their willingness to help others on the team and organization for the betterment of both. Unchecked selflessness will hurt one's career and productivity. Samaritans avoid this by employing specific techniques to balance their own needs and the needs of the wider group.

In this article, I will explore some of the techniques and attributes that make these engineers unique and highly productive. I hope this gives them their props and fosters more Samaritan engineers.

Technical Forte

A senior engineer's prerequisite is to be strong technically in breadth and depth. They have broad knowledge and experience working with different technologies, frameworks, and languages relevant to their current project/company. There is a misconception that a senior engineer must be an expert in ALL of those technologies, but in reality, they focus their expertise on a subset of technologies.

That makes sense: it's impossible to be an expert in all technologies, and the law of diminishing returns applies once you get past a certain number of technologies. Senior engineers still know enough about the remaining technologies to be productive in them.

One way to remedy that is to divvy the relevant techs between engineers on the same team. For example, one senior engineer's deep expertise can be in Spring Framework, Java, Hibernate, and REST API. At the same time, another engineer focuses on IaC (infrastructure as code), AWS, CI/CD, and DevOps. The goal is for every relevant tech to have at least one expert.

Clearing the Runway

Successful software projects require a clear runway on which the development team can build and ship their code, and it's those Samaritan engineers who put the effort into clearing the runway from obstacles.

For example, while the team has a clear idea of what they will work on for the next month, the Samaritan engineer is already thinking about what comes next and working with Product Managers and Delivery Leads to get ahead of the team and gather the high-level requirements, priority, and technical considerations. They provide clarity of business challenges and empower the team to solve them (i.e., come up with architecture and implementation details) so they are not depriving the team of the joy of solutions.

When there is a dependency on an upstream team, they will coordinate that effort. When architecture and infrastructure teams need to be involved, they will reach out to get guidance or reach a consensus on critical architectural decisions.

Never Say No

Samaritan engineers are always willing to help others on the team. Yes, they already have their workload, but you know you can contact them if you run into a blocker, have a question, or just need a helping hand. Because even if they don't have a solution, they will direct you to the right person. Moreover, you know they will never tell you, "No, I can't help."

So they have this golden ratio of willingness to help and the expertise to solve any problem you throw at them.

Samaritans also go the extra mile outside their teams. They watch Slack or Microsoft Teams for others asking for help from the broader organization. When they find a question, they go through an algorithm in their head:

1. Do I know the solution to this problem? If yes, then I will post the solution and offer to pair.
2. Do I know someone who might know the solution? If so, I will mention them in the thread, and hopefully, they can assist soon.
3. If I don't know who can help, I will allow time for someone to jump in with the solution.
4. Suppose this is urgent or an emergency, and no one offered to help for an hour or so. In that case, I'm going to reach out and say, "Hey, were you able to get assistance and solve this issue? If not, maybe we can pair up and look for a solution together."

Dedicated Time for Development

But the question is how they can clear the runway, assist others, and still be productive with their workload? Well, it's by dedicating certain hours of each day for their workload where they put their computer on Focus mode (i.e., snooze alerts and notifications) for 1-3 hours to hunker down, write code, test, and deploy.

If their schedule usually gets flooded with meetings, then they will block off certain times on their calendar for heads-down development and lunch.

If someone reaches out with an issue during their "focus time," they first ask, "How urgent is this? Because I need an hour or so to finish up what I'm working on, and after that, I can help you." I've noticed that 9 out of 10 times, the answer is, "No rush, I can wait for you to free up."

So I kinda lied when I said they never say No, and in reality, they have two possible answers for you when you reach out to help: they will say either "Yes, I can help now" or "Yes, I can help in X hours."

Delegating and Offering Guidance

You will be right in guessing those Samaritan Engineers will get spread too thin and can't be everywhere. In those situations, they are willing and able to delegate specific tasks to other teammates while giving them guidance along the way.

I remember a team that had a crucial architectural decision to make involving architects and cloud engineering groups, but the senior developer was busy with other urgent matters. So the Samaritan engineer (let's call her Dina) asked for a volunteer from the team to take this on and assured that she would help along the way.

So when someone volunteered (let's call him Tim), she sat down with Tim and reviewed the problem statement, solution requirements, and technical considerations. The next step was for Tim to research a solution at his own pace and then get back to Dina.

After Tim came up with possible solutions, she helped him by proposing additional solutions and fleshing out the pros and cons of each proposed solution. She then asked him to write up the proposals.

The next step was for her to proofread the write-up, make edits, and help him practice the presentation. When the presentation day came, she was in attendance and let Tim present. She jumped in when an architect asked tough questions or needed further elaboration.

This approach allowed Tim to try something new and grow, knowing that Dina was there to support him on every step. Dina's continued involvement allowed her to balance her other priorities and ensure Tim was on the right track and making good progress.

And yes, the group adopted the recommended solution.

Volunteering for Group Efforts

The last observation I want to make about the Samaritan developers is that they are involved in the broader organization by participating in guilds and communities of practice (CoPs). By definition, guilds and CoPs are volunteers who get together to learn from each other to increase the productivity and excellence of the whole organization.

Sometimes, these groups will face a problem or issue without a clear solution, requiring someone to volunteer to look into a solution and present it back to the group. The Samaritan developers lead by example by volunteering for those efforts and balancing them against their other responsibilities.

Ideally, the Samaritan will volunteer if they agree with the topic's importance, are passionate about it, and have the capacity to work on it. If they lack the bandwidth, they are transparent with the group by telling them, "I'd love to work on this, but I have other responsibilities for the next X weeks, so most probably it will take me Y weeks to present a solution to this group. So I can take it on if we agree with that timeline."

That kind of transparency helps the group decide on a suitable timeline and if someone else is willing and able to work on this to shorten the timeline.

Benefits to Their Career

After considering all those attributes and techniques, Samaritan engineers develop a strong reputation for being excellent engineers with their technical prowess, ability to balance demands, high productivity, and great team players. So, their careers greatly benefit as they get recognized by their management and peers, opening doors for exciting opportunities and career growth.

In conclusion, by reading this article, you can recognize the Samaritans on your team and give them kudos for their excellent work. Also, I hope this inspires more developers to follow in their footsteps.