> My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status,
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.
Well a lot of this depends on context. I've worked at a place where (for reasons beyond my knowledge), there was a pre-existing false conception of my experience and level. In that situation, it was important to disprove that false perception early. Especially in a competitive environment, establishing your cred is important.
In a more functional and team oriented environment, your advice is absolutely critical.
Regardless, it's the personal relationships that are primary here. And there can be some nuance in how to handle those. Jumping in and alienating people would not be a wise choice :)
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.