In a more serious tone. I think we always have to trade off quality of code vs quality of app + speed of delivery.
One month you release something, other month you fix stuff and organize your code, refactor here and there.
We should care about best practices and patterns and wonderful stuff but what really matters is that we are able to deliver (not necessarily on time), be able to do future changes without being a PITA AND be able to work in a project we care and feel proud of because of the previous reasons.
If you deliver but the codebase is always a mess, one day or another you'll be exhausted and frustrated.
If you do not deliver but your codebase is a wonderland, what's the value if no one is using it?
It's better to deliver and enjoy. It might be a mess today but if you can fix it tomorrow, it'll be great.
In a more serious tone. I think we always have to trade off quality of code vs quality of app + speed of delivery.
One month you release something, other month you fix stuff and organize your code, refactor here and there.
We should care about best practices and patterns and wonderful stuff but what really matters is that we are able to deliver (not necessarily on time), be able to do future changes without being a PITA AND be able to work in a project we care and feel proud of because of the previous reasons.
If you deliver but the codebase is always a mess, one day or another you'll be exhausted and frustrated.
If you do not deliver but your codebase is a wonderland, what's the value if no one is using it?
It's better to deliver and enjoy. It might be a mess today but if you can fix it tomorrow, it'll be great.
As somebody else summarised: "clean code is not that clean".
BTW, I loved your "Pintor de brocha gorda" image 🤣