
Programming: Attitude Trumps Intelligence - malbiniak
http://alarmingdevelopment.org/?p=422
======
jwecker
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.

~~~
bh23ha
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
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.

------
abstractbill
_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.

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

------
klochner
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
Yes, in which he claims that all languages are equally good. In which case I
assume he writes everything in assembler.

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

~~~
arethuza
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
_The Humble Programmer_ (Dijkstra's Turing Award lecture)
[http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD...](http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

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.

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

~~~
sdevlin
Yeah, you can simulate that stuff with lambdas. For that matter, you can
simulate function calls by following conventions in assembly language. That's
what I meant by "awkward/difficult". Surely you'd concede that you're happy to
have syntactic support for if-statements and lambdas?

Given that, it's not a stretch to imagine that syntax could be useful in other
scenarios.

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

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

~~~
tensor
_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.

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

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

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

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

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

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

~~~
abstractbill
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.

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

~~~
anthonyb
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.

------
DanielRibeiro
_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.

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

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

------
yason
They're both needed, of course:

1) Intelligence steers hard work to the right direction.

2) Hard work turns intelligence into reality.

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

------
bh23ha
_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.

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

