15 ms·

Programming: Attitude Trumps Intelligence

170 points by malbiniak 16y ago

Jach 16y ago
Ha, as if attitude resides in something other than the brain. http://yudkowsky.net/singularity/power http://yudkowsky.net/singularity/power I don't think programmers are alone in this problem, however. People by nature tend to get into their own factions and bash anyone else, even if they have more in common than not. (Also note that programmers do tend to be more harsh toward non-programmers than other programmers.) Though I think programmers haven't yet (to my knowledge) resorted to actual violence, which indicates at least a little more maturity than others... "Maturing" doesn't make a better programmer, either, I don't think, and I'd rather have Linus Torvalds' programming abilities than anyone else I can think of right now. Plus, a lack of cleverness isn't going to save you, for no matter how much work and effort you put into digging a hole for that gold, a little cleverness would have told you you're digging in the wrong place. Lastly, I really didn't like this bit: "It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention." When you've met the most brilliant human, see which software dwarfs his brain and which doesn't. I bet a lot of brilliant people can handle a lot of different complexities. Finally, while I'm a fan of simplicity (in the Einstein sense), convention should hardly be a rule. Progress can only be made by breaking convention.
- klochner 16y ago
  He maybe overstepped a little, but the principle is sound: For robust, maintainable software systems, convention and simplicity trump cleverness.
  - benatkin 16y ago
    It's vague enough that the principle is both sound and useless.
  - abstractbill 16y ago
    Not the way he's meaning it. This is a follow-up to his previous post, which claims that "There are no super programming languages, only super programmers." Cleverness gets you things like Garbage Collection. Convention and simplicity leaves us all using assembler because there's no need for "clever" language features.
  - camccann 16y ago
    In my experience, writing simple code often requires more cleverness from the programmer than does writing clever code.
deleted 16y ago
[deleted]
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)?
oconnore 16y ago
Well, for better or for worse, no lisper I know would ever try to fuse a database system in at the kernel level. That's one of the ugliest system designs I've ever heard of. The whole point of lisp is that the language is extensible, so that once you solve one problem, you NEVER have to think about it again. In other languages, you might have to put some conditionals in, or free some dynamic memory somewhere every time you do a task. In Lisp, you think about that once, build a syntactic structure that does it for you, and then free yourself to actually consider how to solve your problem. It's the opposite of rock-star-programming. It is assuming that you aren't a rock star, and therefore working to reduce the complexity that your puny mind has to deal with.
- kenjackson 16y ago
  How is what you described (having to solve a problem once) different than most languages (especially those with garbage collection). It seems like you're describing libraries, ala growing a language (http://video.google.com/videoplay?docid=-8860158196198824415# http://video.google.com/videoplay?docid=-8860158196198824415...).
  - sdevlin 16y ago
    Lisp dialects afford you more powerful tools for abstraction. Whereas most languages provide abstraction at the function level, Lisp allows for syntactic abstraction via macros. Think of constructs like the if-statement that only evaluates one of its consequent and alternative, or short-circuiting and- and or-expressions. These things are impossible (or awkward/difficult) in most languages, but Lisp makes them relatively simple.
    - kenjackson 16y ago
      It's a nice tool for abstraction, but its simply another tool. Once you have the ability to make a function that returns an arbitrary value, including other functions, and can take an arbitrary value, I think you're largely done. I can build conditionals, lazy vs eager eval, and the whole nine with this simple contruct. And sure, it starts out looking uglier, but c'mon, we're comparing to Lisp. :-) The real question is how much of the language is built out for you already. And what type of "culture" does that build out presume or create...
deleted 16y ago
[deleted]
abstractbill 16y ago
Reflecting upon my previous post, I am wondering why LISP triumphalists like Paul Graham annoy me so much? Perhaps it is because I used to be one myself, in spirit if not in syntax. And also because I now see them as a major symptom of what ails programming. Responding just to the Lisp part of this post, all programming languages suck (but not equally!). Lisp isn't designed to let you show how clever you are, it's just designed to suck a little less. For example, until Java came along, Garbage Collection was still mostly regarded as a "toy" feature, rather than as something whose absence would make a language suck. Lisp originated Garbage Collection of course, and remains the only language where you can can find a few other "non-sucky" features that still haven't caught on in the mainstream.
- joshhart 16y ago
  The only language? What about Haskell's type inference and lazy computation? Or the great pattern matching. These show up in my current favorite language - Scala - but I don't exactly think this a mainstream language.
  - jpr 16y ago
    You can implement type inference and lazy computations in standard Common Lisp. You can't implement macros or proper runtime redefinition of functions in standard Haskell.
- mahmud 16y ago
  Lisp is the perfect language for its ex-users and wannabes to wax poetic about. For the rest of us that do it for a living, it just has the least annoyance. I would happily jump ship the moment I get a dynamic, interactive language with CLOS, s-exp notation and some industrial, enterprise-y tools. I hope to see the day when franz and lispworks partner with IBM and Oracle and push Lisp certifications at the masses. Also, For Dummies books! Throw these smug lisp weenies off their pedestal and replace them with armies of impressionable and malleable macro-jockeys.
  - arethuza 16y ago
getonit 16y ago
One last thought to bare in mind before disagreeing: http://www.savagechickens.com/2008/12/iq-test.html http://www.savagechickens.com/2008/12/iq-test.html
klochner 16y ago
Anyone read the prior post he references? This one is supposed to be acknowledging that he was too aggressive in attacking the Lisp community in his last post ("Mea Culpa"). Sounds like the author is having trouble with the humility thing: "I'm really humble, so now everyone else has to be as well" just one of the many faces of narcissism
- abstractbill 16y ago
  Yes, in which he claims that all languages are equally good. In which case I assume he writes everything in assembler.
  - anthonyb 16y ago
    That doesn't appear to be too far from the truth: "I spent those decades debugging the Frankenstein. In the OS crash debugger. In hex. Because wasn’t it oh so clever and efficient to build a radically new kind of database with extreme reliability requirements as a highly multithreaded kernel extension to the OS?"
  - rbranson 16y ago
    ... or Visual Basic... or COBOL... or any other language everyone has pretty much determined is awful.
    - arethuza 16y ago
      Those languages merely aspire to true awfulness - for truly mind warping horror you need to see some in-house designed languages that I have seen that use XML as their starting point.
10ren 16y ago
The Humble Programmer (Dijkstra's Turing Award lecture) http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD... IMHO, factors influencing programming intelligence (PQ?) include things like short-term memory capacity, and experience of similar kinds of problems. But everyone has a limit, of innate talent and of acquired talent, and some of us pursue increasing challenges until we hit that limit - and then seriously work on strategies for tackling complexity. Probably the more intelligent of us recognize this issue earlier. I hit my limits daily, despite my best efforts of decomposition, abstraction, narrowing scope, narrowing aspects of concern (I often fall into the trap of trying to optimize before being 100% on top of my algorithm), defining the problem explicitly (ask the question before answering it), and trying out ideas to see if they work (yes, trial and error) and to gain more information (data) about the problem. Perhaps the best an individual can hope for is to make intelligence and time fungible - to be able to solve a problem of any complexity, given sufficient time. Unfortunately, the task of decomposing problems well does not itself seem to be decomposable, as they grow in complexity.
bh23ha 16y ago
It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention. I am tempted to tattoo this on... somebody.
baguasquirrel 16y ago
I agree with the idea that attitude trumps intelligence, and I humbly disagree with the idea that it's somehow "better" to hire someone smart over someone who's hard-working as others are suggesting. But what kind of dichotomy is that? The reason why languages like Lisp appeal to me is because I don't like it when my hard work is wasted. It's pissy when you spend more time trying to circumvent their poorly conceived type system than you spend on the actual problem itself. I don't like it when my code is unnecessarily complex because of my tools.
calibraxis 16y ago
The author's work on fundamentally improving programming looks interesting: http://subtextual.org/ http://subtextual.org/
- anthonyb 16y ago
  Hmm, except that his first example is weird. He tries to rewrite all of his logic, instead of just putting an extra case at the top: if (b & c) { x = 3; elif (a) { ... which according to his methodology is an "overlap", and thus bad - but seems a lot clearer to me than his program's simplification: if (a & (!b | !c)) { x = 1; } else if (!a & ((b & !c)|(!b & c))) { x = 2; } etc... Ditto for the fibonacci stuff and his later examples. And they're pretty straightforward. For larger functions I can see it spiraling out of control.
mburney 16y ago
The compelling part about pg's lisp "triumphalism" is that he describes how lisp helped him build a better product and add/debug features faster. This author doesn't address that point -- he's talking about a kind of elitism that one would find in newsgroup flame wars. I (and many others) couldn't care less if a language makes me appear brilliant, but I do care about what advantage that language gives me. (EDIT: I wrote this comment before viewing the link to his previous post where he directly addresses the issue. Still wish he'd elaborate more though on how the abstraction level of a language would not help a programmer do better work. Is it enough to just proclaim "There are no super programming languages, only super programmers" for it to be true?)
- mortenjorck 16y ago
  I think the author is responding to the self-indulgent "Reddit clone in three lines of lisp!" variety of stunt-programming, where best practices, standards, and readability take a backseat to showing off how much hard-to-read compound logic you can cram into a single line of code. Honestly, I don't have a problem with those, as long as the practices involved in them don't seep into everyday programming.
- tensor 16y ago
  Still wish he'd elaborate more though on how the abstraction level of a language would not help a programmer do better work. Is it enough to just proclaim "There are no super programming languages, only super programmers" for it to be true?) This is trivially easy to disprove. C vs assembly. Java/C#/Python/Ruby/etc vs C and assembly. Manually creating databases in something like C for every application vs relational databases and SQL. I think it is painfully obvious that we have come a long way due to "triumphalism." Not all ideas bear fruit, but those that do can have a huge impact. His conclusion advocates that we should all simply program in assembly and use good practices. I feel that is an absurd notion.
DanielRibeiro 16y ago
Programming is an embarrassment compared to other fields of engineering and design. Our mainstream culture is one of adolescent self-indulgence Alan Kay made the same point in a interview with ACM: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523. He, much more eloquently, said: Once you have something that grows faster than education grows, you’re always going to get a pop culture. Fixing this is a much bigger issue. It in fact encompasses a lot of other areas, and they are no closer to solving it than computer science is (which was humorously cited to be a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia). Edit: As a side note, Eric Ries recently said on a Lean Startup talk we live in an era where ignorance is truely optional http://bit.ly/9v0XI6 http://bit.ly/9v0XI6 . The problem is that most people opt in.
strlen 16y ago
I agree that attitude trumps pure intelligence in general for programming projects. Indeed, pure intelligence tests (e.g., "why are manhole covers round?") fell out of favour as interview techniques at Microsoft. As far as I know (my own and friends' personal interview experience) Google never used such for programming interviews: ability to apply intelligence to the task at hand (programming, software engineering/architecture and algorithm/data-structure design) is what the industry leaders look for. This (the ability to strip away non-mathematical details and break a problem down to pieces that are machine-solvable, preferably by known and proven algorithms) in itself takes not just intelligence, but also practice. Nonetheless, there are some projects that require a minimal amount of intelligence and/or education and beyond that no amount of attitude can help. E.g., I'd love to hack on applications of machine learning algorithms, but I don't have the educational background to do so. It would require years of serious study to be able to even do even the most basic work in that field. On the topic of the author's previous post, I would agree that a way to get top programmers to work on less-interesting business applications is to let them use a more interesting language. In fact, some of the most difficult development (systems programming, scientific computing) goes on in fairly boring languages (although using higher level languages for this sort of work is becoming a reality). I will, however, take strong issue with the assertion that Common Lisp is a language only suitable to top percentile of programmers: countless schools teach Scheme as the first programming language to undergraduates and Scheme is a much more functional language than idiomatic Common Lisp. Macros aren't inherently related to functional programming (nor is writing your own macros required for Lisp hacking, Graham is fairly unique in this respect). Closures (a heavily used feature of Common Lisp) aren't inherently functional, neither are multiple dispatch nor dynamic typing. Lack of syntax is a salient feature, orthogonal to all other distinguishing features (except for macros) and again, not especially "functional". If it's possible for newbies to write fairly mind-bending Scheme(1), why shouldn't it be possible for educated and experienced (even if not 99.99th percentile aptitude-wise) programmers to do the same in a less pure language (Common Lisp, OCaml)? (1) My alma matter (which most people, even those living next to it, haven't heard of) uses Haskell: http://www.cse.scu.edu/~atkinson/teaching/wi10/070/ http://www.cse.scu.edu/~atkinson/teaching/wi10/070/
- ckuehne 16y ago
  Just to clarify: "why are manhole covers round?" is not a test of intelligence in the narrower sense. "Add the next number in the following sequence 1,4,9,16" is.
bloopybloppy 16y ago
Why is clever programming always associated with some awful monstrous unmaintainable implementation? Being clever shouldn't mean that you're hacking things together ad-hoc just to make it work. On the contrary, that is the opposite of being clever. I really doubt that most of the bad code is written by "clever" programmers. Other factors are at play here.
- kragen 16y ago
  Hacking things together ad-hoc just to make it work isn't the way that clever programmers produce awful monstrous unmaintainable implementations. That's the way un-clever programmers do. Clever programmers, instead, invest lots of time into reinventing things that don't need reinventing, and then must be learned by those who come after them; and implementing things that don't need to be reimplemented. Reams of copy-pasted code is not the affliction of the clever programmer. Instead, you discover that there's a strategy factory to instantiate a strategy that chooses which home-grown database abstraction layer to use and what kind of caching to apply to it; and that there's a home-grown template library on top of that, with its own caching layer. And it's all configured with a plugin system that uses a bunch of XML metadata files for each plugin — all in order to run a message board.
rmundo 16y ago
There is a subfield of programming that feels pretty grown-up: mission critical applications where a bug can cost you a multi-million dollar spacecraft or a plane-load of human lives. The pace of innovation can feel glacial, safety("has this been done before, is it reliable") is valued above "brilliance", and the whole process with its checks and tests and paperwork can feel stifling, but it produces complex code that works(most of the time). I wonder if this is a local maxima, though, and if there are more effective ways to produce rock-solid, high performance code. I'd love to see how SpaceX produce their code, for instance.
cookiecaper 16y ago
Like most other attributes, attitude and intelligence need to be considered with the whole. You can have a great attitude and no intelligence, but that won't get you anywhere, and neither will extreme intelligence and a bad attitude. Of course, every programmer needs a mix of attitude and intelligence to be effective. For my part, I'd rather hire an average programmer with a good attitude than an excellent programmer with a bad attitude; clock cycles are much cheaper than the friction caused by a rogue developer.
jergosh 16y ago
I love how "What a load of self-indulgent adolescent crap." can by juxtaposed with his 'About me' photo: http://subtextual.org/AboutMe.htm http://subtextual.org/AboutMe.htm
yason 16y ago
They're both needed, of course: 1) Intelligence steers hard work to the right direction. 2) Hard work turns intelligence into reality.
j_baker 16y ago
I see the author's trump card and play the von Manstein card! "There are only four types of officer. First, there are the lazy, stupid ones. Leave them alone, they do no harm…Second, there are the hard-working, intelligent ones. They make excellent staff officers, ensuring that every detail is properly considered. Third, there are the hard-working, stupid ones. These people are a menace and must be fired at once. They create irrelevant work for everybody. Finally, there are the intelligent, lazy ones. They are suited for the highest office." This seems pretty relevant. Attitude is important to being good, but it inhibits you from becoming great. Likewise, attitude is a requirement to be terrible.
deleted 16y ago
[deleted]
losethos 16y ago
This makes me feel the same way as when a boss said he'd rather be lucky then have skill.

170 points by malbiniak 16y ago

Jach 16y ago

Ha, as if attitude resides in something other than the brain. http://yudkowsky.net/singularity/power http://yudkowsky.net/singularity/power I don't think programmers are alone in this problem, however. People by nature tend to get into their own factions and bash anyone else, even if they have more in common than not. (Also note that programmers do tend to be more harsh toward non-programmers than other programmers.) Though I think programmers haven't yet (to my knowledge) resorted to actual violence, which indicates at least a little more maturity than others... "Maturing" doesn't make a better programmer, either, I don't think, and I'd rather have Linus Torvalds' programming abilities than anyone else I can think of right now. Plus, a lack of cleverness isn't going to save you, for no matter how much work and effort you put into digging a hole for that gold, a little cleverness would have told you you're digging in the wrong place. Lastly, I really didn't like this bit: "It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention." When you've met the most brilliant human, see which software dwarfs his brain and which doesn't. I bet a lot of brilliant people can handle a lot of different complexities. Finally, while I'm a fan of simplicity (in the Einstein sense), convention should hardly be a rule. Progress can only be made by breaking convention.

klochner 16y ago
He maybe overstepped a little, but the principle is sound: For robust, maintainable software systems, convention and simplicity trump cleverness.
- benatkin 16y ago
  It's vague enough that the principle is both sound and useless.
- abstractbill 16y ago
  Not the way he's meaning it. This is a follow-up to his previous post, which claims that "There are no super programming languages, only super programmers." Cleverness gets you things like Garbage Collection. Convention and simplicity leaves us all using assembler because there's no need for "clever" language features.
- camccann 16y ago
  In my experience, writing simple code often requires more cleverness from the programmer than does writing clever code.

deleted 16y ago

[deleted]

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

oconnore 16y ago

Well, for better or for worse, no lisper I know would ever try to fuse a database system in at the kernel level. That's one of the ugliest system designs I've ever heard of. The whole point of lisp is that the language is extensible, so that once you solve one problem, you NEVER have to think about it again. In other languages, you might have to put some conditionals in, or free some dynamic memory somewhere every time you do a task. In Lisp, you think about that once, build a syntactic structure that does it for you, and then free yourself to actually consider how to solve your problem. It's the opposite of rock-star-programming. It is assuming that you aren't a rock star, and therefore working to reduce the complexity that your puny mind has to deal with.

kenjackson 16y ago
How is what you described (having to solve a problem once) different than most languages (especially those with garbage collection). It seems like you're describing libraries, ala growing a language (http://video.google.com/videoplay?docid=-8860158196198824415# http://video.google.com/videoplay?docid=-8860158196198824415...).
- sdevlin 16y ago
  Lisp dialects afford you more powerful tools for abstraction. Whereas most languages provide abstraction at the function level, Lisp allows for syntactic abstraction via macros. Think of constructs like the if-statement that only evaluates one of its consequent and alternative, or short-circuiting and- and or-expressions. These things are impossible (or awkward/difficult) in most languages, but Lisp makes them relatively simple.
  - kenjackson 16y ago
    It's a nice tool for abstraction, but its simply another tool. Once you have the ability to make a function that returns an arbitrary value, including other functions, and can take an arbitrary value, I think you're largely done. I can build conditionals, lazy vs eager eval, and the whole nine with this simple contruct. And sure, it starts out looking uglier, but c'mon, we're comparing to Lisp. :-) The real question is how much of the language is built out for you already. And what type of "culture" does that build out presume or create...

deleted 16y ago

[deleted]

abstractbill 16y ago

Reflecting upon my previous post, I am wondering why LISP triumphalists like Paul Graham annoy me so much? Perhaps it is because I used to be one myself, in spirit if not in syntax. And also because I now see them as a major symptom of what ails programming. Responding just to the Lisp part of this post, all programming languages suck (but not equally!). Lisp isn't designed to let you show how clever you are, it's just designed to suck a little less. For example, until Java came along, Garbage Collection was still mostly regarded as a "toy" feature, rather than as something whose absence would make a language suck. Lisp originated Garbage Collection of course, and remains the only language where you can can find a few other "non-sucky" features that still haven't caught on in the mainstream.

joshhart 16y ago
The only language? What about Haskell's type inference and lazy computation? Or the great pattern matching. These show up in my current favorite language - Scala - but I don't exactly think this a mainstream language.
- jpr 16y ago
  You can implement type inference and lazy computations in standard Common Lisp. You can't implement macros or proper runtime redefinition of functions in standard Haskell.
mahmud 16y ago
Lisp is the perfect language for its ex-users and wannabes to wax poetic about. For the rest of us that do it for a living, it just has the least annoyance. I would happily jump ship the moment I get a dynamic, interactive language with CLOS, s-exp notation and some industrial, enterprise-y tools. I hope to see the day when franz and lispworks partner with IBM and Oracle and push Lisp certifications at the masses. Also, For Dummies books! Throw these smug lisp weenies off their pedestal and replace them with armies of impressionable and malleable macro-jockeys.
- arethuza 16y ago

getonit 16y ago

One last thought to bare in mind before disagreeing: http://www.savagechickens.com/2008/12/iq-test.html http://www.savagechickens.com/2008/12/iq-test.html

klochner 16y ago

Anyone read the prior post he references? This one is supposed to be acknowledging that he was too aggressive in attacking the Lisp community in his last post ("Mea Culpa"). Sounds like the author is having trouble with the humility thing: "I'm really humble, so now everyone else has to be as well" just one of the many faces of narcissism

abstractbill 16y ago
Yes, in which he claims that all languages are equally good. In which case I assume he writes everything in assembler.
- anthonyb 16y ago
  That doesn't appear to be too far from the truth: "I spent those decades debugging the Frankenstein. In the OS crash debugger. In hex. Because wasn’t it oh so clever and efficient to build a radically new kind of database with extreme reliability requirements as a highly multithreaded kernel extension to the OS?"
- rbranson 16y ago
  ... or Visual Basic... or COBOL... or any other language everyone has pretty much determined is awful.
  - arethuza 16y ago
    Those languages merely aspire to true awfulness - for truly mind warping horror you need to see some in-house designed languages that I have seen that use XML as their starting point.

10ren 16y ago

The Humble Programmer (Dijkstra's Turing Award lecture) http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD... IMHO, factors influencing programming intelligence (PQ?) include things like short-term memory capacity, and experience of similar kinds of problems. But everyone has a limit, of innate talent and of acquired talent, and some of us pursue increasing challenges until we hit that limit - and then seriously work on strategies for tackling complexity. Probably the more intelligent of us recognize this issue earlier. I hit my limits daily, despite my best efforts of decomposition, abstraction, narrowing scope, narrowing aspects of concern (I often fall into the trap of trying to optimize before being 100% on top of my algorithm), defining the problem explicitly (ask the question before answering it), and trying out ideas to see if they work (yes, trial and error) and to gain more information (data) about the problem. Perhaps the best an individual can hope for is to make intelligence and time fungible - to be able to solve a problem of any complexity, given sufficient time. Unfortunately, the task of decomposing problems well does not itself seem to be decomposable, as they grow in complexity.

bh23ha 16y ago

It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention. I am tempted to tattoo this on... somebody.

baguasquirrel 16y ago

I agree with the idea that attitude trumps intelligence, and I humbly disagree with the idea that it's somehow "better" to hire someone smart over someone who's hard-working as others are suggesting. But what kind of dichotomy is that? The reason why languages like Lisp appeal to me is because I don't like it when my hard work is wasted. It's pissy when you spend more time trying to circumvent their poorly conceived type system than you spend on the actual problem itself. I don't like it when my code is unnecessarily complex because of my tools.

calibraxis 16y ago

The author's work on fundamentally improving programming looks interesting: http://subtextual.org/ http://subtextual.org/

anthonyb 16y ago
Hmm, except that his first example is weird. He tries to rewrite all of his logic, instead of just putting an extra case at the top: if (b & c) { x = 3; elif (a) { ... which according to his methodology is an "overlap", and thus bad - but seems a lot clearer to me than his program's simplification: if (a & (!b | !c)) { x = 1; } else if (!a & ((b & !c)|(!b & c))) { x = 2; } etc... Ditto for the fibonacci stuff and his later examples. And they're pretty straightforward. For larger functions I can see it spiraling out of control.

mburney 16y ago

The compelling part about pg's lisp "triumphalism" is that he describes how lisp helped him build a better product and add/debug features faster. This author doesn't address that point -- he's talking about a kind of elitism that one would find in newsgroup flame wars. I (and many others) couldn't care less if a language makes me appear brilliant, but I do care about what advantage that language gives me. (EDIT: I wrote this comment before viewing the link to his previous post where he directly addresses the issue. Still wish he'd elaborate more though on how the abstraction level of a language would not help a programmer do better work. Is it enough to just proclaim "There are no super programming languages, only super programmers" for it to be true?)

mortenjorck 16y ago
I think the author is responding to the self-indulgent "Reddit clone in three lines of lisp!" variety of stunt-programming, where best practices, standards, and readability take a backseat to showing off how much hard-to-read compound logic you can cram into a single line of code. Honestly, I don't have a problem with those, as long as the practices involved in them don't seep into everyday programming.
tensor 16y ago
Still wish he'd elaborate more though on how the abstraction level of a language would not help a programmer do better work. Is it enough to just proclaim "There are no super programming languages, only super programmers" for it to be true?) This is trivially easy to disprove. C vs assembly. Java/C#/Python/Ruby/etc vs C and assembly. Manually creating databases in something like C for every application vs relational databases and SQL. I think it is painfully obvious that we have come a long way due to "triumphalism." Not all ideas bear fruit, but those that do can have a huge impact. His conclusion advocates that we should all simply program in assembly and use good practices. I feel that is an absurd notion.

DanielRibeiro 16y ago

Programming is an embarrassment compared to other fields of engineering and design. Our mainstream culture is one of adolescent self-indulgence Alan Kay made the same point in a interview with ACM: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523. He, much more eloquently, said: Once you have something that grows faster than education grows, you’re always going to get a pop culture. Fixing this is a much bigger issue. It in fact encompasses a lot of other areas, and they are no closer to solving it than computer science is (which was humorously cited to be a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia). Edit: As a side note, Eric Ries recently said on a Lean Startup talk we live in an era where ignorance is truely optional http://bit.ly/9v0XI6 http://bit.ly/9v0XI6 . The problem is that most people opt in.

strlen 16y ago

I agree that attitude trumps pure intelligence in general for programming projects. Indeed, pure intelligence tests (e.g., "why are manhole covers round?") fell out of favour as interview techniques at Microsoft. As far as I know (my own and friends' personal interview experience) Google never used such for programming interviews: ability to apply intelligence to the task at hand (programming, software engineering/architecture and algorithm/data-structure design) is what the industry leaders look for. This (the ability to strip away non-mathematical details and break a problem down to pieces that are machine-solvable, preferably by known and proven algorithms) in itself takes not just intelligence, but also practice. Nonetheless, there are some projects that require a minimal amount of intelligence and/or education and beyond that no amount of attitude can help. E.g., I'd love to hack on applications of machine learning algorithms, but I don't have the educational background to do so. It would require years of serious study to be able to even do even the most basic work in that field. On the topic of the author's previous post, I would agree that a way to get top programmers to work on less-interesting business applications is to let them use a more interesting language. In fact, some of the most difficult development (systems programming, scientific computing) goes on in fairly boring languages (although using higher level languages for this sort of work is becoming a reality). I will, however, take strong issue with the assertion that Common Lisp is a language only suitable to top percentile of programmers: countless schools teach Scheme as the first programming language to undergraduates and Scheme is a much more functional language than idiomatic Common Lisp. Macros aren't inherently related to functional programming (nor is writing your own macros required for Lisp hacking, Graham is fairly unique in this respect). Closures (a heavily used feature of Common Lisp) aren't inherently functional, neither are multiple dispatch nor dynamic typing. Lack of syntax is a salient feature, orthogonal to all other distinguishing features (except for macros) and again, not especially "functional". If it's possible for newbies to write fairly mind-bending Scheme(1), why shouldn't it be possible for educated and experienced (even if not 99.99th percentile aptitude-wise) programmers to do the same in a less pure language (Common Lisp, OCaml)? (1) My alma matter (which most people, even those living next to it, haven't heard of) uses Haskell: http://www.cse.scu.edu/~atkinson/teaching/wi10/070/ http://www.cse.scu.edu/~atkinson/teaching/wi10/070/

ckuehne 16y ago
Just to clarify: "why are manhole covers round?" is not a test of intelligence in the narrower sense. "Add the next number in the following sequence 1,4,9,16" is.

bloopybloppy 16y ago

Why is clever programming always associated with some awful monstrous unmaintainable implementation? Being clever shouldn't mean that you're hacking things together ad-hoc just to make it work. On the contrary, that is the opposite of being clever. I really doubt that most of the bad code is written by "clever" programmers. Other factors are at play here.

kragen 16y ago
Hacking things together ad-hoc just to make it work isn't the way that clever programmers produce awful monstrous unmaintainable implementations. That's the way un-clever programmers do. Clever programmers, instead, invest lots of time into reinventing things that don't need reinventing, and then must be learned by those who come after them; and implementing things that don't need to be reimplemented. Reams of copy-pasted code is not the affliction of the clever programmer. Instead, you discover that there's a strategy factory to instantiate a strategy that chooses which home-grown database abstraction layer to use and what kind of caching to apply to it; and that there's a home-grown template library on top of that, with its own caching layer. And it's all configured with a plugin system that uses a bunch of XML metadata files for each plugin — all in order to run a message board.

rmundo 16y ago

There is a subfield of programming that feels pretty grown-up: mission critical applications where a bug can cost you a multi-million dollar spacecraft or a plane-load of human lives. The pace of innovation can feel glacial, safety("has this been done before, is it reliable") is valued above "brilliance", and the whole process with its checks and tests and paperwork can feel stifling, but it produces complex code that works(most of the time). I wonder if this is a local maxima, though, and if there are more effective ways to produce rock-solid, high performance code. I'd love to see how SpaceX produce their code, for instance.

cookiecaper 16y ago

Like most other attributes, attitude and intelligence need to be considered with the whole. You can have a great attitude and no intelligence, but that won't get you anywhere, and neither will extreme intelligence and a bad attitude. Of course, every programmer needs a mix of attitude and intelligence to be effective. For my part, I'd rather hire an average programmer with a good attitude than an excellent programmer with a bad attitude; clock cycles are much cheaper than the friction caused by a rogue developer.

jergosh 16y ago

I love how "What a load of self-indulgent adolescent crap." can by juxtaposed with his 'About me' photo: http://subtextual.org/AboutMe.htm http://subtextual.org/AboutMe.htm

yason 16y ago

They're both needed, of course: 1) Intelligence steers hard work to the right direction. 2) Hard work turns intelligence into reality.

j_baker 16y ago

I see the author's trump card and play the von Manstein card! "There are only four types of officer. First, there are the lazy, stupid ones. Leave them alone, they do no harm…Second, there are the hard-working, intelligent ones. They make excellent staff officers, ensuring that every detail is properly considered. Third, there are the hard-working, stupid ones. These people are a menace and must be fired at once. They create irrelevant work for everybody. Finally, there are the intelligent, lazy ones. They are suited for the highest office." This seems pretty relevant. Attitude is important to being good, but it inhibits you from becoming great. Likewise, attitude is a requirement to be terrible.

deleted 16y ago

[deleted]

losethos 16y ago

This makes me feel the same way as when a boss said he'd rather be lucky then have skill.