I hate when senior developers who sit in the same project for centuries are closed for any suggestion and do no challenge their own work and environment.

Whyyyyyyyyy

I feel your pain!
I've found that finding out what sparks their engagement with the code and trying to build a rapport builds trust and eventual respect by veteran Devs.
That and asking lots of questions about what they see is wrong about the legacy and solutions they've come up with but have failed - as you and other devs are still trying to fix something.
Pair programming and general catch-ups are a fab, organic way to do this. Brothers/sisters in arms and all that ⚔️🍻😝

They got burned.

I hate when junior developers who start on a new project (to them) for five minutes are way too eager to introduce every New Hotness they see without any regard for stability or long-term maintainability and do no challenge their own unconscious bias that new is always better.

Whyyyyyyyyy

(in truth, the right answer is somewhere in the middle)

@fzammetti my rant has nothing to do with seniority itself. It's more about being senior (which, in this case, includes the ability to make conscious decisions and not focusing only on short time execution perspective), AND being in the same project for years, AND being unable to take a look on your existing work, then, even internally, identifying own mistakes and suggesting better solutions. The team tries to make some improvements to existing system's design, but cannot do much about it due to people that say just "no" and their judgement is grounded in years they have spent working on this product rather than actual explanation why this or that won't do better job than existing design.

@puradawid Well, I would certainly agree that any senior that can't/won't explain why the answer is no isn't doing their job. On the other hand, sometimes the reason for no is simply that change isn't always good or necessary. McCoy said it best in Star Trek: The Motion Picture: "I know engineers, they looove to change things". And we do! But when you have a stable system that's doing the job there's always going to be a tension between people who want to change things because the state of the art has changed versus those that more fully appreciate that stability is, in most cases, more important because unless the system IS the product, the business doesn't care how a system is built, they only - rightly - care about what it enables them to do. It's why airports still largely run on 1960's technology. It's sure not pretty, and us engineers would LOVE to change it, but it's (mostly) stable and gets the job done, and sometimes that's all the reason you need for "no" to be valid.