The "senior" title for software engineers comes with some controversies. What makes one engineer "senior", and another "mid". I think the majority of the difference isn't technical, it's in the soft skills.

NOTE: This is a compressed version of the excellent source article found here

Seek out Constructive Criticism of Your Work.

Nothing is sacred, everything can be improved, ask your peers:

1. “What could I be missing?”
2. “How will this not work?”
3. “Will you please shoot as many holes as possible into my thinking on this?”
4. “Even if it’s technically sound, is it understandable enough for the rest of the organization to operate, troubleshoot, and extend it?”

Strive for Empathy

Be the engineer people wantto work with, not the engineer they have to work with.

1. Continually ask for a gut-check from peers and managers on how you are communicating.
2. Aim to be assertive, not passive or aggressive
3. Give and receive constructive criticism focused solely on the work, not the person.
4. Receive critique with an open mind and open heart.
5. Consider other goals and viewpoints when working on a project, for example Product Managers, Design, QA etc.

Embrace Estimates

Avoiding responsibility for estimates and deadlines is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”

Follow Up: Estimate With Data

Estimates without data are prone to the planning fallacy. Estimates should be based on prior velocity, risk factors, and project details. Build estimates in terms of best, medium, and worst case scenarios and be up front with your calculations for each case.

Stay Curious

Senior engineers are intellectually curious about everything. They ask questions first, and seek out knowledge before forming opinions. They self-educate, go down “google-holes”, and always ask “how can I make this better”.

“Find a Broom”

Jon Wooden was one of the most celebrated and successful basketball coaches in the history of college basketball. With all his money, fame, and power, guess what he was often seen doing in the middle of the week? Finding a broom and sweeping out his own gym.

No matter how exciting or appealing a project is, there are always boring tasks that a less mature engineer may deem beneath their dignity or their job title.

Let no task be beneath you, find your broom.

Teach Others

TL;DR: Multiply.

Instead of: “I’ll just do it”, instead say “Let's work on this together”. Always look for teachable moments, and approach each of those moments with a generosity of spirit and a humble attitude.

A senior engineer shifts their focus from individual contribution to multiplication. You can only write so much code, but through effective teaching, you multiply your abilities across many engineers, and they do the same.

Sponsor Many, Mentor Few

The tech industry is seriously challenged when it comes to supporting underrepresented and/or marginalized groups. When we see them, we have a tendency to want to mentor those groups. This assumes they aren’t already good enough for responsibility and/or leadership.

People in these positions often need opportunity and visibility more than advice.

A senior engineer looks for ways to sponsor their ascent into higher visibility roles.

For example:

• suggest someone who could be a good lead on a new project based on their experience in this codebase,
• suggest someone be a postmortem facilitator, or another type of visible leader in a meeting where others are learning
• suggest someone to give a talk at a company or team meeting in which they demonstrate their work
• forward their email summary of a project to a different group of people than the original audience, underscoring why it was interesting or what you learned from it
• ask someone’s manager if you can share feedback about some of their excellent work you witnessed
• mention or share someone’s work in Slack that you thought was helpful, interesting, etc.

Cut Corners the Right Way

TL;DR: Everyone must cut corners, in every project. Do so with intent.

Immature engineers discover concessions in hindsight, disgusted. Mature engineers spell them out at the onset of a project, accept them, and recognize them as part of good engineering.

All engineering decisions exist on an axis of optimality and brittleness. We solve problems on a spectrum from chronic to acute. Senior engineers make educated choices on this spectrum, and understand tech debt is an unavoidable part of development.

When they do find bugs or refactorable software, they say “yep, we made it this far with it and knew we’d have to extend or change it at some point” instead of “I TOLD them this wouldn’t work!”.

Follow the Nine Commandments of Ego-less Programming

1. Understand and accept that you will make mistakes. We can, and should, learn, laugh, and move on without playing the blame game.
2. You are not your code. Remember that the entire point of a review is to find problems, don’t take it personally when a problem is uncovered.
3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
7. Fight for what you believe, but gracefully accept defeat. Never make your dearly departed idea a martyr or rallying cry.
8. Don’t be “the coder in the corner.” Get involved in conversations, and be a participant in your office community.
9. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

**In a larger organization this isn’t strictly true.

Don’t Care About Credit

Hold the success of the project much higher than the potential praise you may get personally for working on it.*

*This is a fine line to walk - if you don’t self advocate you may have difficulty moving up in your career. Work to strike a balance between rightfully owning wins and seeking out credit as a rule.