“this works, but next time, a better architecture would be x, let's refactor next time we come back to this”

In my experience there is rarely ever a “next time” and “fix it later” becomes “fix it never”. It’s always cheapest to fix worst practices up front rather than letting them metastasize into a huge pile of technical debt later. It’s also rare to find anybody interested in or willing to go back and fix old stuff when priorities often involve chasing the next shiny thing.

Exactly - this, coupled with phrases like "blowing up the sprint," suggests that nobody on this team is likely to trust that the offer of "fixing it later, next time" will be held to.

My rule is code at inception doesn't have to be the best, but every time you touch existing code you must make it better.

Then the code that gets touched the most gets touched up the most. Code that doesn't ever get touched is fine being kinda crappy.

Comments such as “blowing up the sprint” suggest a habit of catastrophizing because an artificial deadline wasn’t met, that’s not going to serve you or your teams well in the long run.

When I hear comments like this from managers it’s generally a sign that I need to start planning an exit strategy.

edit: Also, “my senior developers?” They’re human beings, not your property, dude

Honestly it sounds like a terrible place to work. There’s artificial deadlines with no slack for error, and Junior devs are unable to learn to allow them to be better in the future.

As a manager, the Junior shouldn’t be on the critical path solo. That’s just bad management.

> the difference between "best practices" and actual best practices

hmm...this would sound so much better if you felt your team was pushing for "actual" best practices.

Perhaps it's all working well, but from your words there's so much underlying tension and your clarification adds further distanciation between you and your team.

I'd hate to be on either side of this to be honest.