Notice I didn't say "Negative -> Positive". It says "Junior -> Senior". Thinking about it further, I don't think it's possible to properly get to the second state (tradeoff-understanding) without going through the first (win-seeking) at some point in your career... in fact, when I'm hiring Junior devs I select for win-seeking behavior. "Tradeoff-understanding" is more of a philosophical disposition that one (IMHO the best engineers) arrives at later. "Win-seeking" is kind of related to the "I'm always right" point: A junior will say "Of course this is the best possible thing to do and there are no drawbacks" where a senior will say "Wait a sec - this might be worth doing, but let's understand what we're changing or giving up".
So, in a sense yeah - the Senior is still "looking for a win", so-to-speak but in a deeper zen-state where they realize "There are no wins: only tradeoffs".
I think the "looks for wins" attribute is just a desireable trait period (like "tries to write good code"), but the ability to weigh trade offs comes with experience and changes how one looks for wins.
In the end, you're making a smart vs. wise distinction, and the two are neither independent nor opposed.
Perhaps fixes the problem in front of them vs. thinks about the problem in context (with the context getting bigger and hairier with more experience).
I think the point is that the "easy" way is not always the right way. For example, it's easy to memoize results returned from a database for 5 minutes in response to a request for performance improvements. It's right to understand the business requirements (including performance), deployment strategy, cost of being wrong, cost of being right, and so forth.
Most tools like that reduces any regexes to dfa's or similar, but most production compilers I've seen don't use tools like that because they're a pain to do proper error reporting for.
Yea, we're not talking about compilers, we're talking about lexers. Regex doesn't even make a little bit of sense in a compiler world. What lexer are you working with?
There are others, certainly, like parsing various configuration formats etc. but they tend to either use tool generated lexers that tend to use dfa's, or handwritten lexers that may or may not use regexes, but there too it's fairly uncommon to see much regex use.
I custom write all of my lexers for exactly the reasons I outlined above.
