This is the approach I tried to take as an IC frontend on a building management system dashboard about a year ago. It was basically me and one other frontend, one full-stack, and a QA or 2, plus a manager. My manager I guess had written a lot of the code we'd be interacting with, and I guess was somewhat protective and reluctant to delegate authority over decisions around it. It was a big refactoring project, and I just encouraged my colleagues to take the things they wanted, like rebuilding the state management system. We'd discuss the requirements and why it was necessary, and I'd look for reasons to agree rather than disagree, then we'd be off. Something burnout has taught me is that the marginal differences between one implementation detail or another are not worth getting hung up on unless they pose a real problem, especially when someone else gets to decide that doing it fast is priority (sprints).
> Something burnout has taught me is that the marginal differences between one implementation detail or another are not worth getting hung up on unless they pose a real problem, especially when someone else gets to decide that doing it fast is priority (sprints).
I think this is true. And a self-imposed problem (should a problem arise) is much less frustrating to fix than one that came from a decision imposed by someone else, even if the latter avoided loads of other problems. Sometimes it's better to let people make mistakes (as you believe them to be) and correct them later.
