Podcast 014
Rytmis editing 37:00 - 40:00
[incomplete]
intro, advertising
[01:06]
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.
Atwood: Well i know when my stuff happens to go up, I do read the comments that come up on Reddit and there's certainly no shortage of criticism. I mean people are very, very critical. Umm. So in that sense I - and of your stuff as well. Particularly the last thing you did with the menus, there was a lot of criticism. So there's no shortage of criticism, I guess my point... people are saying, you know "Ooooh" this, you know accepting what you say at face value.
Spolsky: Right and I don't want them to. I do want them to read things critically. That's, that's important otherwise they would have believed me and, and maybe done the wrong thing. The trouble is a lot of these areas that we're writing about and that a lot of people are writing about are not measurable or quantifiable. Should you do code reviews this way or that way. Should you have this kind of schedule or that kind of schedule. Should you talk about your competitors by name or not talk about your competitors by name. Uhh.. there isn't, unfortunately.. uhh... these are not the kinds of thing for which scientific experiments have been devised and anybody has any data. What they have is their own personal anecdotes. Umm.. What happens is that there's different kinds of people in the world and there are people that just don't have a lot of experience and therefore have not been exposed to a lot of anecdotes and they've seen, maybe, one kind of thing and they've said you know that one time in this particular case, so I'm going to go make a general rule out of that thing. And the trouble is it .. to me it becomes enormously frustrating because if, for example, lets say that you wanted to read .. uhh.. a pretty good uhh.. news - community news aggregator which is , uhh... hacker news at news.ycombinator.com uhh... which is set up by Paul Graham at ycombinator and is populated by, umm.. basically a lot of kids starting software companies or internet companies. And, if you were to just take the top post every single day that, that rises to the top and jot down the advice that it allegedly gives you, within about three months you would have seen completely contradictory advice in every possible dimension...
Atwood: How is that different than all these business books that come out
Spolsky: They're exactly the same. Exactly
Atwood: They're exactly the same. I mean there's no difference.
Spolsky: Well, it depends. The business books - and that is actually another frustrating thing - some of these business books - and a good example is "Good to Great" - uhh.. are, are written, actually, with uh, enormous amounts of research. Literally dozens of researchers working for years and years and years, gathering tons and tons of data, doing all kinds of crazy statistical analysis, and actually coming to some, uhh, conclusions which are um, rather interesting. So in "Good to Great" there's this interesting conclusion that, um the most successful lasting companies were the ones where management or the CEO and/or founder actually show the least ego - amount of ego, which is actually an interesting conclusion. And this is numerical data, this is actually based on ...
Atwood: Wait, wait.. how do you measure ego? What was that data?
Spolsky: They count things like how many times he uses the word I when describing the company, or whether he says we when describing the company. Er, bizarre things like that, that do correllate. so anyways, I think this is the right book Good to Great, but there are actually books that are out there that are the results of enormous amounts of research, or enormous amounts of scientific data, I mean books based on, uhhm... actually findings of... of academic research that was done.. exist, and you're right it's very hard to distinguish between those things, and Seth Godin just giving you his opinion. Because both of those books, Seth Godin writes better, and his books are more interesting, and I happen to think he's "righter" in some way, you know; he's more right. But it's just his opinion.
Atwood: But if you can tell a story, right, and provide at elast some anecdotes, and maybe allude, or ideally present some data along with that, that's just basically effective writing. In general, effective persuasive writing. so if you can do that, you can persuade people that ok, maybe they should try this.
Spolsky: Yeah.
Atwood: How is that a net negative then.
Spolsky: Isn't that very dangerous, isn't that saying that the person who's most persuasive should decide what we do?
Atwood: But that's what actually happens anyway.
Spolsky: Right, and that's what I'm complaining about.
Atwood: I actually don't mind that. I think that if you're persuasive and I think that there are other persuasive people who see that you're wrong ...
Spolsky: Yeah
Atwood: will have that conversation about, "Hey this guy's misleading you for these reasons."
Spolsky: I'm very persuasive, so if I get into an argument here at FogCreek, mysteriously, I tend to win. I don't know why.
Atwood: Well, you're also the boss, right. That must have something to do with it.
Spolsky: I know, and as much as I try to train them to do what they are going to do anyway, and I do that very actively. A developer who has been here for a year or two knows to talk back to me.
Atwood: Right.
Spolsky: But they don't for a while. This actually sometimes concerns me, 'cause I do like to be persuasive in an argument, and to have things my way.
Atwood: Winning all the time; that's boring.
Spolsky: Well, I don't know, I could go for all the time! [laughs] But that doesn't mean the right thing will happen. So I have to be really careful to recuse myself. And one of the things, so were does this all lead, I'm not really sure. One of the things that umm. Here are two things that are indistinguishable. We may have talked about this before, I don't remember if it was on the podcast or not--so, at some point, dear listeners, this podcast will start to repeat itself.
Atwood: (Chuckles) Just like real people.
Splosky: Just like real people. I mean Rush Limbaugh must have said the same, must have done two shows that were indistinguishable, almost identical. Must be two show you can find there were he just says the same thing. Anyway, umm, the thing that I want to say for the eighteenth time is it's really hard, when you write, when a journalist writes a business story, let's say Business Week magazine, were he's writing a story about, let's say the story's about foreclosures. In Business Week, if there's a story about foreclosures, there's going to be a pitcure of an overweight family standing in front of a house and they're going to looking kind of sad and they're going to have bad complections. It's just guarenteed. And the house used to be theirs but it;s going to have a foreclosed sign in front of it. For some reason they are know longer allowed to live in this house. And that's guarenteed. And the first paragraph, of this story in Business Week about foreclosures, is going to be about a particular family. Absolutely guaranteed. Now, what's interesting, that's there style. That's just the way they do things, and they tell you an anecdote. Now a good journalist who has to produce a story like this for Business Week, what they're going to do is they're going to research foreclosures, they're going to see who it's affecting, they're going to see generally what's going on here, how many foreclosures are there, what kind of people are losing there houses etc, etc, what parts of the country. And they're going to write this story and they're going to say, "Now I've got to find an example of an almost typical family in order to give a personal picture here of what's going on. I'm going to find the most typical family and that's who's going to be in the picture, that's who the story is going to be about, and that's going to illustrate my point in a way which conveys more truth than what the original article did because it bring it home to you." And this is the kind of thing we say is good in writing. And that's fine, I'm not really criticising that in particular. Unfotunately, that is indistinguishable from a typical story that you'll read in the style section of The New York Times which is one of these stories which is full of weasle words. So it says more and more such and such is happening. So more and more Ivy League women who graduate are opting to raise families instead of joining the workforce. The word "more" doesn't mean very much, and it's not a very strong word, but sometimes they have even more ways of weasling out of actually making a statement. And so you'll have this story that is completely made up and it has no statistical evidence and no actual basis of fact in it, but it also starts with one of these anecdotes, and the anecdote is a story about some family or some person and that particular person is a friend of the journalist, and the journalist was obviously desparate for a story and asked their friend, "Hey, can I write about you?", and then the editor said, "Well this isn't interesting. This is just a story about your friend going to the Hamptons." and you say well, "Well, I guess I gotta make a story about it. As summer months enter, more and more young people are choosing to share houses in the Hamptons." And there's no actual statement being made here. There's an implication that there's some trend and that this is a trend story, but thought there's enough weasle words in the article, but there's no actual truth being asserted, and then there's a fun interesting anecdote which I like. I love the anecdotes. They're great. But the whole thing is being disguised as news and it's done in a way which is indistinguishable from Business Week, where the journalist has actually tried to find a particular example that best illustrates a story that otherwise would be dry and boring.
Atwood: Right
Spolsky: So the use of anecdotes is very dangerous here I think.
Spolsky: But now you're just teaching people that everything has to be measured.
Atwood: Well, how is that bad? That's science. Isn't that science in a nutshell? Science is pretty much measuring.
Spolsky: Because you don't measure things until you have a problem. I would say don't bother even measuring that until you start to see that the response time doesn't feel snappy. And then say, "Why doesn't the response time feel snappy?"
Atwood: Well, but, that's relative. Have you ever... Okay, so if you're a gamer, you'll notice this form where some people go into a form and say, "Oh my god, this game is so slow. It's unbelievably slow, I can barely even play it." And other peopler are like, "Oh, fine. Works fine for me." Because the two people's relative impression of what's slow and what's not is totally not even the same.
Spolsky: So you may have... it's okay to say, like... that's fine. So you want to say, "I have an acceptance criterion for this type of application. I want 100 millisecond response time. Therefore... we'll test against that. And only then will we actually measure how logn the queries are taking, or how many queries there are in a page."
Atwood: I don't know. I think it makes sense to always measure, particularly in a world of, you know, computers, where everything is really pretty easy to measure. Is there anything on the computer that is really that hard to measure? I mean, everything is just ones and zeroes.
Spolsky: Well, for example, we have an internal app that we use that shows us how much commission is due to the sales people that I just wrote. Should I be measuring how long those queries take?
Atwood: Um... maybe not for an internal app. But actually...
Spolsky: Alright, so there are cases where you measure and cases where you don't.
Atwood: Yeah. Well, I would still measure it, because you might want to... But you might throw away that data. But the advantage of having it outweighs the advantages of not having it, I think.
Spolsky: The advantage of not having it is that I didn't have to spend time measuring anything. I just put the SQL query in, and lo and behold, I got a result, and it came up in a kind of fast... I think it was okay.
Atwood: Right. But...
Spolsky: And I moved on.
Atwood: These data access layers tend to have that built in. At least ours does.
Spolsky: Like, I should be able to just turn this on and look at it and ignore it, or look at it.
Atwood: Yeah, exactly, that's what I'm saying.
Spolsky: Well, back to the original thought, whether or not that's germane... The anecdotes are very useful, because actually, hearing a lot of anecdotes, even if, no, the author doesn't have an agenda, he's not trying to convince you of anything, he's just telling you a story... The more of these stories you hear, the more you'll start to learn a way to know this is a recurring refrain, or maybe there is a particular solution.
Atwood: But your post didn't even have one anecdote.
Spolsky: Oh, I know, that was short.
Atwood: Before, you told me... so it was based on the [Windows] Media Player. Even having that one example would have made it a much much stronger version.
Spolsky: Oh, yeah. That article would have been great what I had said is, "I was listening to Jeff Atwood the other day, and he said that I could speed up podcasts, and I wanted to speed up the podcasts playing in Windows Media Player. And I went there, and it was grayed out. So how the hell am I supposed to do this?" And then I could have said, "Guys, don't gray out things unless you're gonna give me some kind of clue what I'm supposed to do."
Atwood: But you know what's funny about that? I guarantee you it'll turn into a hate fest of Windows Media Player. [garbled] That's hilarious.
Spolsky: So I think we agree, we always do end up agreeing on everything, which is something that there is some criticism -- we've been receiving criticism for agreeing too much. I think we agree that an anecdote would have been much more powerful and wouldn't have been making as strong a claim, and yet it would have been one of those things that would accumulate, would allow everybody to gain the wisdom of a lot of different experiences. So they would be thinking up a lot of use cases when they design things. They would be thinking of -- when they disable that thing, you know, it would just give them a story that would remind them that when they're disabling that menu item, "Am I leaving my user without recourse or with no way of figuring out how to ever get this capability if they can't get it right now?"
Atwood: Well, actually I don't agree that we agree [chuckles]. I don't--
Spolsky: Yes we do!
Atwood: The post, as you put it up--
Spolsky: I [hate?] this guy! What the-- [Spolsky and Atwood try to interrupt each other] Don't I have a button to [mute?] you?
Atwood: Well, seriously, the post as you put it up was just really ineffectual. Like, I wouldn't -- definitely wouldn't have published anything like that. Because, I mean-- [experiment] and all
Spolsky: I agree, it was an experiment which proved that you can't do this. It was a failure.
Atwood: But you're also sort of gaming the audience a little bit, which I think is a little -- a little dishonest if that was your goal.
Spolsky: No, no, it wasn't my goal, my goal was to see... I thought, actually, that it would work, to post some simpler, shorter posts, um...
Atwood: But it was too short. I mean it's--
Spolsky: OK.
Atwood: Again you... I don't know.
Spolsky: But how do you know it if you don't measure? The only way to measure is to try posting something that's too short and see that it doesn't work.
Atwood: Well there wasn't even like one example, I mean like -- plus you didn't cover any of like, "Here's some other ways apps do this." It could have been like -- you could have -- made it three times as long, which is still pretty short by your standards. It would have been a much stronger article. It wouldn't have been misinterpreted as much.
Spolsky: Oh, we learned that, didn't we.
Atwood: It wouldn't have taken that [long?] either. [chuckles]
Spolsky: We learned that.
Atwood: Yes.
Spolsky: We have a couple more examples of, er- I do think that there is something about anecdotes, which is that they don't really prove a point. If I had given one anecdote and then said, "This proves that you should never disable menu items", I-- In other words, we got two- we got three possible things theat I could've done. One is that I could've posted what I did, which is "Do this, don't do that." Uh, number two: I could've given some examples or anecdotes. So it would've been, you know, "Do this, don't do that because 'A', 'B', 'C'."
Atwood: Right.
Spolsky: And that's what I've done for years, actually, if you haven't noticed. And, umm, I've been feeling kind of guilty about it.
Atwood: Well, but, you also put tons and tons of words in-between. I think you could've just said, <the stuff you want to say>, <example>, <sentence>, <example>, <sentence>, <example>, <sentence>.
Spolsky: So I could've done this like one of those design patterns.
Atwood: Yes.
Spolsky: Like, shown a couple good examples, a couple bad examples, and just done it like a design pattern. Yeah.
Atwood: Yes.
Spolsky: That's a page of- Yeah, um- Now, the other thing I could've done -- which is something I'm going to be experimenting with increasingly -- and I'm doing this as much as my editor lets me get away with it in Inc. Magazine, where I have a monthly column- Which is, you know- And it's part of just getting to the age in my life where I don't feel like I know anything. [laughter] [Where is that nothing is helpful.]
Atwood: [laughs] Wait, wait. You're going backwards! You're going backwards! So as you get older you feel like you know less and less? Is that what I'm hearing?
Spolsky: Yeah, you're on the other side of that hump. You learn - know - more and more and more until you get to a certain age and then you know less and less and less. Um, anyway... [laughs] Did you ever learn a second language, Jeff?
Atwood: No, I did not actually... well, no, I know Spanish. Took a lot of years of Spanish in high school and middle school.
Spolsky: Okay, so, you can translate things to Spanish, right?
Atwood: I know enough to be a little bit dangerous in Spanish, that's about it.
Spolsky: Like you can say things like, um, "Excuse me, is the cow on your table?"
Atwood: Yeah. I could get by in Mexico if I was stranded, barely.
Spolsky: So, like, how do you say "table" in Spanish?
Atwood: Uh... I don't know. [laughs]
Spolsky: Probably-
Atwood: I know enough of... really basic words. It would be like speaking to a child, really.
Spolsky: Okay. Uh, well, what happens as you're learning a language is you go through a few phases. In the first phase you can't say anything, because you don't know enough words. And in the second phase it's just real easy, you know all the words, you've learned the vocabulary, you're like "bla bla bla bla bla". The third phase you start having -- in the third phase you start to have all these doubts. Because you try to translate a word, and you know about all the shades of grey and the way this word is not exactly like that word in this particular language, and dialects and... you know. Yeah, you could translate that, that would be the same thing, but it wouldn't convey the same sense of existential angst that that conveys in the original German. And so, as you become a better and better translator, you actually get worse at simultaneous translation. Because you start to get confused about the various synonyms and shades of meanings and the cases where the words don't exactly overlap.
And so, training people to be translators, actually -- or simultaneous translators -- is in part training them to get to that next level of skill, which is above and beyond just knowing both languages, where you can actually translate quickly, because you don't -- you've removed all this kind of doubt that you gained in the phase where you were learning all the shades of grey and all the details and the minuscule. And I think that's something that happens a lot, I think that you start your career out saying, "You know, I don't know anything about this software development process, but I'm eager to learn," and you read a lot and you read a lot of blogs and you listen to people and you talk to people and you go to conferences and whatever it-- whatever it is that helps you learn your field, and you just practice. And you learn more and more and more and more.
And as you start to get those first anecdotes and the second anecdotes and that particular story about the way a particular manager in your first job did a particular thing and it worked, or didn't work, you start to form rules from very little information. And you start to say things like "never throw away all your code, you can't throw away all your code and start over. Think of how far behind that will put you in the competitive world if you throw away your code and start over."
Atwood: And you have said that.
Spolsky: Yeah, you will say things like that, and that was based on a decision--partially it was based on a few anecdotes which are mentioned in that story, of companies that did that and failed, and so I think it's correct, and that that is where the overwhelming evidence is, that once you have shipping code you probably shouldn't throw it all out and start over--in a large system, not in a small system. You can throw out pieces of it and start over.
Atwood: Well, people kind of gloss over, too, that, first of all, it took a long, long time. It was, like, five plus years. Also, the business model totally changed. Where does Mozilla get their money from now? It's a totally different world--they get it from Google, basically, right? Through the fact that Google is integrated into the application. Every time somebody searches in FireFox using Ctrl-E, the search box, they get, like, a penny or whatever.
Spolsky: I still think that was right. Anyway, the point is that you get to this point in your career where you start to feel like you actually do have all the information about a lot of things. And that was the grand old halsee... halcy... halcyon--there's a word I can't pronounce--
Atwood: HAL-see-yahn, I think, is correct.
Spolsky: --days of Joel on Software.
Atwood: I'm really not the person to ask on pronounciation, but go ahead.
Spolsky: The halcyon days of Joel on Software. I sort of had that confidence, I'd sort of come of a really--ten years of working in software development, and reading a lot, and talking to a lot of smart people, and working in some places where they really knew what they were doing. And I basically just sort of dumped down the knowledge that I had learned in those ten years as quickly as I could. But over time you start to realize that there are actually all kinds of weird shades of grey, and slightly different variations on things, and it becomes harder and harder to make absolute statements that are interesting. Because, if I were to write an intellectually honest blog post now, it would be like, "63% of the time--you're probably in a situation, where, 63% of the time, you should do A, and the rest of the time you should do B. Here's some cases where you would do A, and some cases where you should do B, and the whole thing would just be too mushy. Nobody would wanna read it, it would be all full of--for example, one thing that I was pretty absolute about is the idea that programmers should have private offices. Which I still believe, that programmers are much more productive with private offices, and they're more willing to work for you if you give them private offices, because the conditions are better. However, since I have said these things, I've learned that a lot of programmers actually prefer to socialize, and not have private offices, because they think of it as being more sociable and more fun. And they are less productive for it, and they're not going to admit that, they'll tell you "Oh, well, we're having accidental productivity," or whatever. But it's just more fun for them. And so one of the reasons that there isn't as strong of a movement towards private offices as I think there should be based on the productivity gains and the recruiting gains that you could get, is that a lot of programmers imagine private offices as being lonely compared to their very, very social workspace where they're laughing and chatting and joking and talking about the bar they went to the night before, pretty much all day long. But that's just a big old caveat, and am I supposed to put that caveat on everything that I say? I still think that private offices are the way to go, it's just that as I've learned more about the shades of grey, the kinds of things I might be able to say about particular topics become more muddled and more boring.
[37:01]
{anecdotes only from now on}
[37:46]
{what if programmers had a choice?}
[38:21]
{it would impact productivity}
[39:16]
{these decisions aren't made often and they're made wrong}
[40:08]
{and they're made by people who don't understand}
[40:28]
{Microsoft's workspaces}
[41:10]
{Scoble video of Microsoft Research}
[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 the version number.
Atwood: So there's this thing called LINQ, and what LINQ does, is it basically lets the language be aware of SQL like constructs, like where clauses, basically set type operations that you would do in SQL, cause SQL's kind of a set based language, which sets it at odds with sort of your typically procedural code, just looping through. But in LINQ, and in particularly LINQ to SQL, see there's all these different flavors of LINQ, because it can't be Microsoft unless there's 10,000 versions of the same thing, right so there's LINQ to object, and LINQ to all, any number of LINQ to whatevers. But the LINQ to whatever that we're using is LINQ to SQL, and it's actually pretty slick because, you take a database, and you drag it on this design surface and it sort of infers all the classes, sort of automagically. So this is where you get the user object, the invoivce object, and all those other things, and they know about each other. This is the key thing, based on the foreign keys that you set in the database...
Spolsky: [laughs] Assuming that you do that
Atwood: Well, assuming that you set your database up properly...
Spolsky: I've yet to have a reason to create a foreign key, so this might be my first reason to set up one.
Atwood: yeah, without those relationships it would be tough. But, I've gotta say, it really is neat, because the other thing about LINQ to sQL that I personally like a lot, is that you can do ad-hoc SQL that can then be cast to the correct object types. In other words, I can do this random query that gives me a set of 5 customers that have some totally unique set of criteria, that nobody else would come up with, and then in the line of code that I do that, say just cast this to user. And I end up with an array of users. And actually not even an array, it's actually set based so I can do LINQ stuff on it, like I can take that set of users and get it back and do .where and then add a clause, and it's all typed code. So the other problem with SQL is that it's strings. You're compiler doesn't know anything about the SQL, it's jsut a string. So you could have syntax errors, you could have completely incorrect SQL in there. But with LINQ to SQL, since you're using language constructs to manipulate the tables for the most part, so if I remove a field from the user table, I immediately get compile errors...
Spolsky: That's cool.
Atwood: on all the LINQ clauses. Yeah on all the LINQ clauses that use that field. Whereas the traditonally app you would be able to build, you could deploy the app, and it would blow up on production because hey, you deleted the social security field on the user table anad you didn't figure that out until later.
[46:46]
{problem solved? No, but this stuff is good}
[47:40]
{there are strengths with RLDBs vs ORM}
[49:07]
{Jeff loves RLDBs}
[49:40]
{The syntax on LINQ is back-to-front}
[50:13]
{LINQ can be used on internal data structures too}
[50:40]
{but that feature... hasn't proved compelling yet}
[51:07]
{Jeff explains what he's using an array for}
[51:33]
{LINQ is for CRUD developers}
[52:18]
{Microsoft Tools group has been good at almost solving big thorny problems}
[53:06]
{Why isn't there first class support for addresses in SQL Server?}
[54:26]
{ORM removes boilerplate code, but doesn't deal with mapping into HTML}
[55:16]
{VS2008 gave a couple of features; columns mapping to web pages and columns to variables}
[56:25]
{Rails emits tag soup}
[57:00]
{There's logic in the template, and the same problem exists in MVC}
[57:28]
{User controls in ASP.NET}
[58:05]
{It avoids large convoluted files, like subroutines provide an abstraction}
[58.41]
Atwood: Before we go to much further, I know we're close to the end. I want to get to at least one question. Because I always feel guilty if we don't.
Spolsky: Okay, I have a question. [laughs] Oh, you mean one of our listeners?
Atwood: Yes.
Spolsky: Let's do... We have a really good question, but it's kind of long. Their all kind of long. I'm trying to find... Oh, here is a short question.
Paul D. Waite: Hi Jeff and Joel. I'm Paul D. Waite from Croydon, South London, England. I'm an aspring Mac programmer, but my experience so far is mainly with web development; Javascript, and Python. I'm looking to learn C for a foundation for working with Objective C on the Mac, and to hope to receiving an aproving nod from Joel. My question is: Where should I start? While most programmers don't read books anymore, I really like a comprehensive language book when I'm starting out. To give me an overview of the language, to teach me the nuts and bolts, and to hopefully give me a good common idea of good programming practices and idioms. If you've got any book recommendations, or any other suggestions of good resources for learning C, it would be great to hear them.
Spolsky: This is a question we can answer in seconds. [pause]
Atwood: Take it away Joel.
Spolsky: The C Programming Language by Kernighan and Ritchie. Otherwise known as K&R. And it is one of the best books about programming that you will find out there. The clearest and most concise. It's a simple language and it's a very clear book. It has a way of teaching you things with just little winks in the problems at the end of each chapter. So that is the book I would recommend. There really is no other decent C programming book that even worth looking at. So The C Programming Language, Kernighan and Ritchie, is worth learning C just to have an opportunity to read that book. So. I took that question because it was unbelievably easy. [laughs]
Atwood: Right. Well, can I warn this asker away from learning C? Is that possible?
Spolsky: Ahh... Sure!
Atwood: [laughs] Well, yeah, I would question... I mean, I wonder if you would really need to learn C or not. I mean, I don't know. This is the classic arguement we always have [Joel Laughs]. But if you are hell bent on learning C then sure, K&R is the book, but... Are there any other languages that you could learn that would, sort of, give you the experience of learning C without actually learning C? Is there anything close enough... Ok... Here is my question to you Joel. Is there anything close enough to C that gives you the C experience while being a little bit modern? Like, say, Objective C, or C++, or any variance of C that you consider consider acceptable?
Spolsky: [A firm, quick] No.
Atwood: No... It has to be the real C or nothing?
Spolsky: Yeah, I mean, if you want... You know what would be a good thing to learn? 68000 Assembler.
Atwood: [laughs] We are going in the wrong direction... [both laugh]
Spolsky: That's because you're trying to find a programming language that eleminates something from C, which is exactly the thing that I want you to learn. Also Objective C, before you learn it, it is a very good idea to learn C. As a foundation for that. If you wanted to go programming, C is a great way to... It's only going to add a couple of days at the beginning, and it's going to make your life so much more better. You know, I used to find these C++ programmers that had never learned C, and it was just sort of astonishing to watch them basically hit the wall again and again and again because they were missing some of the early concepts that nobody cared to explain to them.
Atwood: So did you learn C before learning C, you think?
Spolsky: Um... [both laugh] Learn C before learning C? No. But like I said, 68000 assembler is a very good assembler. It is one of the last assemblers that was designed to be written by a human being. Because, there for a while people did write in assembler, and the chip manufacturers would give them useful features that were helpful to programming. At some point they stopped doing that and they just said, "You know what, it's only compilers that are talking to us, so, why bother?" The motorola 68000, which was a very, very similiar to the PDP 11 assembler, which was entirely designed to be written by humans, probably designed before they thought there would be very many compilers. So.
Atwood: Right.
Spolsky: You don't have to learn Fortran. You don't have to learn COBOL. It's not C because it's old, it's C because of the pointers. And stuff like that. Anyway.
Atwood: The nasty bits, right?
Spolsky: Yes. The nasty bits. We have some good questions for next week.
Atwood: We'll do those first.
Spolsky: Sure. We'll do those first. And... Do we have any other announcements?
Atwood: Do you want to talk about the open house you guys are doing?
Spolsky: Yeah. There is an open house at Fog Creek and if you get this and it's, and you're listening to this on time... I know it takes people a while before podcasts wind their way down into your ears. But if you're in New York, and you are listening to this, and it is not yet Thursday July 17th at 5:00 P.M. then on Thursday July 17th at 5:00 P.M. we would like to the Fog Creek office. New York NY 535 8th Ave. That is in between 36th and 37th street, kinda on a smotzy [?] street here in the middle of the smarta [?] district. And we are going to be having an open house with, apparently... I was chastised for claiming on my website that there would only be gold fish. There will actually be... wine or cheese, or something. And you'll get to meet the Fog Creek interns, and the Fog Creek software management trainees, and our new sales department, and a whole bunch of interesting people, and of course the programmers who bring you FogBugz and Copilot. So if you're in New York, please come to that. I promise it will be be terrible, but you can leave at anytime. I also want to thank a lot of people, you know, Jeff, I don't know if you've been looking at a lot of the transcripts, but they pop up in a matter of a couple of days. Which is really awesome. People, whenever we post these things, we make available a wiki for typing in the transcripts, and a bunch of volunteers all over the world, most of whom I know only by their IP address... Come up to that wiki and write down everything that Jeff and I say word for word, including every nervous giggle, not-so nervous giggle, there is a lot of editorializing going on there. It's a barrel of laughs. And it's very useful actually to people who can't listen to this for various reasons, or don't want to listen to this. And, also, it allows everything we say to show up in Google searches, to be machine readable, basically, so people can find this. Otherwise, it's just audio. It's just bits. Lost. Forever.
Atwood: Yeah. Why can't Google index audio yet? They are really slacking off.
Spolsky: They... You know what? They probably could do for the purpose of searching audio, you don't have very good voice recognition just to search.
Atwood: I don't know. I listener wrote in with some machine transcription, and I was kind of appalled.
Spolsky: Yeah, it was appaling, but if you were searching for specific things they might have been in there. You see what I'm saying? Yeah, the machine translation is appaling, and I think, my personal experience has been the machine transcriptions are harder to edit than to just type right the first place. But, anyway. So I do want to thank some of the people that have been coming in and contributing. There is 70.56.88.179... [both laugh] Just kidding. Some of the people who identified themselves deserve a special call out; Josh Parris, Bernard Dy, Justin Standard, Jan Ives, Jeff Atoot... I can't pronounce anything these days: A. T. W. O. O. D, I don't know who that is. And user 126. user 143. 71.10.161... etcetera. Thank you very much for the transcriptions. It's really very much appreciated. And a lot of people have been sending in great questions, I didn't get to. There are about a dozen of them. But I didn't get to any of them. Except for the one easy one.
Atwood: How about next call, all questions.
Spolsky: Okay. But come up with something interesting. The questions. Let's see. What would you consider interesting? We want to get controversial things.
Atwood: Just whatever people send in. I don't have any specific guidance. Whatever they think would be interesting to hear about.
Spolsky: When i'm listening to them, you know what I'm doing right now? I'm sort of de-emphasizing the questions where somebody says, "Hey, will stackoverflow have this, that, or the other feature," or "How will you do this in stackoverflow?" The reason is that people haven't seen it yet. And so those questions are like, "Just hold on a second. Just look at it and you'll have lots of great questions." So hold off on the questions about StackOverflow because it's a little bit theoretical now. But anything we've discussed on the podcast is obviously fair play.
Atwood: Well, Joel, assign those to me and what I'll do is I'll do a blog entry on our blog summarizing those. So at least their questions get answered. You know what I mean?
Spolsky: Yep. Yeah, that's a good idea.
Atwood: Because I don't want to feel like we're throwing away their questions. They took the time to record them and send them in, so I do want to answer them.
Spolsky: So if you do want to ask a question. Everybody recommended that I get Grand Central. That was the #1 recommendation. I tried to sign up for that, but it's like a waiting list or something. I might as well... It's like the iPhone 3G, except, at least the iPhone 3G if you wait in line for 6 hours you can get it. Where as Grand Central, you put your name in a box and they ignore you. So if any of you work on Grand Central, or know anybody there, could you please approve my application to become a member of Grand Central? And that way we could set up a phone number to take questions. Failing that, there are some other services that were available, but the real thing that we will do is get our Asterisk server hooked up to do it. Unfortunatly to do that we need a direct-inward-dial number, and unfortunately we don't have that in this office, but we will have that in the new office. So we may not have a phone number for you to call in to ask those questions until September, when we move into the new Fog Creek office, and then I'll set that up. In the mean time, you've got two choices:
1) is you can record an MP3 or OGG voribis file using your computers microphone, and recording software, and e-mail it to podcast@stackoverflow.com; Or
you can go to cinch.blogtalkradio.com.
And as usual, Jeff will link it in the show notes. And thats a little service that lets you call a phone number and get an MP3 that you can then send us. And a lot of people have been doing that. It's very easy.
Atwood: So, Joel, were you just asking for preferential treatment? Is that what I heard?
Spolsky: Yes. I would like some preferential treatment. I would like my friggin Grand Central account please.
Atwood: [laughs]
Spolsky: I'll pay for it!
Atwood: I'm just kidding.
Spolsky: You know. All these things get aquired by Google and then they shut down. Because they can't take as much traffic as the Google audience will bring them. So they rebuild the whole thing in Python, or whatever it is that Google likes to rebuild everything in, and in the mean time they are closed for a year or two. I think that's where Grand Central is at right now.
Atwood: I see. It's probably writen in in C. They have to rewrite it now.
Spolsky: [laughs]
Atwood: So I think that's probably it for this week.
Spolsky: Yeah! Sorry I was so grumpy at the beginning there.
Atwood: That's alright. Not a problem.
Spolsky: Let's just delete this whole show and do it again next week.
Atwood: [laughs] Nah, I think it was a reasonably good show. We can probably ship it. Just like software: it doesn't always come out the way you want. [both laugh]
Spolsky: Alright. Ship it!
[1:10:08 - ends]
Advertising, outtro
[1:11:07]
