5 ms·

I'm not sure what his definition of intelligence is. Obviously not the same as mine. He states that the reason "triumphalists" annoy him so much is that he us

by jwecker 16y ago

I'm not sure what his definition of intelligence is. Obviously not the same as mine. He states that the reason "triumphalists" annoy him so much is that he used to be one- and then goes on to explain himself programming something very unintelligent in form and function that took him 20 years to fix. I would paraphrase the post as "I used to be dumb and arrogant, but after 20 years I realize how dumb I was and why don't we all stop being arrogant?" I would pass on someone with an attitude of hard-work and responsibility for someone with real programming intelligence (the whole package- product to interface to maintenance) in a heartbeat. The last thing I need is someone diligently corroding a code-base.

scottw 16y ago
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).
- jacabado 16y ago
  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)?
  - agentultra 16y ago
    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.
    - jacabado 16y ago
      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? :\
      - agentultra 16y ago
        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. :)
  - 16y ago
bh23ha 16y ago
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.
- abstractbill 16y ago
  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.
- kscaldef 16y ago
  > 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.
camccann 16y ago
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).
- wisty 16y ago
  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.
  - blacksmythe 16y ago
    Nicely put.
  - trebor 16y ago
    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.
  - deleted 16y ago
    [deleted]
nellboy 16y ago
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.

by jwecker 16y ago

scottw 16y ago

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).

jacabado 16y ago
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)?
- agentultra 16y ago
  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.
  - jacabado 16y ago
    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? :\
    - agentultra 16y ago
      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. :)
- 16y ago

bh23ha 16y ago

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.

abstractbill 16y ago
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.
kscaldef 16y ago
> 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.

camccann 16y ago

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).

wisty 16y ago
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.
- blacksmythe 16y ago
  Nicely put.
- trebor 16y ago
  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.
- deleted 16y ago
  [deleted]

nellboy 16y ago

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.