1) Use a linter and stop discussing spacing and formatting.

2) Start sizing tickets... or stop an unreasonable expectation of the same delivery for different scopes.

These are standard discussions that most teams sort out early on in a project. So maybe another way to look at this is that you have one underlying problem - you never communicated as a team to agree upon expectations. A 4 person team is way too small to be having these kinds of conflicts, so I'd work on improving communications and helping everyone get to a healthier place.

* If tickets are supposed to be "done" in 3 days, you might find that people are happy if, after 2 days, you have some part completed/merged/released, and a new ticket(s) for the "rest" that is clearly described, detailed, etc. Rinse and repeat. Now, everything is "done" in 2 days, and you're exceeding expectations, and the new manager has a victory to talk about at the next meeting.

* For spacing, figure out how to configure your IDE, or some pretty-printer / indent tool that does it how the tech lead likes it. Obviously, "tabs vs spaces" or how to to format or whatever doesn't actually make any difference to the running code or anything else, so it's not worth arguing about, and no argument about it can ever actually be "won" because it's all personal preference, so if you just do it how they prefer, if that's what they want, they'll be happy. They probably regard this as being about "attention to detail" or being a "team player" as much as being about tabs vs spaces or whatever they say it's about. Start putting comments on _other people's_ MRs to follow the style the tech lead wants when they drop the ball.

* If your fiance is sick, take proper time off when needed, give as much notice as possible, ask people to take notes / record meetings for you to catch up on. Don't let it seem like an excuse / card you play _after_ you drop the ball. Don't be available / working at 80% of capacity/expectations because of this at all times, be 100% capacity / totally on the ball when you are there, but sometimes be away / 0% present when you need to be, and then they'll miss you when you're not there, and appreciate you when you get back.

It's possible you are too far gone at your current job, but maybe not... in any case, you'll find these suggestions apply anywhere. Obviously, deep down, we all know these metrics and tabs vs spaces and stuff are silly, but this is how companies work. These things can be gamed, so be the best at gaming the system, and everyone will be happy. If you fight it, you'll lose. If you don't like it... figure out how to start your own company :) 4k users is impressive, maybe you're closer to that than you think.

If you're not involved in the sizing or estimation then don't commit to any dates and don't bow to any pressure over dates.

In my experience pressure to deliver fast is never enforced. It's all talk used to squeeze and bully people and by incompetent managers who don't know any other knob to turn. Consider this a psychological game. Don't play into it. If you don't deliver by the dates chosen by your manager nothing will actually happen.

In my career whenever I've been faced with the choice between speed and quality I have always regretted it. Even when managers and everyone around me said otherwise. I have never, not once in my 20 year career, actually been punished for good quality even if that meant being late.

I'm actually with your tech lead and your manager on this one. It is imperative that all team members are using the same code style. Its part of your IDE's settings.

While it is fun to debate tabs vs spaces, camelCase vs PascalCase vs snake_case, private _members vs private Members, but in the real world, you match the style of the project you are working on. Always.

This is a problem with your manager. He should provide a pre-hook or a PR action that reformat on pushes. Sure, you can't have everyone using a different formatting convention, that would be insane (especially for diffs) but everyone should have his own formatting on his own IDE.