[intro, ad]

Atwood: Hey Joel.

Spolsky: Hey Jeff. What er, what day is it?

Atwood: Today is Tuesday.

Spolsky: Is it podcast day?

Atwood: It's podcast day.  It's always a very exciting day.

Spolsky: [laughing] Let's do a podcast

Atwood: Yes. Let us.

Spolsky: Ok. Erm...

Atwood: So today is, well, Tuesday is, you know why else Tuesday is awesome...

Spolsky: No

Atwood: 'Cause, every Tuesday there's new songs for Rockband and this week is epic because it's the best of The Who.

Spolsky: Oh... really? They have The Who?

Atwood: Yeah, so I guess, well there was one Who song in Guitar Hero 3 called "the Seeker", I don't know if you know it, it's really fun to play, but this is the "best of" so it has stuff like "Baba O'Riley", "Eminence Front", "Behind Blue Eyes", pretty big hits so it was really fun, I was just playing it outside actually.

Spolsky: Does it have "Who Are You"?

Atwood: It does have that, I played that as well.

Spolsky: God

Atwood: Yeah

Spolsky: I may have to ... this game

Atwood: You know what I learned the other day, so the song "Baba O'Riley", there's some guru, some Indian guru that, I guess back in the sixties, one out of those, Pete Townshend or some member of The Who, Roger Daltrey maybe, uh, was under the influence of this guru and the song "Baba O'Riley" is named for that guru the first name Baba something, but I, he, there's some like church for him down the street from our house, very California, there's like a little, you know, little, there's a little strip-mall and in this strip-mall there's this place that you go and there's all these pictures of this guy on the wall. There was like an art-stroll which was why we were in there and I was like "What is this place ?" and my wife figured it out, she said "Oh this is that guru, Baba" and I don't even know his name I'll have to look it up, but that is from the song "Baba O'Riley" as well so there's your random pointless trivia of the day.

Spolsky: So, I'm, I'm intrigued by this. You're saying that they have gurus in India, too?

Atwood: [laughter] I always associated gurus with India, but maybe there's other places that they're from. Is that not true?

Spolsky: I don't know. I thought it- I thought it was like a code... thing.

Atwood: Oh, no no no. It's traditional religion.

Spolsky: Mmhm.

[pause]

Spolsky: Uhhh, usually you have something to talk about.

Atwood: I do, but I want- this time I want to do something a little different. The reason I was being quiet was cause we had some stuff from last time that you wanted to talk about. In particular, you had a blog entry about disabling menu items, that we were gonna discuss.

Spolsky:  That's a good idea. Let's talk about the disabling of menu items.

[pause]

Spolsky:  I'm not actually- This is a meta-conversation. I didn't really want to talk about the disabling of menu items. Umm, I was sort of thinking about Twitter and how people are now writing these one line blog posts, and I used to waste all this time writing these thirteen page blog posts. And, as time went on, people got whinier and whinier the more words you put in your post. And, uh, I sort of came up with a list of five or six things that I thought were good, you know, two paragraph posts...

Atwood: Mmhm.

Spolsky: Five, six, seven sentences. And, uh, I thought I would post them and just sort of knock 'em out, and I'd put one up just to see what would happen. And, uhh, the trouble is if you put something up without writing a long enough post to actually make your full case, uhmm, you just get misunderstood, was sort of what I concluded.

Atwood: Well I think you took it too far, though. I mean, my impression was there's there's some in-between between 13 pages and like one- Was your post even one paragraph? It was rea-

Spolsky: [laughter] It was almost three paragraphs.

Atwood: It was really absurdly short, and I thought you could've done, like, five paragraphs, maybe 10 paragraphs? That would've, I think, done it some justice. I felt like maybe there's-

Spolsky: Three! There's three paragraphs there.

Atwood: Really?

Spolsky: It's very short for something I would post, and uhhh. So here's, you know, what the post said is, uh, don't disable menu items that aren't available. Uh, instead, leave them enabled, and that gives you an opportunity to tell people why that particular item was not gonna work.

And so there's really a lot of things I kind of learned from this. None of them have to do with menu items. Um, the first is that as soon as you have something that's this short -- for me at least -- as soon as I write something that's this short- You know, I don't really plant my foundations well enough; I don't explain the situation; I don't frame the question; what kind of menu item these are, what kind of application you're writing. Uh, I don't- I didn't write defensively like I usually have to, qualifying it with every possible e-mail response I could ever get. And so, it actually led to quite a lot of people saying, "No, that's wrong! You should not- You should disable, or hide, menu items that do not apply!" And, usually, they went a lot further than that. And so this is somewhat useful because, you know, there's some discussion of the subject in the blogosphere, and that discussion itself, and just, you know, thinking about this issue is more valuable than if I hadn't brought it up and nobody had thought about it.

Um, what I did see, actually, in about eh, 85 to 90 percent of the responses that I got via e-mail, or that I saw people post on their own blogs or in discussion groups, is that what people tended to do is just think of a use case that's interest- that, that- just one use case that's on their mind, for some reason. And then, evaluate whether or not you should disable menu items based on that particular use case that they happen to have in their mind.  So, for example, I saw one person who said "Well, here I am in my email program, and I don't have a message open, and this particular menu item that has all these message commands, all of them are greyed out.  So are you telling me that those should all be enabled?"  And, actually, yes, I was.  I was saying they should be enabled, and if you're trying to forward a message, and you don't actually have one open, then you have a misunderstanding as a user, and you need that to be clarified.  Somebody needs to explain that to you, and that's one of the jobs of the application, to make it easier for you to understand how to use it, is to correct your misunderstandings about how the program works.  But what I actually got is a lot of people that were kind of upset, that imagined that they would be clicking on all these menu items, hoping that they would work, and then they would have to dismiss an annoying dialogue box.  And that's fine, and there's obviously a great middle ground here, where you try to disable the menu item somehow, but you still provide some indication as to what would have to be done to enable it, or why it doesn't work.  You need to find some kind of UI metaphor, which nobody really has a great suggestion for, and it's not very common, but some kind of UI metaphor, where the thing looks disabled, but you still know that you can find out what to do to get it to work.  In the web it may be easier, where you can still make something, like, linkable but grey, or have a little info button next to it.  A typical GUI application programming, the standard menus that the come with just don't give you that as an option.  So that would be the optimum strategy, obviously, is to disable the things and then provide some kind of a little indicator as to why they're disabled.  But if you're not going to provide that indicator, I would still argue firmly not to disable them.  And I was thinking of a different use-case.  So, the use-case I was thinking of was, you had mentioned that in the Windows Media Player, you can play things faster when you're listening to podcasts and so forth, and it'll speed them up.  And when I looked in there, that was disabled.  And I couldn't figure out how to enable it.  And obviously the help file is no help--not that anybody reads helpfiles, but even if you did you couldn't find the answer to that.  And that was kind of frustrating, and I'd rather have that menu item be enabled and have it just tell me "I'm not going to do this right now because of the following reason.  I refuse to do this."  Because I didn't think--

Atwood:  As an experiment, I think it's kind of strange because the outcome is not really--is pretty predictable, I think.  And particularly in your case, because you don't really allow comments.  I know there's a link to, like, the Joel-on-Software sort of discussion, but it's not really in-line.  So sometimes when I--the way I view this is, when I write something and people misunderstand it, I have really failed as a writer--

Spolsky:  Oh, yeah.

Atwood:  --to communicate what I was trying to communicate.  So setting out with that intent is a little weird. But sometimes--

Spolsky:  I didn't set out with the intent to fail!  I just wanted to see how short I could take it before it failed, and I went beyond the shortness, and ... yeah.

Atwood:  But you're also lacking the context of course-correction comments.  Like in comments, a lot of times people will tell me, they look for my orange--I have a little Javascript that highlights my comments--and they'll scroll though and just read my comments, particularly if there's a lot of comments, just to get a sense if I did any course-corrections, trying to clarify.  Because sometimes, even if you're trying really hard to communicate, people just won't get it for some reason--a few people.  And what you can do is clarify in the comments.  And that is tacked on directly on the bottom so it's just right below the fold.  So it's not an additional click, and sort of a different area.  And also, with regards to Twitter, usually those are conversational.  Like, you'll say something, and thenpeople will go "Oh, you meant this!" and you'll go "No, no, no, I meant this." 

Spolsky:  Actually, part of that is a problem that I'm fighting.  I mean, yeah, you're right, it's the conversational-ness that is, I think, leading to the demise of blogs.  I hate to say this, but as soon as you get people--I mean really, when it was harder to publish a blog, and to write full length essays on a topic, and people worked on them and spent more time on their essays and put more thought into them and didn't want to kind of embarass themselves by putting out, effectively, kind of a paper or an essay on a subject that they hadn't really thought about, and that they didn't want to defend.  And there was a brief period like that, and we got some pretty good blog posts.  And now, where there's this world of just sort of everybody being a blogger, and it's just your opinion and blah-blah-blah, you have an enormous number of people who are actually not qualified to provide some input into something.  And that's OK, I'm not saying they shouldn't blog just because their not qualified, I'm saying that what they're doing is their having a conversation.  It's like if they were kind of hanging out with their friends, talking about some particular topic, this is what they would say.  They wouldn't go research it before they open their mouth, they would just say it.  And posting on a blog nowadays is easy enough that you can do that.  And unfortunately, that means that the signal-to-noise on blogs has gone substantially for the worse.  It's sort of turned into the permanent September.  Remember the permanent September?

Atwood:  Yeah, that's when they let the AOL users on Usenet.

Spolsky:  Yeah, and one of the things that I noticed--for a while there was a period when Usenet had deteriorated to just all noise and no signal, or basically the noise was drowning out any useful signal that had been there previously.  And then there was the switch to the web, and creating a website was so much harder than posting on Usenet, that for a while it required sort of a more elite kind of software developer, effectively.  Because it was software developers who were posting on the internet, because they were the only ones who could figure out how to do it.  And the quality went up for a while, and as the tools got easier and easier and easier, and we got these great blogging tools that are absolutely trivial to use, you get a lot of teenagers who have interesting things to say to their friends, and that's what they're doing there.  And that's OK, but the net result is that there's a whole bunch of articles that look a whole lot like your blog posts, or my blog posts, which are either relatively well-researched and relatively edited, and thought-about, I guess, compared to the kinds of other things that people say as if they were having a conversation.  And again, I should emphasize, not that there's anything wrong with that--it's just that there is something about the blog world, where if you take twenty articles on programming topics, nowadays fifteen of them are written by people who really don't have very much experience in the things that they're blogging about, and are actually giving you life advice based on one particular thing that happened to them in their career--which is their first job out of school, or maybe they're still in school, or whatever--and it is indistinguishable, actually, from something from somebody with a lot more credibility.

Atwood:  Is it really? It's not indistinguishable, I don't think.

Spolsky: Well how does it look different than something that Paul Graham posts or that you post? Ah, if somebody posts their opinion based on, you know, nothing?

Atwood: Well it's all about effective communication. I mean if you have somebody who happens to be a young programmer, who's a really effective communicator, then I think they deserve to be read, and they will be read.

Spolsky: No but fine, they deserve to be read, but they're wrong! They're saying wrong things!

Atwood: Well, I think that's relative. How do you define wrong? I mean like what, like..

Spolsky: Wrong meaning if you say this is a good idea I'm gonna do that, then you'll have bad results. I don't think that it's a relative, I think that there's just wrong things you can say.

Atwood: Well I think the audience should learn to read critically, and should learn to ask for data. I mean if someone has an opinion it's like ok you have an opinion that's great but what data are you basing this on? That's really the job of the reader, to be critical, you know of that stuff, and then on top of that you have this meta-layer of like reddit and digg and hackernews and all these other filtering mechanisms that are designed to bring the good stuff out and filter it and move it to the top of the list.

Spolsky: And do they really do that? It seems like reddit brings out the stuff that sounds like there's a conspiracy theory and we're about to invade Iran. That stuff is the first stuff that will come up. So I don't even know if that's, I don't know if these things.. They'll post things that match their world-view which sometimes is real, and sometimes is just wacky. But I don't really think they're doing a great job of evaluating whether the people that say the things should be qualified to say them.

[14:35]

[41:42]

Atwood: That was a very very long topic. It was good, it was good. It went into a couple of different areas. So, I do want to talk a little bit about StackOverflow now. There's one piece of technology that I havent talked about that is pretty critical, that I'm not sure how I've neglected talking about until now. Okay, so in every application, you have a database right? I mean for the most part, I mean are there database-less applications out there somewhere? They've got to be pretty rare. So, start with a database. So then you have the fundamental problem of how do you get stuff out of the database in a rational way. And by rational I mean in a way that won't make you claw your eyes out while working with it. So SELECT * FROM users right? What you get back in the nominal case is an array of typed columns, right? So this is the ID field, this is the last name field, this is the first name field, that's a string, this is a number, this is a boolean, date/time, money, whatever kind of field types you've got.

Spolsky: By the way, you should never SELECT *. You know that right ?

Atwood: (Jokingly) What? Oh, I'll have to write that down, we've been doing that. No, I'm just kidding. Yeah, of course, you should only select the data that you need, obviously.

Spolsky: Yeah, because somebody is going to add some long column there, and it is going to make your whole SELECT statement slower, even though you are not using that column.

Atwood: Right. There's also the art of putting your columns in the right order, so the long stuff is at the end, and the optional stuff is at the end. That actually helps performance a little. There's a whole theory of that. So the whole process of of...So you could write you application that way, where you just query stuff out of the database, and you are just directly working on these essentailly arrays that come back from the data base, but it is kind of awkward. Particularlly in a strongly typed language, where you are constantly casting things back and forth. And just the code just to update the database is very retundant. You end up with a lot of the same code in a lot of the same different places. So, what most people eventually arrive at is what is called object relational mapping, where you take the user table, and through unspecified magic that happens, it turns into a user object. So this is nice, instead of having an array of rows. You have user objects. You go "Oh user.name!", "Oh user.id!", and then in the optimum case you do something like. Give me user. Give me this particular user. Change username equals O'riely, or whatever we are going to change it to and then user., err, database.commit. so you've written no SQL code at all. It's just object magic. There's just a whole set of systems that do this. Object relation mappers, and they work generally pretty well. The one we're using in particular is C#, I think it was 3.0 or 3.5. I get a little squerlly on the versions. They've become very dynamic in the way that they number the frameworks. To put it charitably...

Spolsky: Its based on whatever their checkin, their last checkin to source code reposititory. What ever that number is, that's thier version number.

[44:25]

[58.41 - Currently Editing]

[To end of Show]

[intro, ad]

Atwood: Hey Joel.

Spolsky: Hey Jeff. What er, what day is it?

Atwood: Today is Tuesday.

Spolsky: Is it podcast day?

Atwood: It's podcast day.  It's always a very exciting day.

Spolsky: [laughing] Let's do a podcast

Atwood: Yes. Let us.

Spolsky: Ok. Erm...

Atwood: So today is, well, Tuesday is, you know why else Tuesday is awesome...

Spolsky: No

Atwood: 'Cause, every Tuesday there's new songs for Rockband and this week is epic because it's the best of The Who.

Spolsky: Oh... really? They have The Who?

Atwood: Yeah, so I guess, well there was one Who song in Guitar Hero 3 called "the Seeker", I don't know if you know it, it's really fun to play, but this is the "best of" so it has stuff like "Baba O'Riley", "Eminence Front", "Behind Blue Eyes", pretty big hits so it was really fun, I was just playing it outside actually.

Spolsky: Does it have "Who Are You"?

Atwood: It does have that, I played that as well.

Spolsky: God

Atwood: Yeah

Spolsky: I may have to ... this game

Atwood: You know what I learned the other day, so the song "Baba O'Riley", there's some guru, some Indian guru that, I guess back in the sixties, one out of those, Pete Townshend or some member of The Who, Roger Daltrey maybe, uh, was under the influence of this guru and the song "Baba O'Riley" is named for that guru the first name Baba something, but I, he, there's some like church for him down the street from our house, very California, there's like a little, you know, little, there's a little strip-mall and in this strip-mall there's this place that you go and there's all these pictures of this guy on the wall. There was like an art-stroll which was why we were in there and I was like "What is this place ?" and my wife figured it out, she said "Oh this is that guru, Baba" and I don't even know his name I'll have to look it up, but that is from the song "Baba O'Riley" as well so there's your random pointless trivia of the day.

Spolsky: So, I'm, I'm intrigued by this. You're saying that they have gurus in India, too?

Atwood: [laughter] I always associated gurus with India, but maybe there's other places that they're from. Is that not true?

Spolsky: I don't know. I thought it- I thought it was like a code... thing.

Atwood: Oh, no no no. It's traditional religion.

Spolsky: Mmhm.

[pause]

Spolsky: Uhhh, usually you have something to talk about.

Atwood: I do, but I want- this time I want to do something a little different. The reason I was being quiet was cause we had some stuff from last time that you wanted to talk about. In particular, you had a blog entry about disabling menu items, that we were gonna discuss.

Spolsky:  That's a good idea. Let's talk about the disabling of menu items.

[pause]

Spolsky:  I'm not actually- This is a meta-conversation. I didn't really want to talk about the disabling of menu items. Umm, I was sort of thinking about Twitter and how people are now writing these one line blog posts, and I used to waste all this time writing these thirteen page blog posts. And, as time went on, people got whinier and whinier the more words you put in your post. And, uh, I sort of came up with a list of five or six things that I thought were good, you know, two paragraph posts...

Atwood: Mmhm.

Spolsky: Five, six, seven sentences. And, uh, I thought I would post them and just sort of knock 'em out, and I'd put one up just to see what would happen. And, uhh, the trouble is if you put something up without writing a long enough post to actually make your full case, uhmm, you just get misunderstood, was sort of what I concluded.

Atwood: Well I think you took it too far, though. I mean, my impression was there's there's some in-between between 13 pages and like one- Was your post even one paragraph? It was rea-

Spolsky: [laughter] It was almost three paragraphs.

Atwood: It was really absurdly short, and I thought you could've done, like, five paragraphs, maybe 10 paragraphs? That would've, I think, done it some justice. I felt like maybe there's-

Spolsky: Three! There's three paragraphs there.

Atwood: Really?

Spolsky: It's very short for something I would post, and uhhh. So here's, you know, what the post said is, uh, don't disable menu items that aren't available. Uh, instead, leave them enabled, and that gives you an opportunity to tell people why that particular item was not gonna work.

And so there's really a lot of things I kind of learned from this. None of them have to do with menu items. Um, the first is that as soon as you have something that's this short -- for me at least -- as soon as I write something that's this short- You know, I don't really plant my foundations well enough; I don't explain the situation; I don't frame the question; what kind of menu item these are, what kind of application you're writing. Uh, I don't- I didn't write defensively like I usually have to, qualifying it with every possible e-mail response I could ever get. And so, it actually led to quite a lot of people saying, "No, that's wrong! You should not- You should disable, or hide, menu items that do not apply!" And, usually, they went a lot further than that. And so this is somewhat useful because, you know, there's some discussion of the subject in the blogosphere, and that discussion itself, and just, you know, thinking about this issue is more valuable than if I hadn't brought it up and nobody had thought about it.

Um, what I did see, actually, in about eh, 85 to 90 percent of the responses that I got via e-mail, or that I saw people post on their own blogs or in discussion groups, is that what people tended to do is just think of a use case that's interest- that, that- just one use case that's on their mind, for some reason. And then, evaluate whether or not you should disable menu items based on that particular use case that they happen to have in their mind.  So, for example, I saw one person who said "Well, here I am in my email program, and I don't have a message open, and this particular menu item that has all these message commands, all of them are greyed out.  So are you telling me that those should all be enabled?"  And, actually, yes, I was.  I was saying they should be enabled, and if you're trying to forward a message, and you don't actually have one open, then you have a misunderstanding as a user, and you need that to be clarified.  Somebody needs to explain that to you, and that's one of the jobs of the application, to make it easier for you to understand how to use it, is to correct your misunderstandings about how the program works.  But what I actually got is a lot of people that were kind of upset, that imagined that they would be clicking on all these menu items, hoping that they would work, and then they would have to dismiss an annoying dialogue box.  And that's fine, and there's obviously a great middle ground here, where you try to disable the menu item somehow, but you still provide some indication as to what would have to be done to enable it, or why it doesn't work.  You need to find some kind of UI metaphor, which nobody really has a great suggestion for, and it's not very common, but some kind of UI metaphor, where the thing looks disabled, but you still know that you can find out what to do to get it to work.  In the web it may be easier, where you can still make something, like, linkable but grey, or have a little info button next to it.  A typical GUI application programming, the standard menus that the come with just don't give you that as an option.  So that would be the optimum strategy, obviously, is to disable the things and then provide some kind of a little indicator as to why they're disabled.  But if you're not going to provide that indicator, I would still argue firmly not to disable them.  And I was thinking of a different use-case.  So, the use-case I was thinking of was, you had mentioned that in the Windows Media Player, you can play things faster when you're listening to podcasts and so forth, and it'll speed them up.  And when I looked in there, that was disabled.  And I couldn't figure out how to enable it.  And obviously the help file is no help--not that anybody reads helpfiles, but even if you did you couldn't find the answer to that.  And that was kind of frustrating, and I'd rather have that menu item be enabled and have it just tell me "I'm not going to do this right now because of the following reason.  I refuse to do this."  Because I didn't think--

Atwood:  As an experiment, I think it's kind of strange because the outcome is not really--is pretty predictable, I think.  And particularly in your case, because you don't really allow comments.  I know there's a link to, like, the Joel-on-Software sort of discussion, but it's not really in-line.  So sometimes when I--the way I view this is, when I write something and people misunderstand it, I have really failed as a writer--

Spolsky:  Oh, yeah.

Atwood:  --to communicate what I was trying to communicate.  So setting out with that intent is a little weird. But sometimes--

Spolsky:  I didn't set out with the intent to fail!  I just wanted to see how short I could take it before it failed, and I went beyond the shortness, and ... yeah.

Atwood:  But you're also lacking the context of course-correction comments.  Like in comments, a lot of times people will tell me, they look for my orange--I have a little Javascript that highlights my comments--and they'll scroll though and just read my comments, particularly if there's a lot of comments, just to get a sense if I did any course-corrections, trying to clarify.  Because sometimes, even if you're trying really hard to communicate, people just won't get it for some reason--a few people.  And what you can do is clarify in the comments.  And that is tacked on directly on the bottom so it's just right below the fold.  So it's not an additional click, and sort of a different area.  And also, with regards to Twitter, usually those are conversational.  Like, you'll say something, and thenpeople will go "Oh, you meant this!" and you'll go "No, no, no, I meant this." 

Spolsky:  Actually, part of that is a problem that I'm fighting.  I mean, yeah, you're right, it's the conversational-ness that is, I think, leading to the demise of blogs.  I hate to say this, but as soon as you get people--I mean really, when it was harder to publish a blog, and to write full length essays on a topic, and people worked on them and spent more time on their essays and put more thought into them and didn't want to kind of embarass themselves by putting out, effectively, kind of a paper or an essay on a subject that they hadn't really thought about, and that they didn't want to defend.  And there was a brief period like that, and we got some pretty good blog posts.  And now, where there's this world of just sort of everybody being a blogger, and it's just your opinion and blah-blah-blah, you have an enormous number of people who are actually not qualified to provide some input into something.  And that's OK, I'm not saying they shouldn't blog just because their not qualified, I'm saying that what they're doing is their having a conversation.  It's like if they were kind of hanging out with their friends, talking about some particular topic, this is what they would say.  They wouldn't go research it before they open their mouth, they would just say it.  And posting on a blog nowadays is easy enough that you can do that.  And unfortunately, that means that the signal-to-noise on blogs has gone substantially for the worse.  It's sort of turned into the permanent September.  Remember the permanent September?

Atwood:  Yeah, that's when they let the AOL users on Usenet.

Spolsky:  Yeah, and one of the things that I noticed--for a while there was a period when Usenet had deteriorated to just all noise and no signal, or basically the noise was drowning out any useful signal that had been there previously.  And then there was the switch to the web, and creating a website was so much harder than posting on Usenet, that for a while it required sort of a more elite kind of software developer, effectively.  Because it was software developers who were posting on the internet, because they were the only ones who could figure out how to do it.  And the quality went up for a while, and as the tools got easier and easier and easier, and we got these great blogging tools that are absolutely trivial to use, you get a lot of teenagers who have interesting things to say to their friends, and that's what they're doing there.  And that's OK, but the net result is that there's a whole bunch of articles that look a whole lot like your blog posts, or my blog posts, which are either relatively well-researched and relatively edited, and thought-about, I guess, compared to the kinds of other things that people say as if they were having a conversation.  And again, I should emphasize, not that there's anything wrong with that--it's just that there is something about the blog world, where if you take twenty articles on programming topics, nowadays fifteen of them are written by people who really don't have very much experience in the things that they're blogging about, and are actually giving you life advice based on one particular thing that happened to them in their career--which is their first job out of school, or maybe they're still in school, or whatever--and it is indistinguishable, actually, from something from somebody with a lot more credibility.

Atwood:  Is it really? It's not indistinguishable, I don't think.

Spolsky: Well how does it look different than something that Paul Graham posts or that you post? Ah, if somebody posts their opinion based on, you know, nothing?

Atwood: Well it's all about effective communication. I mean if you have somebody who happens to be a young programmer, who's a really effective communicator, then I think they deserve to be read, and they will be read.

Spolsky: No but fine, they deserve to be read, but they're wrong! They're saying wrong things!

Atwood: Well, I think that's relative. How do you define wrong? I mean like what, like..

Spolsky: Wrong meaning if you say this is a good idea I'm gonna do that, then you'll have bad results. I don't think that it's a relative, I think that there's just wrong things you can say.

Atwood: Well I think the audience should learn to read critically, and should learn to ask for data. I mean if someone has an opinion it's like ok you have an opinion that's great but what data are you basing this on? That's really the job of the reader, to be critical, you know of that stuff, and then on top of that you have this meta-layer of like reddit and digg and hackernews and all these other filtering mechanisms that are designed to bring the good stuff out and filter it and move it to the top of the list.

Spolsky: And do they really do that? It seems like reddit brings out the stuff that sounds like there's a conspiracy theory and we're about to invade Iran. That stuff is the first stuff that will come up. So I don't even know if that's, I don't know if these things.. They'll post things that match their world-view which sometimes is real, and sometimes is just wacky. But I don't really think they're doing a great job of evaluating whether the people that say the things should be qualified to say them.

[14:35]

[41:42]

Atwood: That was a very very long topic. It was good, it was good. It went into a couple of different areas. So, I do want to talk a little bit about StackOverflow now. There's one piece of technology that I havent talked about that is pretty critical, that I'm not sure how I've neglected talking about until now. Okay, so in every application, you have a database right? I mean for the most part, I mean are there database-less applications out there somewhere? They've got to be pretty rare. So, start with a database. So then you have the fundamental problem of how do you get stuff out of the database in a rational way. And by rational I mean in a way that won't make you claw your eyes out while working with it. So SELECT * FROM users right? What you get back in the nominal case is an array of typed columns, right? So this is the ID field, this is the last name field, this is the first name field, that's a string, this is a number, this is a boolean, date/time, money, whatever kind of field types you've got.

Spolsky: By the way, you should never SELECT *. You know that right ?

Atwood: (Jokingly) What? Oh, I'll have to write that down, we've been doing that. No, I'm just kidding. Yeah, of course, you should only select the data that you need, obviously.

Spolsky: Yeah, because somebody is going to add some long column there, and it is going to make your whole SELECT statement slower, even though you are not using that column.

Atwood: Right. There's also the art of putting your columns in the right order, so the long stuff is at the end, and the optional stuff is at the end. That actually helps performance a little. There's a whole theory of that. So the whole process of of...So you could write you application that way, where you just query stuff out of the database, and you are just directly working on these essentailly arrays that come back from the data base, but it is kind of awkward. Particularlly in a strongly typed language, where you are constantly casting things back and forth. And just the code just to update the database is very retundant. You end up with a lot of the same code in a lot of the same different places. So, what most people eventually arrive at is what is called object relational mapping, where you take the user table, and through unspecified magic that happens, it turns into a user object. So this is nice, instead of having an array of rows. You have user objects. You go "Oh user.name!", "Oh user.id!", and then in the optimum case you do something like. Give me user. Give me this particular user. Change username equals O'riely, or whatever we are going to change it to and then user., err, database.commit. so you've written no SQL code at all. It's just object magic. There's just a whole set of systems that do this. Object relation mappers, and they work generally pretty well. The one we're using in particular is C#, I think it was 3.0 or 3.5. I get a little squerlly on the versions. They've become very dynamic in the way that they number the frameworks. To put it charitably...

Spolsky: Its based on whatever their checkin, their last checkin to source code reposititory. What ever that number is, that's thier version number.

[44:25]

[58.41 - Currently Editing]

[To end of Show]