Though a lot depends on what you define as being a good programmer. 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.
Clear and boring code written by people who know what they are doing is worth it's weight in gold.
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).
Java - although I love it - tends to be verbose and prone to this kind of stuff.
>There is probably a library for that
Too many dependencies is a problem
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.
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.
!! 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.
One mans clever is another mans blindingly obvious. Should we always work to a lowest common denominator?
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 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.
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.
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])
But it's maybe off topic.
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.
Maybe the foolish ones are just more vocal than the ones who are there to learn.
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.
I also noticed my peers tend to consistently rate me 1-2 points higher than I do rate myself. I'm unsure if this is a good thing, if my peers are overestimating me, or if I'm underestimating myself.
I approach your last point differently however; I find it inspiring to look at people being at the top of their fields; makes it easier to plan a route to ramp up your knowledge to that level as the work has already been done.
But... I show up and get it done to the best of my ability.
The common element seems to be hidden process followed by a finished product. Your peers see the code you write (or essays, or speeches, etc). You see the writing process, with all its inevitable inefficiencies and foolish mistakes. No one sees Obama stumbling over his speeches as he gets dressed in the morning, they just see a skilled final delivery.
So without more context, I would guess that you and your peers are rating different things. You're rating every stage of your development, and they're rating the results, or at least the commits.
Other times the fame comes from being big external communicators: Giving a lot of talks about programming doesn't meant that your can code quickly, accurately, or that you can come up with good designs.
When we look at what it is for someone to be a great programmer and a good teammate, there's a whole lot of characteristics that are extremely hard to measure in a job interview. Do we really think it's easier to measure them by just hearing someone give talks or reading some articles? Do you really know that your favorite speaker writes good tests, cares about code readability, or will be there for you whenever you have a technical problem? Will they even work as much as you do, or do they have a contract that says that their speaking is their job, therefore leaving your team behind to do things less famous people have to do, like being on call for cyber monday, or making sure the new shiny system is actually operable in production?
Therefore, my personal experience working with a lot of the socially famous has given me a lot of respect for the great developers I have met that spend less time in self promotion, and more time working on their own craft and take care of their job and family obligations. I've worked with many that are as good, if not better, than the average famous developer I've work with. You just don't know about them.
Behind every successful person is years of hard work. Behind every success is an untold number of failures and learning experiences.
You can't compare yourself to someone who has been making games for 20 years when you're learning.