Sometimes dirty code is more efficient than clean code.

If features get dropped frequently and requirements change every few days, writing best-practices, tested code is wasted time. Learned that in my first job where I thought the other devs were all bad. Until I realized their bad code pays my salary, and my clean code takes more time to develop.

I agree that you have to get shit done sometimes.
But so many "Clean Code"-rules do not generate any effort at all, but are ignored as well.
Like indenting, variable/function naming, avoiding spaghetti code, make modules do one thing, and so on.

You do not have to create a great design on every small part of the software, but make it readable und comprehensible. Remember that source code is written once but read a thousand times.

I see it every day, someone does some tiny shitty hack, because there's no time to do it right. And then this hack spreads with CTRL-c/CTRL-v virus up to the point where you cannot get rid of it without days of work. Five minues here and there can save lots of time on the long run.

Partly agree. My code in reusable components is cleaner and better than in code that is for one customer only.

Requirenents change every few days? What kind of software is that?? Sound more like working on prototypes instead of some production ready stuff.

It's called Scrum

Even scrum is about 2 or 3 weeks. Requirements changing so much is another way of saying there are no requirements and doing things as they come.

@Huuugo I've been doing scrum for quite some years now and yes, requirenents change, but not that often. Your PO or whoever changes requirements so frequently is an asshole and doesn't seem to know what he/she is doing.