Your assumption that seniors will be able to output good code in any situation is what is the issue.
As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.
Again, you need to reasonably interpret what I'm saying. Picking out an edge case and acting as if it is some mic drop is disingenuous. We can't communicate if you hyper fixate on one tree when our discussion is about the forest. Language isn't precise enough to do that without getting extremely verbose. So either I can write a novel in response (I'm not going to) to explain what I said above or you can work with me here. If you're really not getting it I'm sure an LLM could help you out if you also fed it the responses.
> As a senior I've been tasked with impossible tasks
Sure. Even juniors get this. But an impossible task is an impossible task.
> Sure, saying NO is an option
Saying no is always an option. When given an impossible task it's the only option. There's many ways to say no. Not delivering is one of them
> being the NO guy is surefire way to getting fired.
You do not get fired for saying no, you get fired for how you say no. You get fired because the project fails. You get fired because you push back against an egotistical manager who doesn't understand the problem and none of the other engineers back you up.
It's all about how you say no. You don't have to use the word to do so. Instead lead them down the right path and make them understand. You don't lecture them. Managers are like cats, you have to make them think it's their idea. So you have to ask clarifying questions and when doing so you can introduce explanations that let them know that it's not possible. The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
You are not a mindless automata directed by your manager. That's not the role of a senior. Your job is to get things done. A senior knows that "the customer" (in this case your manner) doesn't know what they want and doesn't know how to say what they do. The job is to figure that out as best as possible
> We can't communicate if you hyper fixate on one tree when our discussion is about the forest.
All I'm saying is you can't expect perfect code in impure systems.
> You are not a mindless automata directed by your manager.
I never said I was, but I also can't turn a ship on a dime. I'm asked to perform a task; I'm going to perform to the best of my abilities, but in impure systems the best you can do is patch the leaking part with code and do some basic refactoring. Any moment spent trying to simplify and fix the software will be rightfully considered a waste.
Because a feature sold is better than performance gained (unless it's utterly abysmal).
> The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.
Again, in impure systems half the puzzle pieces have left, some other parts of other puzzles have been mixed, and it's the clock is running.
The more you focus on cleaning code, the more you are falling behind feature wise. Up until a point that you can present to managers "Shit is very bad, we need to refactor."
As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.