Comfort with meaninglessness the key to good programmers

Discuss

90 Responses to “Comfort with meaninglessness the key to good programmers”

  1. t3knomanser says:

    @Zuzu(#43): I hate manually managing threads. The first thing I did when I needed to write a threaded application was write a class that hid all the details and I just reuse that everywhere. It only works for simple cases of multithreading, but that’s the majority of cases I run into.

    I haven’t manually managed memory in a very long time. I did some ObjectiveC, so I had to manage retain/release calls, which isn’t exactly managing memory. Not exactly, but it’s pretty close- a half step between manual and garbage collected memory.

    I’m sadly stuck in the .NET world, and I’m trying desperately to get my employer to see the benefit of declarative persistence through something like NHibernate. The reply is, “The next version of .NET has LINQ. That’s the same thing.”

    It isn’t, but at least it’s better than what we’ve got now. *sigh*

  2. techdeviant says:

    For me, learning a programming language has always been more like learning a foreign language than learning math.

    There are intricacies and weird syntax that you might not understand but it doesn’t matter – this is just the way it is done (so many programmers I’ve met just don’t understand that.) There are multiple ways to do the same thing, but as a skilled programmer [or foreign language speaker] you need to find the most concise and easiest to understand path.

  3. yish says:

    There are 10 kind of people. those who get binary and those who don’t.

  4. techdeviant says:

    @nprnncbl

    Apparently, the researchers have discovered that there actually 11 kinds of people, and not 10, as previously believed.

    nice :)

  5. fnc says:

    Try working with digital artists and all of this will be thrown into ~very~ sharp relief.

  6. GregLondon says:

    Uh, someone figured out that programming requires some relationship with the concept of meaningless a long time ago. A famous sign posted over an old terminal long ago said:

    “I really hate this damn machine,
    I wish that they would sell it.
    It never does what I want,
    but only what I tell it.”

    Getting “meaningless” means getting that what you want and what you say can be two different things. And the computer will do exactly what you say, which isn’t always what you want.

    But if you try sometimes, you get what you need.

  7. Anonymous says:

    “Other students, who hadn’t read the Time-Life Science Library or some similar grade school library book might have done less well. There’s got to be a strong correlation between reading library books like that in grade school and being capable of understanding computer programming.”

    This is meaningless, because you are defining the program compilation using your known language – math.

    The programming language could just as easily compile that a = b as both being 10. Or both returning 0 because it’s an invalid line (constants can’t be assigned to each other. You don’t even know they are CONSTANTS). Or maybe they’re 10 and 20 still respectively. You don’t know the rules of the language, and they aren’t given, so you ASSUME and fall back upon, the previous world of mathematics.

    As poster #8 clearly stated, it’s about order of operations.

    Since this has no frame of reference (ie, language, rules, ect), this test is MEANINGLESS, hence the title. So there is no “better” answer, only an answer you can justify. And you can justify many answers many different ways. Applying that justification across multiple answers is what the test was searching for (thus the categories).

  8. callingshotgun says:

    Finding meaning in programming… Heh, that reminds me of jesux: http://www.geocities.com/ResearchTriangle/Node/4081/

  9. GregLondon says:

    tech: For me, learning a programming language has always been more like learning a foreign language than learning math.

    Probably because when you’re learning french, people who speak french can figure out what you meant, regardless of what you actually said.

    If Alice only speaks English and Bob only speaks Incan, and then Alice and Bob both study Japanese for a day, when they try to talk to each other, the experience might not be unlike programming.

    Neither one will know Japanese well enough to extract meaning from what the other says. Unless the other person says something exactly right, the intended meaning may be lost.

  10. Anonymous says:

    Very interesting, but I don’t know why the results are surprising either, or why the programmers didn’t guess the consistent group.

    My first thought on reading the three groups was, “ah, the consistent group will make good programmers, because they have the tenacity and determination to try and apply a consistent ordering to the system.”

    That to me is the key to what makes a good programmer… tenacity. The attitude of “well I don’t understand this yet, but screw it, I have the confidence in myself to push forward anyway”.

    The people who didn’t answer at all are afraid of making mistakes, and will be the type who will always be asking for help from senior devs, instead of forging ahead on their own.

    The inconsistent group just simply don’t have the right mindset for programming… or they will become spaghetti programmers. ;)

    (For the record, I’m a senior developer, who taught myself to code at about 7.)

  11. philoponia says:

    The correct answer is actually ALL OF THE ABOVE.

    For those of you who have taken a basic concepts of mathematics course, what we have done here is describe a mathematical theory where 10=20 by axiom, which means that 0=1. It can be shown from there that 30=0, 30=20, 20=0, and all the other answers.

    So even though there was not supposed to be any truly correct answer, any friend of math could totally pwn the Prof.

    axiom: a=10
    axiom: b=20
    axiom: a=b

    Since a=b
    Then (a-10)/10=(b-10)/10
    Therefore 0=1
    Let c=30
    Then 0*c=1*c
    Therefore 0=30 QED
    Also 0*a=1*a
    So 0=10
    Then 0+b=10+b
    Therefore 20=30 QED

    ALL OF THE ABOVE

  12. Anonymous says:

    In the context of the example, there’s no reason to assume assignment is left right or right left or even allowed (a compiler is its own state machine that gets fed a program like a = b). 10 could be interpreted as a 2 bit binary number and 20 as an integer based on arbitrary rules of the state machine, while “int” might be a softly typed (can be 2bit binary or integer) variable label. The correct answer is, YOU CAN’T KNOW (with the information provided).

  13. Anonymous says:

    20 20 ?

  14. wkiernan says:

    Maybe it’s just that one question, but as a college freshman I’d certainly have answered that as a = 20 and b = 20, not because my brain has this structure as opposed to that, but because when I was in grade school, I read the Time-Life Science Library volume on Mathematics, which spelled the idea of assigning values to named variables out for me in words and pictures.

    Other students, who hadn’t read the Time-Life Science Library or some similar grade school library book might have done less well. There’s got to be a strong correlation between reading library books like that in grade school and being capable of understanding computer programming.

  15. sabik says:

    Of course, there’s interpretation B: there’s a single, fundamental concept in programming that nobody ever teaches. Those who happen to already know it succeed, the others fail.

    This would also tend to be self-perpetuating: only those who didn’t need to be taught the concept succeed to become programming teachers, so they do not think of it as something that needs to be taught (nor do they have a model for how to teach it).

    Semi-testable consequence: once this concept can be isolated, verbalised and taught, success in programming courses will rise.

  16. gebloom says:

    Seems to me that they defined not programming aptitude, but autism. There’s research to suggest that there is some dovetailing of technology workers and the autistic spectrum, but that doesn’t mean that further research won’t show that a variety of cognitive abilities can result in programming aptitude.

  17. bardfinn says:

    nprnncbl:

    I’m employed in a DBA role, shared with others. Consistency of input and consistency of code expression are very highly ranked skillsets for our role; Probably 90% of my time and 90% of the code I write is spent hunting down and flattening bugs caused by inconsistency of expression, from input data to query statements.

  18. zuzu says:

    Imperative stateful programming, yuck! Of course that’s confusing (unless you’ve already been indoctrinated) compared to the single-assignment of asynchronous message-passing concurrency programming, such as with Erlang.

    :p

    c.f. A Small Matter of Programming by Bonnie A. Nardi.

  19. noahpoah says:

    But method X/language Y is so intuitive that it solves this problem, iff ( X == trial & error ) & (Y == Scheme | Perl )!

  20. klenow says:

    “Very few, so far, have predicted that the consistent group would be the most successful. Remarkably, it is the consistent group, and almost exclusively the consistent group, that is successful.”

    I’m not a programmer, so maybe this is just my naivte…but this doesn’t make any sense to me. Why would someone predict anything other than the consistent group? I can see the blank group, at least the explanation makes some sense (not much, but some).

    Why is it remarkable that the consistent group would be the highest performers? Do computers not work by consistent rules?

  21. Anonymous says:

    Of course then there are the quality control types like me who would just shake their heads and tell the tester what a ridiculously bad way to write a program that is, and where the heck are the comments on what this program is supposed to do, and where are the design specs, etc, etc…

  22. Chrs says:

    Sorry to show my ignorance here, but which of the options is correct in the first one? I’m guessing that the answer will be clear in hindsight, but I’m too impatient to look up the programming language properly.

  23. ricket says:

    I tend to think that “comfort with meaninglessness” is a critical skill for all people in science. You have to be adept and comfortable with not always knowing “the answer”, knowing that later it will come. I can always spot a non-science/non-math person a mile away in that they don’t have this skill.

  24. t3knomanser says:

    That puts a fine point on something I always tried to communicate when I used to teach programming.

    It’s like order of operations.
    2 + 7 * 9 = 81 is perfectly valid. We just defined an order of operations that says multiplication goes first. It really doesn’t matter, so long as everyone agrees to evaluate these statements the same way. Since the consensus is that multiplication should go first, we instead say that the right answer is 65.

    The secret ingredient to a good programmer is someone who is aggressive about simplifying things. Consistent rules are more simple than inconsistent ones.

    Here’s the thing though: it’s harder to be simple and concise than it is to be complex and verbose. It takes more time and more effort to cut things down and define consistent rules.

    Try prying requirements out of a customer. I used to tell students, “They honestly don’t know what they want,” which is uncharitable. They know what they want, but they don’t know how to describe it in clear, simple terms.

  25. Xeno says:

    @BARDFINN

    I sympathize. I do DBA, sys administration and development for my company (triple threat) and I have had to redesign all their systems to as they did not have standards in place for anything.

    A classic example is their CITYSTATEZIP field in their existing database which store three data types in various degrees of conforming standards. Some of the data is their, some of the data is not, some of the data is foreign and doesn’t conform to united states formats.

    Consistency is VERY important but you cannot guarantee that humans will be consistent so you have to force consistency down their throats by limiting their options much like forcing a rat down a maze; he can only choose left or right when he comes to a fork and you have limited his options through his environment.

  26. kyuzo says:

    #1 I think you’ve solved it.

    #5 Haha! That’s great, I wonder it it would be possible to find an xkcd strip that relates to each and every boing boing post as they are published…

  27. t3knomanser says:

    @CHRS: It’s a C flavored language doing simple assignment. The correct answer is a = 20, b = 20.

  28. GregLondon says:

    The correct answer is actually ALL OF THE ABOVE. For those of you who have taken a basic concepts of mathematics course,

    Except this isn’t a math course, this is a programming course, and programs are executed in sequence, whereas mathematical statements are always true.

    Which should point to the fundamental difference between math and programming. Math is about getting fundamental truths. Programming is about getting something that works.

  29. zuzu says:

    Assuming it’s C, because it sure looks like it:

    The variable “a” is being defined as an integer data type and assigned the value of “10″.

    The variable “b” is being defined as an integer data type and assigned the value of “20″.

    Now what’s weird is that unlike in algebra, “a = b” means that the variable “a” is from that moment on assigned whatever value “b” held at that time (in this case, “20″).

    There’s no way to know that “a” used to hold “10″, but “a” will retain the value of “20″ even while “b” may also be reassigned to a different value later. Having to keep track of this program state in your head is why bugs and crashes occur.

    Single assignment is far more… consistent. ^_^

  30. t3knomanser says:

    @Zuzu: Prolog doesn’t do single-assignment, but (ignoring unification) program state shouldn’t change.

    It’s a weird approach to programming, where you mutate your state objects as local, single-assignment variables then pass them recursively back to your program for the next round of changes.

  31. arkizzle says:

    Zu, but then it wouldn’t be a variable, no?

  32. Anonymous says:

    So the result is that the most machine-like thinkers will understand machine “thinking” the best?

    I can back this up with my anecdotal evidence:

    If you know the basic theories in most classes, unless the professor specifically designs the questions to use more math than you can do during the question period, you can usually brute force the answer to a CS question.

    For instance: floating point. You can use their tricky formulas… or you can just count. (Mileage may vary with fractional values.)

  33. ColorfulNumbers says:

    SAMSAM: “As a programmer, I’m surprised by the finding that programmers thought that those who didn’t answer would be the best programmers. This is absurd to me.”

    I agree. If a test is multiple choice, and you have no idea what the correct answer is, isn’t any guess better than leaving a blank answer? I couldn’t tell if testers were “penalized” (or told they would be penalized) more for blank answers than wrong ones. I would be tempted to assume the “blank” answer students were simply despairing, rather than righteously protesting a “trick question.”

    (To be fair, the ambiguity is part of the test, and the test-givers cannot explain ambiguous questions.)

    It’s a fine thing to refuse to answer out of pride, but it makes for a pretty poor test-taking technique.

    Do bad test-takers make good programmers?

    CHRS and others:

    The assignment operator is not actually consistent from language to language. Currently, “C” style operators are in fashion: “=” denotes assignment, “==” is an equivalency test.

    But, in Pascal, “=” is the equivalency test.

    The Pascal symbol for assignment is “:=”, which is meant to look like the left-pointing arrow from mathematics. APL (which does not use the ASCII character set) uses an actual left-arrow symbol.

    BASIC uses “=” for BOTH.

    For others, see Assignment (computer science) on Wikipedia.

  34. jdfreivald says:

    @Sabik, I don’t think that’s “interpretation B”, i.e., something different from what they’ve shown. The single, fundamental concept is probably exactly what they’ve identified: meaninglessness.

    The semantics we use are just a convenient mnemonic understanding for the way your keystrokes will be translated into mindless and meaningless movements of electrons in silicon. You have to grok that. When you forget it — when you say, “But [Expression] means blah blah blah, so that code block must be right…” — you’ve stopped looking for the stupid mindless misplaced semicolon that’s mucking up the works.

    Assembly language programming really helps drive that concept home. It’s about as close as you can get to ones and zeros without crossing the line; however, even then you should keep in mind that computers don’t really use ones and zeros at all, because there’s no inherent meaning in an electron that makes it a “one” rather than a “zero”.

  35. zuzu says:

    Here’s the thing though: it’s harder to be simple and concise than it is to be complex and verbose. It takes more time and more effort to cut things down and define consistent rules.

    “I apologize for the length of this letter. I didn’t have time to write a short one.”

    (or some permutation thereof)

  36. t3knomanser says:

    @Arkizzle: It varies between two states. Uninitialized and initialized.

  37. Anonymous says:

    That xkcd comic and the article (to a degree) remind me of this joke:

    There was an engineer, manager and programmer driving down a steep mountain road.

    The brakes failed and the car careened down the road out of control.

    Half way down the driver managed to stop the car by running it against the embankment narrowing avoiding going over a cliff.

    They all got out, shaken by their narrow escape from death, but otherwise unharmed.

    The manager said “To fix this problem we need to organize a committee, have meetings, and through a process of continuous improvement, develop a solution.”

    The engineer said “No, that would take too long. Besides that never worked before. I have my trusty pen knife here and will take apart the brake system, isolate the problem and correct it.”

    The programmer said “I think you’re both wrong! I think we should all push the car back up the hill and see if it happens again.”

  38. LB says:

    Programming isn’t exactly like math, is it?

  39. RevEng says:

    @#1: That was the first thing I was thinking while going through this. What we really have is three groups of people: those who know what to do, those who don’t know and fumble along aimlessly, and those who don’t know and refuse to answer a question they don’t understand. This seems like a much more general observation that can be made of any group of people asked to solve a series of problems.

    @#7: In many ways, they probably don’t know what they want. They know they want a solution to their problem, but they usually don’t understand what a correct solution entails and they likely don’t even understand the problem.

    While I deeply question the hypothesis these researches came up with, and its meaningfulness without verification experiments, as a programmer I can agree with their belief on the key to programming. The hardest thing to teach and to remember is that for all of their sophistication, computers are stupid. They blindly follow what they are told, even if you meant something else. They don’t know that a byte represents a number, a letter, or a pixel — it’s just a number that needs to be manipulated.

    Even harder to wrap your head around is the idea that they have to be taught even the simplest of operations: even something as simple as “insert this letter here” must be broken down into a series of smaller operations.

    I think the thing that really makes programming difficult for newcomers is that we use mathematical notation, but don’t follow all of maths’ rules. For example, we’ve been taught in math that A=B means A and B always share the same value (it’s a logical rule, not an imperative statement). It’s no surprise then that students misunderstand what a computer will do with the given code snippet. They apply the rules they’ve been taught before, in years of mathematics classes, and they come to the wrong conclusion because computers (or at least programming languages) don’t follow mathematical rules (which is completely counterintuitive). Would a different notation help? Probably not, since there’s no standard notation for assignment, and in any case the copy-and-overwrite mechanism of an assignment is unique to computing. The best you can hope is to choose a unique symbol which nobody will confuse with something they already understand.

  40. bardfinn says:

    LB: Programming is very much like math.

    I would like to see work done on distinguishing between a deep comfort with meaninglessness, and a deep dislike of inconsistency. The inconsistent way in which most people use the term “meaning” discomforts me.

  41. cshirky says:

    LB, depends on the level of abstraction. Up where the users are, no, its not exactly like math, but down where the silicon, yes, it is exactly like math.

  42. SeattlePete says:

    @#7 TEKNO…

    “2 + 7 * 9 = 81 is perfectly valid.”

    And as a MUMPS programmer (http://en.wikipedia.org/wiki/MUMPS), I see this as being correct.

    “The secret ingredient to a good programmer is someone who is aggressive about simplifying things.”

    Isn’t the simplest way to to process 2+7*9 a strict left-to-right interpretation? Maybe I’m contaminated by an ancient language, but jumping to 7*9 first and then going back to +2 isn’t intuitive. 2+(7*9) and you might have something there…

  43. FoetusNail says:

    There is no such thing as math.

  44. greebo says:

    Clay – you disappoint me – you didn’t do your homework on this one. Did you notice that Dehnadi and Bornat never managed to publish this work? Turns out it’s a deeply flawed study. Our research group set out to replicate the their original study. None of their results hold up. Several other groups round the world who also attempted a replication also found there to be no correlation.

    You can read about our adventures trying to replicate the study in a paper that was published, in this year’s international conference on software engineering:
    http://www.cs.toronto.edu/~sme/papers/2008/Lung-ICSE2008.pdf

  45. Anonymous says:

    Programming is all Greek to me, but the study is still interesting. It reflects our tendency to persist in certain heuristics even in the face of situations where those heuristics do not apply.

    It’s fundamentally similar to learning to ride a motorcycle. If you’ve driven a manual shift car all your life, you’re going to have trouble learning how to shift on a bike. But if you have no idea how to shift a car, you will learn the motorcycle’s method much more quickly, because you have no heuristic to break through, first.

    It’s the fine line between status quo and innovation. Once we learn how to do things a certain way, we tend to want to settle into that. We build our confidence around that. But to be ignorant of something and still be confident enough to admit to this ignorance defines, I think, a person as a perfect candidate to learn innovative new methods. Because a mind that can admit when they don’t know can also search more honestly for innovative new answers and methods.

  46. Anonymous says:

    @54 Philoponia:

    Your conclusion is correct: if 20 = 10, then 10 = 20-10 = 10-10 = 0. This means all multiples of ten are also zero. However, it also means you can’t divide by 10 = 0.

    With the axioms you have, it’s possible to have 1 != 0 (as in modular arithmetic). As such, your proof is wrong, and I can only give you partial marks.

  47. cshirky says:

    Klenow, the surprise was that consistency was more important than *actual knowledge.* The people who were inconsistent in their models could get more right answers than the consistent people. The view of the paper is that consistency even among people ignorant of the actual workings of a language, will do better than people who regard computer programs as meaningful to the machine, even if they do know the details.

  48. Draco18s says:

    I correctly picked the consistent group as the group most likely to outperform later, and for nearly the same reason: all you need to know is the right model and you’re good.

    But yes, programming is meaningless.

  49. Anonymous says:

    They devised a basic aptitude test for first year students of computer programming, and then administered it on the first day of class, before the students had learned anything. (One of them maintains this was a mistake, the other claims it was planned.)

    I thought most computer science students have already had experience with programming before first year.

  50. cshirky says:

    Reveng @ 17: While I deeply question the hypothesis these researchers came up with, and its meaningfulness without verification experiments…

    To their credit, they do too. They make it clear that this they are offering up their research to spur further debate, not end it.

  51. sabik says:

    @jdfreivald #14 and shutz #42: my point was more of a difference of attitude toward the finding: we can say that there’s something some people have and some don’t, and call it “programming aptitude” and use it to filter comp-sci students. Alternatively, we can say that there’s something some people have and some don’t, and we’re failing to teach it to those who don’t, and we should improve our programming courses to include it.

    Both meaninglessness and consistency are a part of it, I suspect; however, the true concept is probably more difficult than that and it’s always hard to describe something for the first time.

  52. zuzu says:

    Greebo, I imagine that your actively sharing of your work is part of the process of peer-review. (You telling him is exactly how Clay would find out, right?)

    Thanks for help making SCIENCE happen! :)

  53. bardfinn says:

    Programming languages do follow the rules of mathematics, they just don’t follow the conventions of arithmetic, in that various symbols don’t mean precisely the same as in arithmetic; They’re not the same concept but a related one, they’re not the same operation but a related one.

    Reading the test, I had to decide whether “A = B” was an operation or a statement. I decided that it was an operation. I then consistently applied that. I suppose someone might decide that it is a statement, and consistently apply that.

    I had to decide whether the operations were subsequent or concurrent; I decided that the operations were subsequent, and consistently applied that assumption. I suppose someone could decide that they’re concurrent, and consistently apply that model.

    My bias may be due to having programmed for nigh-on two decades now, and of assuming that each operation – unless otherwise explicitly specified – was subsequent to the one above it.

    Oh, Jesus; I’m typing out the Computer Scientist prediction, aren’t I?

  54. bishophicks says:

    It is the fact that the majority of people can’t think like programmers that gives me hope that I will always be able to find work as a programmer or systems analyst. I’ve been doing this for almost 20 years and I figured out long ago that hardware, operating system and programming language are pretty irrelevant. A person either thinks like a programmer or they don’t. If they do, they can be useful in any environment.

    Looking at the example, a programmer looks at the “a=b” statement, realizes that the value of “a” has changed and also realizes that the initialization of “a=10″ is now irrelevant, and can simply be ignored moving forward. A non-programmer can’t do this.

  55. Ugly Canuck says:

    Yes Arkizzle, time and sequence are in play.
    LB, in programming an actual physical machine gets in the way of “purity” of the math.
    In general, machines know nothing of “meaning”, they do but operate.
    BTW I am no programmer, so my views are very much from the outside in, on this topic.
    As with all human endeavors, some people will have (seemingly built-in) talent, while many will not who nevertheless by application and effort can achieve competency in the task at hand, and yet others (perhaps most) will never be able to perform the task under consideration. As ever those with talent can often improve greatly thereon by constant application and effort.
    In this way, programming is like swimming or playing the piano or flying the trapeze (or for nerds, having the sex).

  56. Bloodboiler says:

    I detests calling it “comfort with meaningless”.

    Programming is not about accepting meaningless rules, it is about continually adapting and switching to new new sets of rules. For instance, if you can program you can easily adapt to situation where statement “Rabbits lay eggs.” is a fact, as long as you are working with genetically engineered egg laying rabbits. The concept of a rabbit egg is meaningless only if you are not aware of the the context where it makes sense.

  57. bardfinn says:

    seattlepete: Claiming that one method of evaluating the statement versus another method of evaluating the statement is more or less valid, presumes agreed-upon rules of how to evaluate the operation. The long-time rules of arithmetic, agreed upon by arithmeticians, is that a division operator or multiplication operator takes an implicit priority. For trained arithmeticians, this is consistent and presumed. Yet, always writing the parentheses to explicate operator priority is more consistent, in that there is only one (and not two or more) string-length symbols that all /mean/ the same thing and evaluate the same under that particular set of assumptions but may evaluate differently under another set of assumptions, or lack thereof.

  58. t3knomanser says:

    @SeattlePete: left-to-right execution is more intuitive, certainly, and it’s trivially simpler than order of operations. But order of operations isn’t very complex- one rule per operator.

    But I’m not a fan of order of operations. I’ll be honest, I don’t leverage it. I find it simpler to always group terms with parentheses.

    @CShirky(#19): Programming, even at a high level, is very much like math. At a low level, it’s very much like arithmetic, which isn’t really math at all. I would argue that the farther you get from the silicon, the more like math programming gets, not less. From the perspective of the users, you’re right- it’s nothing like math. But from the perspective of a programmer, everything they do is very much math, even if they don’t have the grounding in mathematics to recognize that.

    My biggest regret about my education was not spending enough effort on mastering mathematics. I’m an excellent programmer (not to pat my own back or anything) but a lousy mathematician, and that means there’s a limit to how great a programmer I can be.

  59. markfrei says:

    “Dehnadi and Bornat’s thesis is that the single biggest predictor of likely aptitude for programming is a deep comfort with meaninglessness.”

    Ok, was I the only one that laughed aloud when I read this?

  60. Daemon says:

    Doesn’t surprise me that the consistent group would do well. Programming is all about consistancy…

    The rules never change, so how you think about them shouldn’t either. If you are a consistant thinker, then even if you are consistantly wrong, it’s just about showing your where and why you are wrong, and once you get that, you’ll be consistently right. Not to hard to see why inconsistant thinkers wouldn’t do as well working with something that’s entirely consistant.

    And I’m not surprised the “didn’t answer” people didn’t do well. If for no other reasons than that people who don’t risk being wrong are going to have a steeper learning curve as a result. You’d think scientists would recognize the value of failure – their entire field is based on getting things wrong. (Scientific method: get something wrong. realizing what was wrong. get things less wrong in the future.)

  61. t3knomanser says:

    @BishopHicks: Yes. Programming is its own skill. If you can program, and I mean really program, you can get the basics of a new language in a short number of days. You master the ins-and-outs of that language in a matter of weeks.

    Programming is programming, regardless of whether your line terminators are “;” or “.”.

  62. greebo says:

    Zuzu – great shirt, just in time to add to my xmas list. Was I too hard on him?
    I guess I just naturally expect all bloggers to be able to do a reverse citation lookup on google scholar. The world regularly disappoints me. :-)

  63. bardfinn says:

    Xeno:

    One of the problems we have is user adoption of the database. Before this database, people kept information in isolated spreadsheets, and it wasn’t of any use to anyone.

    We have a DBA who chooses to wield the stick. She doesn’t get many results. I chose to teach the database to silently and consistently normalise and correct user input. Unfortunately the database we are using works better with the stick than with the magic carrot, but it keeps them using it.

  64. Anonymous says:

    Programming is in many ways just like mathematical operations. But most mathematicians don’t do mathematical operations, they do things like Lie algebras, finite fields, and logic. To be a mathematician, you need a very strong sense of the abstract, more than is needed by programmers.

  65. nprnncbl says:

    @bardfinn- I agree completely that expressing things simply and consistently is important, and I didn’t mean to imply otherwise. But these are human skills, not properties of a language– although languages certainly do vary in how they allow one to express programs.

  66. skeeto says:

    I think there are only two groups here. The blank group was part of the consistent group. They were consistently blank.

    And I think blank really is a consistent model here. If this was an IQ test, which means nothing in the test will draw from any real-world, a priori knowledge or education, the correct answer would simply be “not enough information” because the operators were not defined in the exam. Since this was given at the beginning of the course, the student could assume (unless told otherwise) that everything they need to know will be provided by the exam itself.

  67. Anonymous says:

    a= programmer
    b= problem
    c= solution
    d= requirement
    e= reality

    if c > d then a = b and a <> e

  68. zuzu says:

    It is the fact that the majority of people can’t think like programmers that gives me hope that I will always be able to find work as a programmer or systems analyst. I’ve been doing this for almost 20 years and I figured out long ago that hardware, operating system and programming language are pretty irrelevant. A person either thinks like a programmer or they don’t. If they do, they can be useful in any environment.

    Broken window fallacy / opportunity costs

    Imagine how much more we could do if everyone could modify and improve their own software?

    That’s the gist of Doug Engelbart’s research on Augmenting Human Intellect.

    (It’s also the reflexive argument behind Free Software.)

    c.f. end-user programming, spreadsheets

  69. Guysmiley says:

    Assembly language programming really helps drive that concept home. It’s about as close as you can get to ones and zeros without crossing the line; however, even then you should keep in mind that computers don’t really use ones and zeros at all, because there’s no inherent meaning in an electron that makes it a “one” rather than a “zero”.

    Assembly definitely crosses the line, but in a good way (I think).

    If only x86 assembly wasn’t so ass-backwards (little endian grumble grumble)

  70. zuzu says:

    I guess I just naturally expect all bloggers to be able to do a reverse citation lookup on google scholar.

    I think the blogosphere expects the scientific knowledge repository to be more like Wikipedia and less like Google Scholar/ CiteSeer / science journals.

    “Everything is deeply intertwingled.”

  71. zuzu says:

    Programming is programming, regardless of whether your line terminators are “;” or “.”.

    I disagree; I think implying the invocation of Turing completeness is a tired cliche.

    We have different programming languages and different operating systems because some are easier (and more efficient) for humans to use than others.

    Humans are the ultimate resource; it’s we who need to be catered to. Not the efficiency of the computing hardware as CS would have you believe. You can’t take humans out of the equation, because we’re perpetually revising the tasks we’re asking computers to do (and even the computing hardware itself is being perpetually improved according to Moore’s Law).

  72. bardfinn says:

    Greebo: So, what you’re saying here, is that this study is … meaningless? And that you’re not comfortable with that? (i kid. i kid.)

  73. SamSam says:

    As a programmer, I’m surprised by the finding that programmers thought that those who didn’t answer would be the best programmers. This is absurd to me. The very essence of a good programmer, IMO, is hacking — trying to find your way around when you aren’t quite sure how to do something.

    Of course, I guess this is a bit of a special case, because they don’t have a chance to “hack” the rules — they get no feedback when they try something. But still, cautiousness is not a prt of any programmer I know.

  74. Xeno says:

    @BARDFINN

    I have a similar problem. The company STARTED with a spreadsheet and then tried to design a database based upon a spreadsheet paradigm. I came in and saw this and redesigned everything, this confused the HELL out of the other developer because he only understands one paradigm… the spreadsheet.

    However, this opens the ability for me to use enforce a standard rather than just accepting all data as ‘good’. As an example, I can force all states to comply to 2 characters and even check them against a preexisting table of states and two character codes (as no new states are being added). This makes it so all users who wish to enter a state in the database through said application MUST have data that is known to be good else it is rejected.

    I’ve found that if you can do this with as many fields as possible, you can drastically limit bad inputs into your database. Dropdowns and lookups are your friends.

    Plus helps that I designed an MVC framework that is database driven giving it a high scalability that is not really matched by other frameworks :)

  75. cshirky says:

    markfrei @ 30: there’s at least two of us

    t3knomanser @ 31: Don’t be ridiculous. God meant for termination to be newlines, and Guido is his Prophet. All other forms of termination are abominations to His compiler.

  76. FoetusNail says:

    Before quitting school to get a job, which meant repairing anything in an office, I was learning to program. My teacher, in the late seventies, said, people do math, machines compare, store, increment, retrieve. There is no such thing as addition, subtraction, multiplication, or division. At the machine code level the only thing one could compare what a machine does to the way humans think is to say machines add, but he would only concede this when pushed into a corner. There were no ones and zeros, it was high or low, on and off, full or empty. He was trying to reprogram our thinking. Processor’s don’t think, they execute code.

    T3KNOMANSER, if you get your wish, there will only be one programmer left on the planet.

  77. dragonfrog says:

    SeattlePete

    Isn’t the simplest way to to process 2+7*9 a strict left-to-right interpretation? Maybe I’m contaminated by an ancient language, but jumping to 7*9 first and then going back to +2 isn’t intuitive. 2+(7*9) and you might have something there…

    The simplest way to process 2+7*9 is to not express it in that notation in the first place, but to use a notation that is unambiguous.

    This is why engineers and computer scientists tend to like RPN. If you want 2 and 7 added first, write it that way ( 2 7 + 9 * ), if you want 7 and 9 multiplied first, write it that way ( 7 9 * 2 + )

  78. Xeno says:

    Logic is merely finding a pattern from something that seems to have none. Something that seems meaningless you know isn’t because you can see a meaningful outcome being repeated.

    The programmer will therefore look for that pattern. They will break apart the pieces in manageable ‘objects’, figures out how those smaller objects work, then figure out how they work together, and then figure out how the entire piece works when put back together.

    Once that is done, they try to duplicate and improve using their programming language of choice. Usually the best programmers and engineers are the kids who were taking apart radios and clocks as kids just to see how they worked. That same mindset lends itself toward a natural curiosity towards trying to figure out what they don’t understand by following the patterns that they see.

  79. shutz says:

    @Sabik (#1): maybe that single, key concept you’re referring to is precisely this concept of consistency that Dehnadi and Bornat are discussing.

    Once you understand that any randomness in a computer’s behavior is solely due to a randomness in input (even random number generators are only pseudo-random and need to be initialized by some random, external input, such as the current time) and that once all external inputs are accounted for, the computer or program will perform in a perfectly consistent manner, programming, and “thinking like the computer” becomes much easier.

    Indeed, “thinking like the computer” essentially means just that: thinking consistently.

  80. t3knomanser says:

    @Zuzu: you say you disagree, but it sounds to me like you agree with me. To word it a different way: “Isn’t that what I said?”

    I didn’t mean to imply that programming languages are interchangeable- they’re not. Each one is a tool best suited to certain tasks.

    When I say that programming is its own skill, I mean it in the same way to say that “Woodworking is its own skill”. While each woodworking tool has its own methodology and its own purpose, the general task of woodworking is its own skillset. You don’t need to specialize. The band saw is a very useful tool. Can you imagine if we decided every woodshop should specialize in band saws? A certain kind of problem becomes very easy, but huge classes of common problems become nearly impossible to solve with just a band saw.

    That said: I think we can and should remove programmers a bit from the process of programming. I see know reason why we shouldn’t write programs to write programs. I write so many DB front ends and datapumps that it makes my brain bleed from boredom. So many programming problems are solved for the general case, and yet programmers keep reimplementing their specific case of the general problem. Tools designed around automating these tasks are so painfully general that I may as well write the code from scratch (SSIS, I’m lookin’ at you).

    I want a program that can do some of my work for me. “Hey, here’s a tech spec in a word document. Implement it for me, and let me know if you have any questions.”

  81. georg says:

    Isn’t the simplest way to to process 2+7*9 a strict left-to-right interpretation? Maybe I’m contaminated by an ancient language, but jumping to 7*9 first and then going back to +2 isn’t intuitive. 2+(7*9) and you might have something there…

    No, this would mess up the commutativity of the multiplication, which messes up the algebraic structures we’ve been exploring. It’s not just a syntactic thing: http://en.wikipedia.org/wiki/Group_theory

  82. Takuan says:

    just pre-sort programmer candidates with the Milgram Method.

  83. Guysmiley says:

    trying to find your way around when you aren’t quite sure how to do something.

    My smart-alec answer would have been:
    cout << a;
    cout << b;

    :)

  84. Guysmiley says:

    My smart-alec answer would have been:
    cout cout

    HTML-pwnd.

    cout << a;
    cout << b;

  85. Anonymous says:

    It seems like most of the surprise here comes from describing things with no concrete meaning as “meaningless”. Usually, they’re called “abstract”. It’s not so surprising that programming and math require a good deal of comfort with abstraction.

  86. zuzu says:

    @40 t3knomanser

    I think we can and should remove programmers a bit from the process of programming.

    I agree with Dick Sites (DEC) about, “I’d rather write programs to write programs than write programs.” But that’s why in practice I disagree with “multiparadigm” programming (as much as the Oz book rocks). Programmers really need to stop manually threading, just like they needed to stop manually managing memory. (Unless you’re working in a very corner case.)

    I write so many DB front ends and datapumps that it makes my brain bleed from boredom.

    The historic split between “programming languages” and “databases” drives me mad. We could use a major dose of orthogonal persistence, native to the programming language (that’s also the operating system, like Squeak Smalltalk, or how UNIX and C together used to be ala the K&R — in a half-assed ripoff of Multics way).

    I want a program that can do some of my work for me. “Hey, here’s a tech spec in a word document. Implement it for me, and let me know if you have any questions.”

    That’s the idea behind declarative programming. At least introspection / reflection is a good start. (e.g. irb) Removing the false dichotomy between interpreter and debugger is wonderful.

  87. cshirky says:

    Greebo, thanks. Posting an update.

  88. Anonymous says:

    I wonder how they justify the aptitude. It is a very common and very unsettling issue in the computer science world that the majority of graduates from even the most renowned universities seem to have skill sets that are inadequate for current market demands. Colleagues of mine from a variety of fields ranging from major research institutions to small startups have expressed concerns about the quality of developers they’re meeting for internships and employment. I’m sure that a “nose-down” coder would probably fit the mold expressed above; but, in defense of my fellow mathematicians, I imagine that the students who would exceed the expectations of my associates would be more inconsistent on this preliminary exam. Why, then, do we not see a lot of successful graduates from the CS program who fit the bill? I imagine the curriculum is to blame and that the Codds, Turnings, and Von Neumans of our time elect to pursue other fields of study which are more provoking and rigorous (such as mathematics or electrical engineering).

  89. nprnncbl says:

    Apparently, the researchers have discovered that there actually 11 kinds of people, and not 10, as previously believed.

    Zuzu- I’m not going to stand up for imperative stateful programming, but it’s naive to think that’s the root of all bugs. One can make errors in any paradigm; try some pure functional programming with continuations and see if you don’t make any mistakes.

    I also don’t see how bishophicks comment is the broken window fallacy: are they sabotaging code or writing bad code to make work for themselves, or just pointing out that they have a useful skill? Supporting end-user programming is not an easy task. Also, modify != improve.

    Bardfinn- any Turing-complete language will actually support an infinite variety of programs which produce the same result; finding the shortest such program (cf. Kolmogorov complexity) is an undecidable problem. In your example: is 2 + (7*9) the same or different program from (7*9)+2? What about 2*7+2*9? Or just 65? Uniqueness of the result of a program is much more important than uniqueness of how it is expressed.

Leave a Reply