Clean code is not an OO concept. It's a higher level concept. SOLID may help you achieve clean code in OO, but clean code does not mean "know SOLID".
For many of us, it's nothing new, but I do think that it's remarkably easy to just rip code toward a deadline unconsciously without keeping these concepts in mind.
If you do backend, the user doesn't give a shit about your clean code, so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience.
It's not about the user. Coding in a 'clean' way is something you do for your colleagues and maybe future colleagues, who will have to maintain and upgrade your software in the future.
> so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability
I have seen quite some hacks that were intended as 'one-time-only' and 'we-refactor-this-later' solutions. I don't think any of these trade-offs payed out in the end. The proper work to refactor crappy code and reintegrate it into the system took a whole lot of time longer than implementing it correctly in the first place.
The only situation where hacks like this are acceptable in my opinion are 'one-time-only' prototypes (where the prototype code does not find its way back into the codebase), where certain features are shown to a customer, and the rest are mockups.
Sometimes you have to put more time into frontend and you're up against a tight deadline. I'd opt for the UX in most circumstances.
You're assuming that there are colleagues to work on it and that it will live indefinitely.
Many projects, esp. those related to marketing, have a definite lifetime.
You also mention prototypes as another use-case.
Cleaner code as directed by the article is not always necessary.
The user doesn't care about any code. If it works, it works.
I understand clean code is for the developer(s). That's precisely my point. You don't always need to go through a SOLID checklist with your project.
Sometimes you have deadlines, sometimes you're the only dev and you know the project will die post-launch. So if it works; you're good.
I'm not sure why this part of my original comment is confusing or controversial:
"sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience"
A purist push for design patterns and paradigms for every project is not based in the real-world.