Programming: Attitude Trumps Intelligence(alarmingdevelopment.org)
alarmingdevelopment.org
Programming: Attitude Trumps Intelligence
http://alarmingdevelopment.org/?p=422
66 comments
Glorifying "hard work" as more important than intelligence is a common mistake made by intelligent people when they finally realize that sitting around being intelligent is not, in fact, sufficient to make things happen (this is often surprisingly contrary to expectations formed during schooling).
I think intelligence and attitude are both multipliers. The difference is, if you glorify attitude (to yourself) it can help you improve your attitude. Glorifying intelligence won't improve your intelligence so easily.
[deleted]
However, we programmers must fight egotism and arrogance. The danger is that in forgetting that we are fallible and were new programmers once, we commit a grave error. We're all shortsighted at one time, or another--unless we fall prey to egotism.
Nicely put.
Agreed—I've known too many of the former, who undo years of quality work in a single, well-meaning but unintelligent rewrite.
I think the author is confusing the Real Thing with the hubris-laden, self-proclaimed intelligent programmer. Programming is one of the tiny handful of fields where real intelligence (plus hard work) puts you at a significant advantage over the eager-but-average-intelligence hard-workers.
Programming is like writing or other arts in so many ways: it's easy for those who are competent to immediately recognize another gifted thinker, but the have-nots will dismiss the gifted work as "unintelligible" simply because they don't have the skill or capacity to appreciate it yet (Dunning-Kruger Effect).
I think the author is confusing the Real Thing with the hubris-laden, self-proclaimed intelligent programmer. Programming is one of the tiny handful of fields where real intelligence (plus hard work) puts you at a significant advantage over the eager-but-average-intelligence hard-workers.
Programming is like writing or other arts in so many ways: it's easy for those who are competent to immediately recognize another gifted thinker, but the have-nots will dismiss the gifted work as "unintelligible" simply because they don't have the skill or capacity to appreciate it yet (Dunning-Kruger Effect).
And if you work in heterogeneous teams you are just proving the author's point.
If the gifted code is unintelligible to the less skilled how can a team work? Immediately you have the problem of the less skilled not being able to follow the code pratices of the gifted coder, it will be harder to reuse. And the when somebody else has to extend it will cost a lot more time, or to correct something.
Surely some parts of code should be clever, sometimes it has to be clever because there are no alternatives. It should always be somehow well contained. But if you start evaluating code <i>per se</i> you surely end with a bad compromise.
Isn't this obvious to everybody who has to lead a team(I don't)?
If the gifted code is unintelligible to the less skilled how can a team work? Immediately you have the problem of the less skilled not being able to follow the code pratices of the gifted coder, it will be harder to reuse. And the when somebody else has to extend it will cost a lot more time, or to correct something.
Surely some parts of code should be clever, sometimes it has to be clever because there are no alternatives. It should always be somehow well contained. But if you start evaluating code <i>per se</i> you surely end with a bad compromise.
Isn't this obvious to everybody who has to lead a team(I don't)?
I'm not talking about writing the "clever code" that nobody understands (including the coder 6 months afterward)—that's a symptom of the hubris-laden self-proclaimed intelligent programmer the original author is confused about. A genuinely intelligent programmer might early in his career write that esoteric crap as well, but soon learns that nobody—including himself—can understand it after a while. And that is the difference: the intelligent programmer stops doing that immediately while the pseudo-intelligent guy can't stop himself, worlds without end.
I've been in a variety of shops over the past 20 years or so where new kids come in, thinking they're all that and a bag of chips, and systematically replace smart, well-engineered, and working modules with their new ones that will now take years to become as robust, and never be half as elegant.
They do this because they won't take an afternoon to spend the time to read and understand the original code.
Intelligence isn't wholly a matter of genetics—some of these earnest kids do eventually learn better in spite of their natures. They spend enough time with the real good guys to figure out they're not one of them, and then they start trying to figure out why. The fakes go on for years and years writing the worst stuff imaginable and even after shown direct evidence of their incompetency will refuse to reclassify themselves. They start getting defensive, paranoid, thinking they're the poor misunderstood artist. Whatever.
Coders who aren't willing to get into someone else's code to see the "whys" beyond the "hows" are the people I specifically exclude from my projects.
I've been in a variety of shops over the past 20 years or so where new kids come in, thinking they're all that and a bag of chips, and systematically replace smart, well-engineered, and working modules with their new ones that will now take years to become as robust, and never be half as elegant.
They do this because they won't take an afternoon to spend the time to read and understand the original code.
Intelligence isn't wholly a matter of genetics—some of these earnest kids do eventually learn better in spite of their natures. They spend enough time with the real good guys to figure out they're not one of them, and then they start trying to figure out why. The fakes go on for years and years writing the worst stuff imaginable and even after shown direct evidence of their incompetency will refuse to reclassify themselves. They start getting defensive, paranoid, thinking they're the poor misunderstood artist. Whatever.
Coders who aren't willing to get into someone else's code to see the "whys" beyond the "hows" are the people I specifically exclude from my projects.
Are humans not capable of enlightenment or are we too far gone in the "me too" era to think for ourselves and learn from others?
Being around a better programmer will rub off on you even if you aren't as intelligent. Intelligence isn't a hard metric you can rely upon in my experience. Otherwise intelligent people have made amazingly stupid mistakes on more than one occassion. Intelligence is only useful if you have the intuition to realize just how little you know.
Being around a better programmer will rub off on you even if you aren't as intelligent. Intelligence isn't a hard metric you can rely upon in my experience. Otherwise intelligent people have made amazingly stupid mistakes on more than one occassion. Intelligence is only useful if you have the intuition to realize just how little you know.
I agree completely but that shouldn't drive the way a team works.
If the convention says that the code should be as clever as it could be you will have problems. If your tech lead acknowledges some limitations on the team he will have to compromise cleverness for simplicity. And everybody will still learn.
I can't see why my first comment was downmodded, and it's happening for my last comments, confusing or bad grammar? :\
If the convention says that the code should be as clever as it could be you will have problems. If your tech lead acknowledges some limitations on the team he will have to compromise cleverness for simplicity. And everybody will still learn.
I can't see why my first comment was downmodded, and it's happening for my last comments, confusing or bad grammar? :\
I don't think clever code implies obfuscated or difficult to read code.
Some of the most clever code I've read is conscious of when it breaks from convention.
Any intelligent person will unconsciously understand conventions and recognize their importance. They will also possess an intuition of when those conventions should be ignored, changed, or removed entirely. This is a part of skill acquisition they should be able to pass on to others in your team.
Overly strict adherence to convention only insures that the least-capable person on your team can contribute. Subsequently that person will never be encouraged to improve their skills. Blindly following convention says to me that you're willing to accept inefficiencies and poor design choices for the sake of maintainability by your least competent team member.
You need a mix; the most competent at the top to lead the least competent. Ideally everyone becomes the most competent at some point. Generally you will have people at various points on the ladder. This is a good thing.
We don't need egalitarian dogma ruffling with the food-chain. It's a pretty good system in many cases. :)
Some of the most clever code I've read is conscious of when it breaks from convention.
Any intelligent person will unconsciously understand conventions and recognize their importance. They will also possess an intuition of when those conventions should be ignored, changed, or removed entirely. This is a part of skill acquisition they should be able to pass on to others in your team.
Overly strict adherence to convention only insures that the least-capable person on your team can contribute. Subsequently that person will never be encouraged to improve their skills. Blindly following convention says to me that you're willing to accept inefficiencies and poor design choices for the sake of maintainability by your least competent team member.
You need a mix; the most competent at the top to lead the least competent. Ideally everyone becomes the most competent at some point. Generally you will have people at various points on the ladder. This is a good thing.
We don't need egalitarian dogma ruffling with the food-chain. It's a pretty good system in many cases. :)
That's not the way I read it. It seems to me what he meant to say is that, no matter how good and smart you are - software can outsmart you.
Or in other words, debugging code is twice as hard as writing code, so if you write the smartest code you can, you will not be able to debug it.
But having said that, I do think that the headline is link bait. I only agree with it if you add: "On very large, long term projects".
For the release often and early and start-up crowd, smart and fast is probably better then disciplined and maintainable.
Or in other words, debugging code is twice as hard as writing code, so if you write the smartest code you can, you will not be able to debug it.
But having said that, I do think that the headline is link bait. I only agree with it if you add: "On very large, long term projects".
For the release often and early and start-up crowd, smart and fast is probably better then disciplined and maintainable.
Right. And his mistake is in equating smart languages with smart code.
A smarter language will make debugging easier. Smarter code will usually do the opposite.
A smarter language will make debugging easier. Smarter code will usually do the opposite.
> But having said that, I do think that the headline is link bait
You realize the title of TFA is "Mea Culpa", right? The "link bait" headline was written by the HN submitter.
You realize the title of TFA is "Mea Culpa", right? The "link bait" headline was written by the HN submitter.
I find that 'intelligent programmers' tend to write better code than 'programmers with intelligence'.
e.g. 'programmers with intelligence' can handle a lot of complexity and need to refactor a lot less, and thus can write messy code and get away with it.
'Intelligent programmers' understand that refactoring is essential and that clearly written, well structured code makes it easy to work with, and far less taxing on the brain.
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.
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.
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.
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.
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.
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).
(Actually, I find reading AMOP a bit humbling, which is why I keep it lying around my desk at home).
clojure.org
You know where we are :)
You know where we are :)
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.
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.
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:
Sounds like the author is having trouble with the humility thing:
"I'm really humble, so now everyone else has to be as well"
Yes, in which he claims that all languages are equally good. In which case I assume he writes everything in assembler.
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?"
"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?"
... or Visual Basic... or COBOL... or any other language everyone has pretty much determined is awful.
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.
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.
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.
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.
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.
> 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".
It's nevertheless fairly common, and it's usually called a "filesystem".
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...).
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.
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...
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...
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.
Given that, it's not a stretch to imagine that syntax could be useful in other scenarios.
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.
I disagree. It's not only elegant but is the way it should be.
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.
"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.
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?)
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?)
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.
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.
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.
Honestly, I don't have a problem with those, as long as the practices involved in them don't seep into everyday programming.
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.
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.
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.
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.
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.
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/
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/
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.
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.
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.
He maybe overstepped a little, but the principle is sound:
For robust, maintainable software systems, convention and simplicity trump cleverness.
For robust, maintainable software systems, convention and simplicity trump cleverness.
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.
Cleverness gets you things like Garbage Collection. Convention and simplicity leaves us all using assembler because there's no need for "clever" language features.
In my experience, writing simple code often requires more cleverness from the programmer than does writing clever code.
It's vague enough that the principle is both sound and useless.
The author's work on fundamentally improving programming looks interesting:
http://subtextual.org/
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) {
...
if (a & (!b | !c)) {
x = 1;
} else if (!a & ((b & !c)|(!b & c))) {
x = 2;
} etc...
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.
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.
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.
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.
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.
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.
[deleted]
They're both needed, of course:
1) Intelligence steers hard work to the right direction.
2) Hard work turns intelligence into reality.
1) Intelligence steers hard work to the right direction.
2) Hard work turns intelligence into reality.
I love how "What a load of self-indulgent adolescent crap." can by juxtaposed with his 'About me' photo: http://subtextual.org/AboutMe.htm
[deleted]
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.
I am tempted to tattoo this on... somebody.
[deleted]
One last thought to bare in mind before disagreeing: http://www.savagechickens.com/2008/12/iq-test.html
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.