Be pragmatic. A lot of code does not survive the first year of its existence. Writing clean code at least gives it a chance but sometimes getting things up and running is more important than over-engineering it (which is what clean code fetish can escalate into).
I like to think in terms of disposable code. Lets be real, if it's frontend code, it's going to be replaced in under 2 years. Also most of your team will have moved on and be replaced with a few senior full stack guys that have not yet reached the ripe age of 28 and will be likely to want to try whatever is fashionable. Exaggerating here of course but front end code has a short shelf life in my experience. I don't care about how clean it is but it should be testable, robust, and work as advertised. These three together typically amount to the same thing but they are a bit easier to reason about than "elegance" or whatever.
For backend code, do something simple and conservative that is likely to be still valid in five years because a lot of backend code never gets retired. So doing it right is more important. If it gets retired, it's because something went wrong. Replacing the backend in a company tends to be disruptive and risky for the company. A lot of money in our industry is in patching up existing backends.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.