I must admit I am wary of this attitude. I've worked at places where lambdas are clever, or generics are clever, or writing constructors that take arguments is clever, using LINQ on collections is clever, refactoring copy-pasted code into methods is super clever, etc etc.

One mans clever is another mans blindingly obvious. Should we always work to a lowest common denominator?

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.

I think there are two types of clever.

There's the type of cleverness that shows off too complex a solution or intricate knowledge of a particular system in a less portable way. It's fanciful and surprising and is a mess to maintain later. People who employ that cleverness for anything other than toy example code meant as a curiosity are employing the bad sort of clever programming.

Then there's the sort of cleverness that makes a leap that becomes a new idiom over time. It's not immediately apparent before you've seen it, but it's deceptively effective and looks really obvious in hindsight. Some of those idioms are local to an organization or vertical to an industry or language community. Some are so elegant that they jump from one community to another. The "Orcish Maneuver" or using !! to force a variable into a 1 or 0 to approximate a boolean are some examples that come to mind. Yes, someone was doing something clever the first time something like those was done. When an example is seen it's simple enough to recognize and understand, though. It turns out to be useful and becomes a common and understood to be almost straightforward way to do things. That's the sort of cleverness to which one should aspire. That sort of obvious in hindsight elegance is what's truly clever.

I think familiarity is a key factor here, and I think your examples highlight that.

!! seems slightly arcane to me, and I'd rather write some function like to_bool() to make the intent clearer, but I imagine if you're used to it !! is immediately obvious, and to_bool() would be confusing because it's not !!. (And conversely, if to_bool was part of a standard library and widely used, !! would seem arcane.)

I don't think either technique has any real practical advantage, and the real trick is writing your code for the people who need to read it.

This! So much this! (Unfortunately my single up-vote is not enough to help you sir.)

Unnecessary complexity is god-mother of all evil (premature optimization included). The goal is to use as simple (to understand and to maintain) means, code, idioms etc. as the problem you are solving allows. I know fancy stuff and I know when not to use it (i. e. almost always) and value simple robust code much more than fancy fragile crap.

Seems like more people are trying to solve easy problems by complex means than people trying to solve difficult problems by any means. Sad thing is by using unnecessary complex means even the simplest problem can be obscured beyond mental capacity of anyone. Welcome legacy spaghetti mess.

I agree in principle, but "boring" is in the eye of the beholder. Some developers don't understand "map", that doesn't mean you should replace every `.map` with a for-loop.

>There is probably a library for that

Too many dependencies is a problem

Down-vote me if you like, but I'm speaking from a lot of experience, many companies, many projects, many languages, from 'real time / embedded' C w/machine code + custom ASICS, all the way up the stack to the highest level of abstractions + UX.

Clear and boring code written by people who know what they are doing is worth it's weight in gold.

There's different dimensions of clear and boring, however. I've had to wade through a lot of clear and boring code that was mostly fashionable OO ceremony; the verbosity of it obscured what was going on.

New abstractions need to be introduced sparingly. Building new kinds of abstractions is one of the easiest ways that "cleverness" gets into a codebase, and if the abstractions are don't pay their way, they just obscure. Often they aren't even necessary at all (indirections that only ever point to one thing).

I think of this case as boring vs tedious. Tedious code should be refactored (if possible) to become boring.

Agreed on the 'ceremony' and 'boilerplate'.

Java - although I love it - tends to be verbose and prone to this kind of stuff.

Yeah, I've definitely developed an aesthetic taste for code cleverness. Like, one time I was writing some python and using third-party code that expects a list of user-provided classes. It was really annoying and I kept passing it a bare class which made things fail. I ended up making a class that behaves like a list containing itself, and it completely "fixed" the problem. That really shouldn't be production code, though.

Why didn't you just pass one element list with your class with it, for example:

  class MyClass:
     pass

  class_list = [MyClass]
  third_party_function(class_list)
  # or just 
  third_party_function([MyClass])

?

creating some simple wrapper for third party function, e.g.

  def wrapper(C):
     third_party_function([C])

could also be much simpler solution :)

But it's maybe off topic.

Although I'm not a fan of it. If you are doing "clever" coding. I urge fellow coders to please write some test cases for your "boring" programmers. Helps the rest of us to be brought up to speed and maintain it.

Let me know when you have your interviewing technique worked out, and where I can apply to somewhere using it.