Drepus editing 49:04-49:40

[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: Well, because they don't want to be productive. They want to have a good time at work. That's not what the bosses want though, the people that are paying them, so why not let the people who are paying them decide how they..?

Atwood: Well I think that for the type of people you're hiring to do software -- can you really even know what they're doing? On some fundamental level, it's really difficult to judge or even really tell if a program is correct, right? Does it really even do what we want it to do? These are very hard things to judge. So for the type of people that you're hiring to do programming -- not to, again, put us on a pedestal or anything -- I think these are the type of people that really can self-organize, to some degree, their working organization. With some degree of trust. Versus, say, factory line workers or janitors or, I don't know... maybe I'm completely wrong. But I feel like that's a more flexible situation than "hey, everybody gets an office" or "hey, everybody gets these incredibly depressing little cubicles" like the one you were telling about last week downtown.

Spolsky: Oh, yeah, they're not that [depressing?]. You know, it's actually... I don't know if it's ever possible. Usually the development team has no say whatsoever on what kind of offices they get. These leases, commercial leases, they're ten year leases traditionally. You're in a place, it's been built, it is what it is. Changing it is ridic-- it's just beyond impossible. These decisions are made very very rarely, and when they're made, they're usually made by some office manager's second assistant who is in charge of figuring out where the programmers would sit. Who, possibly, if you're very lucky, got to work with an architect, and the architect knows nothing about what spaces are right for programming. And architects have all their crazy metaphors like, well, "an open space fosters open communication." Which is not true [laughs] and is not actually what's happening in the space, but sounds good, and might be something he might have read in an architecture magazine somewhere. So nobody knows what they're doing when they're planning these spaces, and they make terrible spaces. And there are a few examples I like-- I think Microsoft had some flexible workspaces at one point, where they actually come in, they raise the floors so that you can rearrange the ductwork. Which is the main reason you raise the floors, so that the ductwork can be rearranged well. And because you have to have ventilation in every room. And then instead of drywall walls they use these furniture systems that go all the way up to the ceiling. So it looks like a wall but it's actually a part of a furniture system, much like a cubicle system. And that allows them to rearrange things kind of at will, very rapidly, according to what the team wants to do. So there are a couple of workspaces like that at Microsoft and that seems to be the new trend, and I've heard of them at Microsoft Research specifically. There's a really good video that Scoble did, I think, somewhere.

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 number field from the user table and we didn't figure that out until later.

Spolsky: So the trouble that you're is, that by the time they, uh, they finally solved this problem of object-relational mapping...well, I don't want to say they've solved it, because there've been so many proposals...

Atwood: Oh, it's not solved.  It's not solved.  This is very lightweight though.  What I like about LINQ SQL: flexible, very lightweight, and built into the language.  Those are really the key things that make it workable for me, 'cause, I've gotta be honest with you, I do not like--my feeling on object-relational mapping is, it's called the Viet Nam of computer science for a reason, 'cause there's really no good way to do it, in my opinion, that solves all the problems that you're inevitably gonna have.  You just sort of pick some pros and cons and run with it.

Spolsky: Yeah.

Atwood: I lean heavily towards the data side of that.  'Cause you don't have a problem if you do away with either the database or the objects.  Then you just have one thing.  It's kind of radical.  Right?  To say, hey, we don't even have a database, we just have a bunch of objects that we persist to disk, y'know, just magically.  Right?

Spolsky: No, but that's really irritating, because the code that you would use--hhah--because there's things you would do in a database, like selecting a single column, that to do, if you just had a bunch of objects, would be enormously wasteful.

Atwood: Oh, totally!

Spolsky: Let's say, for example, that I--all I'm doing is persisting a bunch of telephone numbers to a database.  I've got the C user-with-telephone object, it's got 47 fields, for their billing address, and their last-payment-due, and all kinds of stuff, 'cause I'm the phone company and I'm listing every telephone number.  And now I wanna do a query which is like, you know, "What area code has the most phone numbers?" or something.  So I don't need any of the extra data, I don't need to load and instantiate all these objects, I just need to do a SQL query, a very basic underlying SQL query, and the entities would just get in my way, or just be a really inefficient way of getting that particular thing.  Y'know, I just want to do "SELECT count(*) FROM blah-blah-blah WHERE blah-blah-blah AND blah-blah-blah AND blah-blah-blah;", and the database is gonna look at that, and in a millionth of a second, it's gonna tell me, "37".  I don't wanna have to create a million objects and then filter them, and so forth.  Ah, so, there's these whole classes of things that ORM doesn't really solve, that relational databases do solve.  Or, I don't wanna say ORM in general, but just mapping objects, just pretending that all I'm doing is taking an object and freezing it, persisting it, or pickling it and throwing it in the database.

Atwood: Right, right, no no and actually I agree with you because on the continuum of ok, pure objects versus pure database where you don't, literally don't have a problem because the other thing doesn't exist.  I lean heavily toward the database side, like I've always viewed the data as the model.  Which this is this is heresy to a lot of people so I apologize, but what I find is..

Spolsky: I think you're right, yeah you're right.

Atwood: LINQ SQL is the lightest possible layer of object you can put over that and get away with it and not have people complain, which is what I like about it.  Plus I can still do raw SQL and CAST it to whatever object I want, if I want to.

Spolsky: Now here's the other problem, the other reason I haven't even started using Length.  The first reason I didn't start using it is that I saw immediately that for various Intellisense reasons it has an upside down syntax where you say from BLAH BLAH BLAH select etcetera and it has taken me... ah, how old am I 43 years to learn SQL as well as I know it now and just the idea of like coming back and learning, eh some kind of a backwards upside down SQL after all that effort I went into learning exactly how to do it is, uh, very frustrating.  So I was frustrated that it couldn't just be SQL.

Spolsky: Now here's the other problem, here's the other reason I haven't even started using LINQ, and the first reason I didn't start using it is that I saw immediately that for various Intellisense reasons, it has an upside-down syntax, where you say, "FROM blah-blah-blah SELECT...", et cetera, and it has taken me--aw, how old am I?--forty...three years to learn SQL as well as I know it now, and just the idea of, like, coming back and learning, uh, some kind of a backwards, upside-down SQL--[laughs]--after all that effort I went into learning exactly how to do it...is, uh, very frustrating.  So I was frustrated that it couldn't just be SQL.

[50:08]

{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]

Drepus editing 49:04-49:40

[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: Well, because they don't want to be productive. They want to have a good time at work. That's not what the bosses want though, the people that are paying them, so why not let the people who are paying them decide how they..?

Atwood: Well I think that for the type of people you're hiring to do software -- can you really even know what they're doing? On some fundamental level, it's really difficult to judge or even really tell if a program is correct, right? Does it really even do what we want it to do? These are very hard things to judge. So for the type of people that you're hiring to do programming -- not to, again, put us on a pedestal or anything -- I think these are the type of people that really can self-organize, to some degree, their working organization. With some degree of trust. Versus, say, factory line workers or janitors or, I don't know... maybe I'm completely wrong. But I feel like that's a more flexible situation than "hey, everybody gets an office" or "hey, everybody gets these incredibly depressing little cubicles" like the one you were telling about last week downtown.

Spolsky: Oh, yeah, they're not that [depressing?]. You know, it's actually... I don't know if it's ever possible. Usually the development team has no say whatsoever on what kind of offices they get. These leases, commercial leases, they're ten year leases traditionally. You're in a place, it's been built, it is what it is. Changing it is ridic-- it's just beyond impossible. These decisions are made very very rarely, and when they're made, they're usually made by some office manager's second assistant who is in charge of figuring out where the programmers would sit. Who, possibly, if you're very lucky, got to work with an architect, and the architect knows nothing about what spaces are right for programming. And architects have all their crazy metaphors like, well, "an open space fosters open communication." Which is not true [laughs] and is not actually what's happening in the space, but sounds good, and might be something he might have read in an architecture magazine somewhere. So nobody knows what they're doing when they're planning these spaces, and they make terrible spaces. And there are a few examples I like-- I think Microsoft had some flexible workspaces at one point, where they actually come in, they raise the floors so that you can rearrange the ductwork. Which is the main reason you raise the floors, so that the ductwork can be rearranged well. And because you have to have ventilation in every room. And then instead of drywall walls they use these furniture systems that go all the way up to the ceiling. So it looks like a wall but it's actually a part of a furniture system, much like a cubicle system. And that allows them to rearrange things kind of at will, very rapidly, according to what the team wants to do. So there are a couple of workspaces like that at Microsoft and that seems to be the new trend, and I've heard of them at Microsoft Research specifically. There's a really good video that Scoble did, I think, somewhere.

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 number field from the user table and we didn't figure that out until later.

Spolsky: So the trouble that you're is, that by the time they, uh, they finally solved this problem of object-relational mapping...well, I don't want to say they've solved it, because there've been so many proposals...

Atwood: Oh, it's not solved.  It's not solved.  This is very lightweight though.  What I like about LINQ SQL: flexible, very lightweight, and built into the language.  Those are really the key things that make it workable for me, 'cause, I've gotta be honest with you, I do not like--my feeling on object-relational mapping is, it's called the Viet Nam of computer science for a reason, 'cause there's really no good way to do it, in my opinion, that solves all the problems that you're inevitably gonna have.  You just sort of pick some pros and cons and run with it.

Spolsky: Yeah.

Atwood: I lean heavily towards the data side of that.  'Cause you don't have a problem if you do away with either the database or the objects.  Then you just have one thing.  It's kind of radical.  Right?  To say, hey, we don't even have a database, we just have a bunch of objects that we persist to disk, y'know, just magically.  Right?

Spolsky: No, but that's really irritating, because the code that you would use--hhah--because there's things you would do in a database, like selecting a single column, that to do, if you just had a bunch of objects, would be enormously wasteful.

Atwood: Oh, totally!

Spolsky: Let's say, for example, that I--all I'm doing is persisting a bunch of telephone numbers to a database.  I've got the C user-with-telephone object, it's got 47 fields, for their billing address, and their last-payment-due, and all kinds of stuff, 'cause I'm the phone company and I'm listing every telephone number.  And now I wanna do a query which is like, you know, "What area code has the most phone numbers?" or something.  So I don't need any of the extra data, I don't need to load and instantiate all these objects, I just need to do a SQL query, a very basic underlying SQL query, and the entities would just get in my way, or just be a really inefficient way of getting that particular thing.  Y'know, I just want to do "SELECT count(*) FROM blah-blah-blah WHERE blah-blah-blah AND blah-blah-blah AND blah-blah-blah;", and the database is gonna look at that, and in a millionth of a second, it's gonna tell me, "37".  I don't wanna have to create a million objects and then filter them, and so forth.  Ah, so, there's these whole classes of things that ORM doesn't really solve, that relational databases do solve.  Or, I don't wanna say ORM in general, but just mapping objects, just pretending that all I'm doing is taking an object and freezing it, persisting it, or pickling it and throwing it in the database.

Atwood: Right, right, no no and actually I agree with you because on the continuum of ok, pure objects versus pure database where you don't, literally don't have a problem because the other thing doesn't exist.  I lean heavily toward the database side, like I've always viewed the data as the model.  Which this is this is heresy to a lot of people so I apologize, but what I find is..

Spolsky: I think you're right, yeah you're right.

Atwood: LINQ SQL is the lightest possible layer of object you can put over that and get away with it and not have people complain, which is what I like about it.  Plus I can still do raw SQL and CAST it to whatever object I want, if I want to.

Spolsky: Now here's the other problem, the other reason I haven't even started using Length.  The first reason I didn't start using it is that I saw immediately that for various Intellisense reasons it has an upside down syntax where you say from BLAH BLAH BLAH select etcetera and it has taken me... ah, how old am I 43 years to learn SQL as well as I know it now and just the idea of like coming back and learning, eh some kind of a backwards upside down SQL after all that effort I went into learning exactly how to do it is, uh, very frustrating.  So I was frustrated that it couldn't just be SQL.

Spolsky: Now here's the other problem, here's the other reason I haven't even started using LINQ, and the first reason I didn't start using it is that I saw immediately that for various Intellisense reasons, it has an upside-down syntax, where you say, "FROM blah-blah-blah SELECT...", et cetera, and it has taken me--aw, how old am I?--forty...three years to learn SQL as well as I know it now, and just the idea of, like, coming back and learning, uh, some kind of a backwards, upside-down SQL--[laughs]--after all that effort I went into learning exactly how to do it...is, uh, very frustrating.  So I was frustrated that it couldn't just be SQL.

[50:08]

{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... Atood? I can't pronounce anything these days: A. T. W. O. O. D, I don't know who that is... Justin Standard...

Atwood: Yes nice...

Spolsky: 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]