[tmh88j]

Thanks for the list. There are a lot of great suggestions here, but I think the scope is much wider than just senior engineers for a majority of the items. Here are a few that I think are especially important for junior level engineers.

• Question everything and ask “why” repetitively until you get to the root of problems and situations.

• Do not be adamant about your views. Listen to others and accept that there is more than one way to look at a problem statement, and multiple valid solutions to a problem.

• Have strong mentors to help you navigate and grow in the company.

• Read a few technical books every year.

• Actively seek feedback from your manager

The bullets above brings me to halfway through the list, and I feel that I was pretty selective in the ones that I chose. At this point for the remainder of the list nearly every item is one that I'd suggest for any experience level.

[rekabis]

Second bullet point: recommend using “strong opinions weakly held” (https://medium.com/@ameet/strong-opinions-weakly-held-a-fram...).

Always be ready to review any opinion you have in the face of new evidence. In fact, seek out information that will challenge your opinions. But until the burden of evidence favours another opinion over yours, be prepared to hold and defend your opinions stridently.

[galaktor]

> until the burden of evidence favours another opinion over yours, be prepared to hold and defend your opinions stridently

It might seem obvious, but this part is extremely important and can be very difficult to live by because it encourages (healthy) disagreement and conflict. "Strong opinions, weakly held" is explicitly _not_ about giving in to a majority opinion or because the opinion is coming from a position of higher authority. It's essentially the scientific method. It does not mean you should agree with other peoples' opinions just because they said it louder and/or more often than you did.

I've witnessed senior engineers and managers misunderstand this mantra and (mis)use it to punish ICs who disagreed with ideas of other more/tenured engineers but lacked evidence for being "better".

If you intend to use this framework as a value in your organisation, make sure you and everybody else understand what it means (_especially_ your engineering managers).

[jayrwren]

> It's essentially the scientific method.

I had never considered this before and it is right and true.

Thank you for enlightening me.

[ehnto]

> Have strong mentors to help you navigate and grow in the company.

Sometimes that mentor is you. It's good to know if that is explicitly expected of you in your role, because you will need to budget time to do it properly. It is an extremely important role for any team, so take it seriously too.

For project managers/employers reading, it is paramount that you make mentorship be part of the senior developer's roles. As your company grows, you will be churning through employees as new hires and as people leave. It is very easy to not notice that you just lost all of your domain knowledge because you thought everyone was on the same page, but actually you had your senior developers too busy to effectively spread the tribal domain knowledge.

Documentation is great, but there is nuance and depth to complex software decisions that can't be captured in text in a reasonable amount of time. Not only that, but you probably have less documentation than you think you do, no matter how much you asked for it. People don't read it either. They will sooner google a problem, or ask a colleague.

Some developers absolutely do not like the role because of the regular interruptions, I get it, but some people are more than happy to help be a go-to. It remains the favorite part of my job. Make it a question in your interview process so that you can make sure you have someone who is going to be happy making sure your domain knowledge is shared throughout the company.

[arvinsim]

> Some developers absolutely do not like the role because of the regular interruptions, I get it, but some people are more than happy to help be a go-to.

I would happy to do it if management acknowledges that managing people as a senior dev will take time away from doing actual coding work.

But somehow, they think you can manage to pull off doing deep coding work and managing people at the same time. This refusal to adjust expectations is just baffling to me.