Glorifying "hard work" as more important than intelligence is a common mistake made by intelligent people when they finally realize that sitting around being intelligent is not, in fact, sufficient to make things happen (this is often surprisingly contrary to expectations formed during schooling).

I think intelligence and attitude are both multipliers. The difference is, if you glorify attitude (to yourself) it can help you improve your attitude. Glorifying intelligence won't improve your intelligence so easily.

However, we programmers must fight egotism and arrogance. The danger is that in forgetting that we are fallible and were new programmers once, we commit a grave error. We're all shortsighted at one time, or another--unless we fall prey to egotism.

Nicely put.

Agreed—I've known too many of the former, who undo years of quality work in a single, well-meaning but unintelligent rewrite.

I think the author is confusing the Real Thing with the hubris-laden, self-proclaimed intelligent programmer. Programming is one of the tiny handful of fields where real intelligence (plus hard work) puts you at a significant advantage over the eager-but-average-intelligence hard-workers.

Programming is like writing or other arts in so many ways: it's easy for those who are competent to immediately recognize another gifted thinker, but the have-nots will dismiss the gifted work as "unintelligible" simply because they don't have the skill or capacity to appreciate it yet (Dunning-Kruger Effect).

And if you work in heterogeneous teams you are just proving the author's point.

If the gifted code is unintelligible to the less skilled how can a team work? Immediately you have the problem of the less skilled not being able to follow the code pratices of the gifted coder, it will be harder to reuse. And the when somebody else has to extend it will cost a lot more time, or to correct something.

Surely some parts of code should be clever, sometimes it has to be clever because there are no alternatives. It should always be somehow well contained. But if you start evaluating code <i>per se</i> you surely end with a bad compromise.

Isn't this obvious to everybody who has to lead a team(I don't)?

I'm not talking about writing the "clever code" that nobody understands (including the coder 6 months afterward)—that's a symptom of the hubris-laden self-proclaimed intelligent programmer the original author is confused about. A genuinely intelligent programmer might early in his career write that esoteric crap as well, but soon learns that nobody—including himself—can understand it after a while. And that is the difference: the intelligent programmer stops doing that immediately while the pseudo-intelligent guy can't stop himself, worlds without end.

I've been in a variety of shops over the past 20 years or so where new kids come in, thinking they're all that and a bag of chips, and systematically replace smart, well-engineered, and working modules with their new ones that will now take years to become as robust, and never be half as elegant.

They do this because they won't take an afternoon to spend the time to read and understand the original code.

Intelligence isn't wholly a matter of genetics—some of these earnest kids do eventually learn better in spite of their natures. They spend enough time with the real good guys to figure out they're not one of them, and then they start trying to figure out why. The fakes go on for years and years writing the worst stuff imaginable and even after shown direct evidence of their incompetency will refuse to reclassify themselves. They start getting defensive, paranoid, thinking they're the poor misunderstood artist. Whatever.

Coders who aren't willing to get into someone else's code to see the "whys" beyond the "hows" are the people I specifically exclude from my projects.

Are humans not capable of enlightenment or are we too far gone in the "me too" era to think for ourselves and learn from others?

Being around a better programmer will rub off on you even if you aren't as intelligent. Intelligence isn't a hard metric you can rely upon in my experience. Otherwise intelligent people have made amazingly stupid mistakes on more than one occassion. Intelligence is only useful if you have the intuition to realize just how little you know.

I agree completely but that shouldn't drive the way a team works.

If the convention says that the code should be as clever as it could be you will have problems. If your tech lead acknowledges some limitations on the team he will have to compromise cleverness for simplicity. And everybody will still learn.

I can't see why my first comment was downmodded, and it's happening for my last comments, confusing or bad grammar? :\

I don't think clever code implies obfuscated or difficult to read code.

Some of the most clever code I've read is conscious of when it breaks from convention.

Any intelligent person will unconsciously understand conventions and recognize their importance. They will also possess an intuition of when those conventions should be ignored, changed, or removed entirely. This is a part of skill acquisition they should be able to pass on to others in your team.

Overly strict adherence to convention only insures that the least-capable person on your team can contribute. Subsequently that person will never be encouraged to improve their skills. Blindly following convention says to me that you're willing to accept inefficiencies and poor design choices for the sake of maintainability by your least competent team member.

You need a mix; the most competent at the top to lead the least competent. Ideally everyone becomes the most competent at some point. Generally you will have people at various points on the ladder. This is a good thing.

We don't need egalitarian dogma ruffling with the food-chain. It's a pretty good system in many cases. :)

That's not the way I read it. It seems to me what he meant to say is that, no matter how good and smart you are - software can outsmart you.

Or in other words, debugging code is twice as hard as writing code, so if you write the smartest code you can, you will not be able to debug it.

But having said that, I do think that the headline is link bait. I only agree with it if you add: "On very large, long term projects".

For the release often and early and start-up crowd, smart and fast is probably better then disciplined and maintainable.

Right. And his mistake is in equating smart languages with smart code.

A smarter language will make debugging easier. Smarter code will usually do the opposite.

> But having said that, I do think that the headline is link bait

You realize the title of TFA is "Mea Culpa", right? The "link bait" headline was written by the HN submitter.

I find that 'intelligent programmers' tend to write better code than 'programmers with intelligence'.

e.g. 'programmers with intelligence' can handle a lot of complexity and need to refactor a lot less, and thus can write messy code and get away with it.

'Intelligent programmers' understand that refactoring is essential and that clearly written, well structured code makes it easy to work with, and far less taxing on the brain.