"I used to be a lot better at clever algorithmic stuff. Now my focus is on clean maintainable code and getting the higher level architecture right, so that I don't need clever algorithmic stuff."

This.

'Clever' is BS.

There's way too much 'clever' going on in high tech, and way too many people interviewing for the wrong skills.

I used to be very clever as well, today, I don't think I could get a job at Google (not that I care) - but I think those interview styles are upside down.

These days I look at Eng. more like construction or plumbing: most of it is not rocket science, really. You don't want new or fancy anything unless you have to.

Good code should be boring and read like English. There should be nothing special about it, unless the problem space really calls for it.

The paradox is - simple code is not psychologically impressive, at least to some people.

I'm actually trying to develop an interview method that will allow me to measure this.

Clever is expensive, dangerous, and usually not worth it.

In fact - if you're trying to do something clever, it might be a sign that something is wrong. There is probably a library for that.

One caveat: it's good to have done a bunch of clever but not-so-useful things in the past, because when I use a library for something, I know what's going on - that's worth something.

Sometimes I feel that first 2 years in dev is basically 'training' - and I wonder if someone with < 2 years experience should even be writing production code.

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.

I think the crux of the problem is: brilliant developers exist (and we tend to follow + see their work more often), but sub-mediocre developers also exist and are way more abundant. If you're looking at a pre-existing code base at work, it's more likely it was created and maintained by the latter rather than the former.

I follow great developers via social media/news and always tend to compare myself to them too much. That leaves me with the impression I'm a failure. But then I just have to go to a local tech meetup (in one of the biggest cities in the US no less) to be facing people with an appalling lack of knowledge, who like to discuss platitudes as if it's the second coming, and who really barely know what the hell they're doing and yet think they're the most clever people on earth. The feeling of wasted time is often an infuriating experience. Many times I've had to excuse myself during Q&A rounds after a presentation, given the outright ignorance displayed by people asking questions. Still, that's one experienced that serves to show me I'm probably doing something right.

I know I sound very negative and judgmental, so apologies. My point is, that's one thing I always recommend to people: go to local tech meetups. You can see how you "compare" there.

I think this is a selection bias. In my experience most of the people attending meet ups are people trying to learn about the topic. They view it as a free class, way to network into a job using that technology, or something similar.

It's admittedly anecdotal. But I've encountered it so often, in different meetups, I don't think it's such an isolated phenomena.

Maybe the foolish ones are just more vocal than the ones who are there to learn.

"Move jobs a few times, inherit some crappy application and look at the code that others write, that has done the opposite for me."

I remember when some of Microsoft's Windows code leaked I took a look and realized that these guys are just regular programmers like you and me. There was really no magic there.

I am sure there are brilliant programmers out there but often they work in a nicely defined environment they can actually control instead of having to deal for weeks with incompatibilities of several systems like many of us.