Programming: Attitude Trumps Intelligence

by malbiniak • 16 years ago

170 60 16 years ago

Jach• 16 years ago

Ha, as if attitude resides in something other than the brain. 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.

klochner2• 16 years ago

He maybe overstepped a little, but the principle is sound:

For robust, maintainable software systems, convention and simplicity trump cleverness.

benatkin• 16 years ago

It's vague enough that the principle is both sound and useless.

abstractbill4• 16 years 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.

camccann2• 16 years ago

In my experience, writing simple code often requires more cleverness from the programmer than does writing clever code.

jwecker• 16 years 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.

scottw2• 16 years 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).

jacabado3• 16 years 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)?

bh23ha2• 16 years 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.

abstractbill4• 16 years 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• 16 years 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.

camccann2• 16 years 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• 16 years 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.

nellboy• 16 years 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.

oconnore• 16 years 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.

kenjackson2• 16 years 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...).

sdevlin2• 16 years 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.

kragen2• 16 years 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.

It's nevertheless fairly common, and it's usually called a "filesystem".

david927• 16 years ago

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

I disagree. It's not only elegant but is the way it should be.

abstractbill4• 16 years 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• 16 years 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• 16 years 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• 16 years 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.

arethuza3• 16 years ago

I look forward to "The Meta Object Protocol for Dummies" and "CLOS in 21 Days".

(Actually, I find reading AMOP a bit humbling, which is why I keep it lying around my desk at home).

francoisdevlin• 16 years ago

clojure.org

You know where we are :)

getonit• 16 years ago

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

klochner2• 16 years 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

abstractbill4• 16 years ago

Yes, in which he claims that all languages are equally good. In which case I assume he writes everything in assembler.

anthonyb2• 16 years 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• 16 years ago

... or Visual Basic... or COBOL... or any other language everyone has pretty much determined is awful.

10ren• 16 years ago

The Humble Programmer (Dijkstra's Turing Award lecture) 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.

bh23ha2• 16 years 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• 16 years 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• 16 years ago

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

anthonyb2• 16 years 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• 16 years 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• 16 years 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• 16 years 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• 16 years 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. 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 . The problem is that most people opt in.

strlen• 16 years 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/

ckuehne• 16 years 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.

jacquesm• 16 years ago

42?

jacabado3• 16 years ago

18 ?

arethuza3• 16 years ago

Clearly the answer is "1", the sequence being defined as the numbers 1,4,9 and 16 repeated.

bloopybloppy• 16 years 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.

kragen2• 16 years 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• 16 years 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• 16 years 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• 16 years 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

yason• 16 years 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• 16 years 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.

Programming: Attitude Trumps Intelligence

Related Stories