Yes. I have worked in similar places and it is maddening. "Sorry, you can't use that highly idiomatic construct because an inexperienced person might not understand it straight away. Ignore the fact that someone experienced is going to wonder why the hell it is done the naive way"

"One mans clever is another mans blindingly obvious. "

I think that, when in hindsight, something looks really obvious, it was probably the right thing to do.

I don't think lambda's or anything that specific are clever.

Every tool has it's use.

Here's an example of 'bad clever' - writing an optimized 'find' function which may very well be a little faster than the lib 'find' - but which will have absolutely no impact on the software.

I find that 'performance' is one of those areas that tends to be way over-engineered right off the bat.

Because of the historical (and current) performance constraints of systems - we soft engs. have 'built in' impetus to want to make things perform better.

There are very, very few things I will allow myself to optimize from the get-go. Even now - I have to urge myself to not do this. Code for clarity, then do the tweaking where necessary, because it's nary impossible to tell where the real bottleneck will be.

Does the choice have to be about the lowEST common denominator? Maybe a good criteria is to code for a lowER common denominator, just to account for the Bus Factor, maintainability, and so on. The lowest common denominator that makes sense, rather than playing denominator golf or disregarding the fact that you're coding for the benefit of your colleagues, too.

I disagree. Rather than coding for the benefit of someone who doesn't know the language very well - people should learn the language. If the company is hiring maintenance programmers who don't know what lambdas are - again, their problem.

I feel like we should have higher standards, and use the abstractions available to us grow the code towards the problem. Instead I see people writing long sprawling application that use the same low level library routines everywhere.

Maybe it's a quantity vs quality thing. And quantity is much harder to hire for, so my ideas lose out.

I's about common sense. I'm not saying your former place of employment is full of idiots, but some people hold fast to the that's just the way it's done paradigm. None of what you listed is clever. Those are basics, and I think you'd be hard pressed to find people that disagree that those are basics.

It will vary across languages. Someone who only knows Java 7 (or 8 without the use of lambdas) is going to find 4 chained anonymous functions in JavaScript clever simply because it's unfamiliar. Language specific or something from an unfamiliar paradigm (think functional programming for many new grads) will seem clever. Breaking 500 lines of continuous code into manageable methods is what everyone should be striving for.