Be pragmatic.
It is easy to get caught up in the idea of writing elegant/brilliant/perfect code. You can golf code down to a high performing, low footprint ball of random symbols that no one else can decipher and that's fun ... for a novelty site.
As developers, I think we often forget that at the end of the day this isn't about pleasing us or making our code look the best, but rather solving a problem and creating an enduring solution. We want software that works, that doesn't have defects, and is easy to maintain.
This means trade-offs. Optimizing a routine to shave off 9 milliseconds when it is part of a UI and the average user takes hundreds of milliseconds even to process and respond is probably a waste of time. Often we'll see a framework touted as "100 times" faster and switch even though it's 10x harder to work with. What do you gain? An imperceptible change in performance for higher cost and longer production cycles.
I was on another thread when someone made the blanket declaration "if statements are always a design flaw." Of course, instead of actually explaining why, they continue to maintain they didn't have to explain because it's just a fundamental rule of pure design and using them is wrong.
I know it may sound rude, but my hard lesson to learn was "so what."
Personally, I know no matter what level of developer is touching my code, this:
if (a > b) {
x = 'yes';
}
else {
x = 'no';
}
Is far more readable and easier to debug and maintain than this:
x = a > b ? 'yes' : 'no';
I may revel in the conciseness of my brilliant code, but what happens when I also have to set y? You could do this:
x = a > b ? (y = 1, 'yes') : 'no';
But what are you really gaining? I would posit not much. You don't need to compact your code, there are tools that do that for you. Why not make it easier to read and add space to add other logic in the branch?
The same goes with frameworks. I'll hear "that framework adds so much overhead." But if the overhead isn't visible to the end user and gives my developers the ability to generate stable code 4x faster, why wouldn't I use it?
That was a hard lesson to learn because I focused early on my career on being elegant, perfect, and "right." And I produced code that I could brag about and, guess what, a lot of people came along and struggled to maintain. I could get on a soapbox and call them "novices" or I could admit that I was programming for the wrong person: me, instead of the business.
Please, learn to be pragmatic.