I met professional fanatic. Who is fanatic?

• he always knows everything (and he has good explanation for everything)
• never modifies his way of thinking
• has zero flexiblity no matter the circumstances

Imagine asteroid coming to hit the earth and cause ELE. Fanatics work on program which should save the earth. It will operate some high energy laser which will hit up asteroid and change its course. There are 12 hours before the impact.
Fanatics start their TDD approach. They are relaxed and self-confident as they know they create highest quality code. Somewhere between 2. and 3. version of the feature branch, after 20 tiny tickets and total amount of about 35 reviews of even tiner mini-branches asteroid hits the earth and turns it into a desert with no life on the surface.
If fanatics have been on the moon, they would have been happy because just when asteoid was hitting the earth, they understood application domain finally and 3. version of the feature branch was meant to be production version. This wonderful feeling you are on perfect path is worth any cost. It doesn’t matter for them their work is useless from that point on.
Here comes the only bright side of ELE: there are no fanatics anymore.

How not to be a fanatic?

It is simple, when there is question which contains word “always” never answer yes:

• should you always work using TDD? No ! Only when it makes sense. I totally agree with this interesting article: https://techleadjournal.dev/episodes/58/ stating TDD should be applied in the right moment. You need to make some code and only some tests after when you try to understand application domain. Working TDD style from the scratch slows you down by the multiple factor and is waste of time as your work goes to the junk anyway on this stage. Only after you know you are ready to proceed with given feature branch you should start TDD.
• should you always have pyramid like test levels? No ! Only when it makes sense. If your application for example is some rest api thing which has few functions which do not interact with external systems, you can even have square like test levels shape: number of integration tests could be the same as unit tests. The only disadvantage of integration tests in such case is slow feedback as if they fail you do not immediately know where is the point of failure. But you have your unit tests set which will tell you that and large number of integration tests will save you from regression.
• should you always create highest quality possible code? No ! Only when it makes sense. When you create a helper tool for analyzing/filtering/reporting some stuff, make a ticket, make a feature branch and a decent review. Check if code follows good practices, if it is clear and most importantly has good set of tests. And this is good enough! Do not spend hours on the review torturing the details – you really can stop at some point before reaching the perfection. It is a tool, like a car wrench. If it is not useful anymore you can just throw it away and create new oone. 

Do not waste your time on:

• making multiple tickets for simple application
• making multiple branches for simple application
• making each commit be atomically consistent

Do not make simple task bureaucratic horror. I am not afraid to say it loud – in general you can just afford some technical debt. It just needs to be calculated well. Very often the cost of delivering late is much higher.
It is better to have something decent on schedule than have something perfect when it is not needed anymore.