Programming: Attitude Trumps Intelligence
alarmingdevelopment.org
alarmingdevelopment.org
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.
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).
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)?
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.
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? :\
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. :)
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.
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.
A smarter language will make debugging easier. Smarter code will usually do the opposite.
You realize the title of TFA is "Mea Culpa", right? The "link bait" headline was written by the HN submitter.
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.
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.
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.
(Actually, I find reading AMOP a bit humbling, which is why I keep it lying around my desk at home).
You know where we are :)
Sounds like the author is having trouble with the humility thing:
"I'm really humble, so now everyone else has to be as well"
"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?"
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.
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 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...
Given that, it's not a stretch to imagine that syntax could be useful in other scenarios.
It's nevertheless fairly common, and it's usually called a "filesystem".
I disagree. It's not only elegant but is the way it should be.
"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.
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?)
Honestly, I don't have a problem with those, as long as the practices involved in them don't seep into everyday programming.
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.
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.
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.
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/
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.
For robust, maintainable software systems, convention and simplicity trump cleverness.
Cleverness gets you things like Garbage Collection. Convention and simplicity leaves us all using assembler because there's no need for "clever" language features.
if (b & c) {
x = 3;
elif (a) {
...
if (a & (!b | !c)) {
x = 1;
} else if (!a & ((b & !c)|(!b & c))) {
x = 2;
} etc...
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.
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.
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.
1) Intelligence steers hard work to the right direction.
2) Hard work turns intelligence into reality.
I am tempted to tattoo this on... somebody.