Wrong title is wrong! The good programmers take a guess at the laws governing what's going on, and apply that law consistently. They are capable of seeing laws apart from ordinary, everyday situations. They see more meaning.
I don't know whats all the fuss about programming being so "special".Everything is hard - music is hard, carpentry is hard, poetry is hard, designing a effiecient vacuum cleaner is hard , but wonder why only we programmers make so much noise all the time
If a musician has her instrument on hand, she can make music, every single time. Musicians are really quite reliable. Their improvisations and crowd-pleasers won't all be as good as the best works of Mozart, or Monk, or even Billy Joel, but chances are that the crowd will be at least moderately pleased. Cover bands do not routinely run 300% over budget and six months late, and if they do you can be confident that the fault was entirely theirs -- it's not that the gig, which seemed simple on the surface, turned out to be completely intractable.
A skilled carpenter or vacuum-cleaner engineer might not produce a masterpiece every time. But the result will probably be a house that doesn't fall down, or a thing that picks up some dust for at least a little while. Vacuum cleaners are a well-understood technology, and while carpentry projects do occasionally go nonlinear (if you change the specs mid-project, or a freak windstorm blows up, or they discover a natural spring while digging your basement, or... well, just go read Mr. Blandings Builds His Dream House, one of the greatest engineering books of all time ;) they are nonetheless relatively predictable, and the more experienced the carpenter the fewer surprises you can expect.
Now go read Dreaming in Code, which shows that even if you are Mitch "I Built Lotus" Kapor and you hire Andy "Mac OS 1.0" Hertzfeld your software project may fly straight into a wall: You may blow the schedule by a factor of five, and the budget by a factor of ten, and still not ship anything. [1] It has happened. People who write books about corporate IT throw around numbers like fifty percent when discussing the odds that a given software project will succeed. And the reason why programmers don't stop talking about this is that it is vitally important that our clients understand the risk in advance! Which they often don't. Nothing in their everyday experience with plumbers, dentists, and caterers has prepared them for it.
---
[1] Note: These numbers are not the ones from Dreaming in Code. I made them up. ;) I actually have yet to finish Dreaming in Code. It induces painful flashbacks.
You ever heard of a one-hit wonder? There countless of them. There are also numerous examples of extremely popular bands releasing an album that is panned by critics, fans, or both (read: Metallica). I agree with your parent post, every discipline involving art and talent is complex and difficult if you're interested in it and delve deep enough into it. It's just that programming gets a lot of attention on the Internet, especially Hacker News, but that's no surprise, is it?
I've read Dreaming in Code, and I don't think you can draw many conclusions from it. The project was especially undisciplined, and given that Kapor started it, I think he has to take most of the blame.
Some musicians make noise too! Seriously, music teachers etc. also wonder about how to teach, how to determine which studets has potential and so on. But they usually dont do it on HN, so it is probably a case of confirmation bias if you think programmers make more noise or talk and think more about their profession than people in other walks of life.
It's not that "only we programmers make so much noise all the time", you have to remember that the internet is the domain of the programmer.
It seems like we make so much noise because we are the feudal lords of the online fiefdom. If you were to spend all your time in wood shops for example, you'd wonder why carpenters complain so much.
I think it stems from the fact that you actually have to understand a problem in computer science to comprehend it's difficulty. In carpentry, for example, anyone can observe a finely carved piece of wood work and immediately know that it was a difficult to make. In computer science you show a layman gcc next to the Windows calculator program and my guess would be a majority would choose the calculator as the more difficult of the two. This likely makes us computer scientists feel like we have to explicitly state the difficulty of our accomplishments where as for some better understood professions it is implied. I mean there are loads of people out there who think that they know everything there is to know about a computer because they can upgrade their sound card and install windows w/o setting their house on fire.
As I read your comment, you're suggesting it's a form of self-involvement. If so, I don't think that's quite fair. Programming has been around for fifty years. That far into, say, the industrial revolution, people were talking about it a lot. In fact, it was at least a hundred years before industrialization began to be understood and quite a while later before you get Taylor and Ford. And software is far more complicated than that. So the reason we talk obsessively about programming is that we've barely begun, it's really important and fascinating, and we don't understand it.
I don't think "meaninglessness" is the right word for this. It smacks of journalistic spin. I wonder what a better word would be... maybe just "abstraction"?
The word that comes to mind to me is arbitrariness. That's not quite right either because it is a self-consistent arbitrariness rather than an arbitrariness for arbitrariness' sake.
If you want to get different results, you have to change the rules of the game.
As for the term "meaningless," I think I can see what the researchers are saying. For example, when I first started programming in QBasic, I was trying to modify a game called Gorillas that came with the language. In the game, there are two gorillas that try to destroy each other by throwing exploding bananas. I saw one variable in the code was called 'banana' and thought changing it to 'baby' would make the gorillas throw babies at each other (yes, I was a strange kid). Anyways, that would be an instance of looking for meaning where there isn't any. I ignored the syntactical context of the variable in favor of the semantics of the variable name, though this was more due to me not being familiar with code.
So, the tested students who focus on the syntactical context of variables and keywords will probably be better at understanding programs than those who focus on their understanding of these words' semantics. The problem is not "meaning" itself, but that they are using the wrong frame of reference to derive meaning.
Perhaps a better distinction, then, is objective vs subjective meaning. Those who look for the objective frame of reference to infer meaning will understand programs better. Once they do so, they can analyze programs more semantically. For instance, now that I've been exposed to many languages, I know something called "print," occurring in a certain position on a line, probably outputs textual information somewhere, such as stdout.
I've noticed this kind of mindset helps with debugging. I use it to eliminate possibilities and to also keep going. The latter is especially important when I think I've already tried all possibilities. It's a constant check that keeps me from thinking it's a problem on the computer's end, instead of a problem on my end. I can think of a number of times when I've been able to solve the bug precisely because I kept the right mindset.
The problem with the compiler is that it implements a language whose rules, applied to the code I just wrote, yield a bug. That this language is consistent with the spec makes it no less a problem.
Worse is when you think you've proved it to be bad memory, but it turns to be something way more ridiculous.
I dealt with a batch of 60 identical PCs that would occasionally fail in odd ways during the disk imaging process, and upon further inspection would fail memtest spectacularly. It didn't make sense, as they were stable when running an operating system, just not in memtest or while imaging. Plus the memory tested fine in other computers!
I eventually figured out that while the BIOS was in real mode, the USB controller would write to extended memory when the USB mouse sent it events. They would have no problems with the mouse unplugged, and the problem went away with a BIOS update. It took a lot of yelling to figure this out!
I wouldn't call it 'comfort with meaninglessness' but rather 'ability to find meaning'. Those who succeeded were the ones who came up with a theory about how things could work and then applied their theory consistently. The problems must have seemed more meaningful to them than to the others who answered at random or thought there was no answer.
I think they are using 'meaningless' as 'lack of significance' more than 'lack of meaning'. Programming rules obviously always mean something, but they don't always seem significant. People who get programming are comfortable with that lack of significance and just go about following rules. People who don't get programming try to find significance where it's not and end up being inconsistent.
The researchers posit that the students who start by applying rules consistently across problems learn programming better than those who don't. For me, this raises some questions:
1) Can this mindset be taught?
2) Can this mindset be taught to anyone?
3) Can this mindset be taught more easily to the young than the old?
4) Is this mindset a disadvantage in some areas? E.g. does it hurt you if you're a psychologist or a novelist?
I'd love to see some research to answer those questions.
4) Is this mindset a disadvantage in some areas? E.g. does it hurt you if you're a psychologist or a novelist?
It depends on what kind of novelist you want to be, I think. A good illustration of the differences comes from Brandon Sanderson in his essay on "hard" versus "soft" magic. Hard systems give the reader the satisfaction of solving puzzles and difficulties along with the characters. Soft systems preserve a feeling of mystery and wonder. Both can make for good writing.
On the one end you have Tolkien, and on the other, Asimov.
As I think about this novelist mindset connection once more, I'm reminded of a conversation I had with LE Modesitt who is the author of some of my favorite 'Hard' fantasy novels. He has an extremely large base of readers who are engineers. They really love the logic and problem-solving he introduces in his magic system. Interestingly, another large lobe of his fanbase is female readers looking for intelligent romantic fiction.
Perhaps this "deep comfort with meaninglessness" explains why -- anecdotally at least, in my experience -- there seem to be higher levels of atheism among programmers than among the general populace.
As a grad student, I was a TA for an intro Java class, and I remember the students who just didn't get it. It is hard to say why they failed. Most of the worst students fell behind quickly, and never really had a chance to catch up. It would have been interesting if I had had more of a chance to try and figure out where they were stuck and help them out, but I think most of them gave up trying to understand the basics once they realized how far behind they were and just spent their time copying off other students to get a passing grade (many of them were later caught).
As far as the article goes, it says that no other successful predictors have been found for programming aptitude, but when I looked at one of the references cited, it didn't even include HS GPA or SAT scores. I would be surprised if there was no correlation there.
Really, from what anecdotal evidence I've seen, the ability to deal with things abstractly is crucial. Moreover, it has seemed to me that the ability to maintain multiple abstractions and switch between them is also crucial. Note that this isn't "inconsistency" (to borrow the article's terminology), but rather an awareness of context.
This is precisely why I find that the hardest programming language to learn is your second. To learn the first, you just memorize some arbitrary rules. To learn the second, you must develop abstractions for both, and realize how they differ.
