Seniority

How to behave as a senior software engineer: 7 behaviors that every senior software should have.

Franco Fernando

Jul 13, 2024

Hi Friends,

Welcome to the 80th issue of the Polymathic Engineer newsletter. This week, we will talk about becoming a senior software engineer.

Moving from software engineer to senior software engineer was a difficult step in my career, and it took quite a long time.

However, after some retrospective thinking, I later understood that most of the struggle was my fault. I focused a lot on developing my technical skills but didn’t put enough effort and attention into my behaviors.

Building deep technical expertise on the domain you are working on and on the related technologies is essential, but what often delay your promotions are behaviors.

To become a senior engineer, you must first learn how to behave as a senior engineer.

In the following section, I’ll list things senior engineers do and behaviors they have so that you can use them to speed up your promotion:

Make your team better
Be reliable
Prioritize value
Think in terms of tradeoffs
Don’t complain unless you have a suggestion
Build value, not only code
Search for criticism

How CodeRabbit can support your code reviews

This issue is offered by CodeRabbit, a great tool that automates the code review process and provides context-aware feedback on pull requests within minutes. CodeRabbit uses AI to analyze your codebase, identify possible issues, and suggest improvements.

Try CodeRabbit and Cut Code Review Time & Bugs in Half

Make your team better

One of the distinguishing traits of senior engineers is their ability to uplift the entire team. Senior engineers prioritize the growth of the team over their personal code contributions.

There are many ways to teach and guide your coworkers, including code reviews, pair programming, and design reviews.

For example, a design review isn't only about choosing the best possible design.

It's about weighing the tradeoffs together, asking the right questions, and ensuring everyone understands why some choices must be made.

Team growth is one of the main benefits of reviewing code or discussing a design.

You can also hold regular knowledge-sharing sessions. When you learn something new, make it a point to share it with the team.

Be reliable

Being reliable is about more than meeting deadlines. It’s about building a reputation where your team and stakeholders know they can count on you to deliver high-quality work consistently.

Senior engineers take responsibility for their tasks and projects and understand the differences between estimates, predictions, and commitments.

They make things predictable and deal with uncertainty, so the team can always count on them to deliver. If something goes wrong, the best thing to do is to own up to it and work on a solution rather than pointing fingers.

Prioritize value

Senior engineers understand that not all tasks are equal. They focus on tasks that add the most value, even if they're not the most difficult or exciting.

This could mean fixing the build system or refactoring code, but the goal is always to make the team as effective as possible.

Identify the core problems that need solving and prioritize tasks that add significant value to the customer, the team, or the stakeholders.

Prioritizing value is about making choices that align with the bigger picture and maximize the positive impact of your work.

Think in terms of tradeoffs

Every decision in software engineering involves tradeoffs. Senior engineers must balance various factors to make informed decisions.

As a senior, people expect that you are able to explain what you’re building, the options you considered, and the pros and cons of each.

Always consider multiple solutions before going all-in on one, and prefer easier-to-build and maintain solutions.

It’s also essential to understand the tradeoff between short-term and long-term benefits. Sometimes, a quick fix might solve the immediate problem but lead to more significant issues later.

Don’t complain unless you have a suggestion

Complaining without offering solutions is unproductive. When you identify problems or see something isn't working as well as it could. Focus on finding and proposing actionable solutions.

You can also engage your team in finding the best solution. Brainstorm together, gather feedback, and refine your proposal based on collective input.

This demonstrates proactive thinking and helps build a positive and solution-oriented team culture.

Build value, not only code

Senior engineers understand their role is creating value and not just about creating code. They know what the customers want and use technical solutions to add value.

They are careful with their time, ensuring that customers and stakeholders get the most value for their money.

A good strategy is to engage with them regularly. Understanding their perspectives can help you build well-rounded solutions that address broader needs.

Search for criticism

Be always eager for feedback and open to criticism because this is necessary to grow.

Senior engineers actively ask for feedback from peers, managers, and stakeholders to improve their work.

Regular feedback helps you identify areas for improvement and ensures you're meeting expectations. Take also the time to reflect on the feedback you receive.

The key to continuous improvement is identifying patterns and recurring issues and creating an action plan to address them.

Food for thoughts

When I wasn't yet a senior engineer, I had some bad experiences with nontechnical managers. First, they couldn't fully understand some dynamics inside the team. Second, they couldn't fully assess how hard my work was and its quality. Link

If managers implicitly ask for bad code and no tests, they should be ready to deal with technical debt and hard-to-maintain software. A great manager will know how to find the right balance, such as setting aside time to improve the quality of the code and the tools you use.

The first programming language I learned was C, and if I had to pick a first language as a beginner, I’d still go with it. It gives you nothing but a few built-in keywords, and you need to understand everything else. Plus, many other languages are C derivative or inspired.