View  Info
 

Podcast 014

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 Rock Band 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 buy 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 Townsend or some member of The Who (Roger Daltrey maybe) 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.  But yeah.

Spolsky: [grunts acknowledgment]

[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: [grunts encouragement]

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 thirteen 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 ten 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.  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 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 grayed 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, they 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 dialog 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 help files, 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.  Yes, I have failed.

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 then people 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 embarrass 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 actually 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 very 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 "Okay 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 Hacker News 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.  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.  More importantly, 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.  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 a pretty good news - community news aggregator which is, Hacker News at news.ycombinator.com which is set up by Paul Graham at Y Combinator and is populated by 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.  Do this-

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" - are written, actually, with 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 conclusions which are rather interesting.  So in Good to Great there's this interesting conclusion that 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?  

Spolsky: I know! 

Atwood: 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.  Bizarre things like that, that do correlate.  So anyways - I think this is the right book Good to Great, I should double check on that - but there are actually books that are out there that are the result of enormous amounts of research, or enormous amounts of scientific data, I mean books based on loads and loads of actual findings 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 least 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 "okay, maybe they should try this."

Spolsky: Yeah.

Atwood: How is that a net negative?

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: [laughs] 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: You wouldn't want to win 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...  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.

Spolsky: 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 shows you can find there where he just says the same thing.  Anyway, 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 picture 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 complexions.  It's just guaranteed.  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 no longer allowed to live in this house, so they're sad.  And that's guaranteed.  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 criticizing that in particular.  Unfortunately, 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 weasel 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 weaseling 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 desperate 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 weasel words in the article, but there's no actual truths 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.

Atwood: Well, the anecdote was not associated with data.  I think that anecdotes plus data is actually very effective.  But again, this is where you have to be a critical reader.  I mean, are they giving you one data point, which is their friend?  Are they giving you no data points, or are they using just random words to simulate the idea that they have some data when it's really just a general impression that they have of something?  So really, I guess, just, demand data where you can get it, and if you can't get data... I mean, let me use my recent post as an example.  So I was talking about normalization of data.  And I didn't really say, "Do normalize" or "Don't normalize," but "measure your queries, and figure out what works based on the data that you're getting through your system."  And this is something... The reason I wrote that post was because on Stack Overflow, one of the very first things we did was say, "okay" - and I do this on all of the projects that I work on - "I want to know how long every query is taking.  I want to know how many there are, and I want to know how long they are taking."  Not that I'm going to, maybe, obsess over every little query. Maybe I will. But I just want to know, right? I want to see the data.  So when I make decisions about, oh, let's change the database, it's not because I feel like it's better Feng Shui of having a database, but because it'll actually make the database faster.  To me, response time is really really important.  So if I can shave 40-50 milliseconds off a page load, to me, that's worth it.  So even though I can't tell you, I'm basing it off a very limited experience.  I haven't worked on every project in the world; I'm not, like, a database expert or anything.  But you can measure your own stuff, right?  This is easy for programmers to do.  And then you can make a decision based on it, rather than, "Oh, I was taught that everything has to be normalized."

Spolsky: But now you're just teaching people that everything has to be measured.

Atwood: Well, how is that bad? That's science. Isn't that science in a nutshell? Science is pretty much measuring.

Spolsky: Because you don't measure things until you have a problem. I would say don't bother even measuring that until you start to see that the response time doesn't feel snappy. And then say, "Why doesn't the response time feel snappy?"

Atwood: Well, but, that's relative. Have you ever... Okay, so if you're a gamer, you'll notice this form where some people go into a forum and say, "Oh my God, this game is so slow.  It's unbelievably slow, I can barely even play it."  And other people are like, "Oh, fine. Works fine for me."  Because the two people's relative impression of what's slow and what's not is totally not even the same.

Spolsky: So you may have... it's okay to say, like... that's fine.  So you want to say, "I have an acceptance criterion for this type of application. I want 100 millisecond response time.  Therefore ... we'll test against that.  And only then will we actually measure how long the queries are taking, or how many queries there are in a page."

Atwood: I don't know.  I think it makes sense to always measure, particularly in a world of, you know, computers, where everything is really pretty easy to measure.  Is there anything on the computer that is really that hard to measure?  I mean, everything is just ones and zeros.

Spolsky: Well, for example, we have an internal app that we use that shows us how much commission is due to the sales people that I just wrote.  Should I be measuring how long those queries take?

Atwood: Um... maybe not for an internal app.  But actually...

Spolsky: Alright, so there are cases where you measure and cases where you don't.

Atwood: Yeah.  Well, I would still measure it, because you might want to... But you might throw away that data.  But the advantage of having it outweighs the advantages of not having it, I think.

 

Spolsky: The advantage of not having it is that I didn't have to spend time measuring anything.  I just put the SQL query in, and lo and behold, I got a result, and it came up in a kind of fast enough... I think it was okay.

Atwood: Right. But...

 

Spolsky: That was the end of that, and I moved on.

 

Atwood: These data access layers tend to have that built in.  At least ours does.

 

Spolsky: Like, I should be able to just turn this on and look at it and ignore it, or look at it.

 

Atwood: Yeah, exactly, that's what I'm saying.

 

Spolsky: Well, back to the original thought, whether or not that's germane... The anecdotes are very useful, because actually, hearing a lot of anecdotes, even if, no: the author doesn't have an agenda, he's not trying to convince you of anything, he's just telling you a story... The more of these stories you hear, the more you'll start to learn "Oh, wait a minute this is a recurring refrain," or maybe there is a particular solution.

Atwood: But your post didn't even have one anecdote.

Spolsky: Oh, I know, that was short.

Atwood: Before, you told me... so it was based on the [Windows] Media Player. Even having that one example would have made it a much much stronger version.

Spolsky: Oh, yeah yeah yeah.  That article would have been great what I had said is, "I was listening to Jeff Atwood the other day, and he said that I could speed up podcasts, and I wanted to speed up the podcasts playing in Windows Media Player.  And I went there, and it was grayed out. So how the hell am I supposed to do this?"  And then I could have said, "Guys, don't gray out things unless you're gonna give me some kind of clue what I'm supposed to do."

Atwood: But you know what's funny about that?  I guarantee you it'll turn into a hate fest of Windows Media Player.  I guarantee it.  That's hilarious.

Spolsky: So I think we agree, we always do end up agreeing on everything, which is something that there is some criticism -- we've been receiving criticism for agreeing too much.  I think we agree that an anecdote would have been much more powerful and wouldn't have been making as strong a claim, and yet it would have been one of those things that would accumulate, would allow everybody to gain the wisdom of a lot of different experiences. So they would be thinking up a lot of use cases when they design things.  They would be thinking of -- when they disable that thing, you know, it would just give them a story that would remind them that when they're disabling that menu item, "Am I leaving my user without recourse or with no way of figuring out how to ever get this capability if they can't get it right now?"

 

Atwood: Well, actually I don't agree that we agree [chuckles].  I don't--

Spolsky: Yes we do!

Atwood: The post, as you put it up--

Spolsky: [laughing]  I [hate?] this guy! What the-- [Spolsky and Atwood try to interrupt each other] Don't I have a button to [mute?] you?

 

Atwood: Well, seriously, the post as you put it up was just really ineffectual.  Like, I wouldn't -- definitely wouldn't have published anything like that.  Because, I mean-- [experiment] and all

Spolsky: I agree, it was an experiment which proved that you can't do this.  It was a failure.

Atwood: But you're also sort of gaming the audience a little bit, which I think is a little -- a little dishonest if that was your goal.

Spolsky: No, no, it wasn't my goal, my goal was to see... I thought, actually, that it would work, to post some simpler, shorter posts, um...

Atwood: But it was too short.  I mean it's--

Spolsky: OK.

Atwood: Again you... I don't know.

Spolsky: But how do you know it if you don't measure?  The only way to measure is to try posting something that's too short and see that it doesn't work.

Atwood: Well there wasn't even like one example, I mean like -- plus you didn't cover any of like, "Here's some other ways apps do this."  It could have been like -- you could have -- made it three times as long, which is still pretty short by your standards.  It would have been a much stronger article.  It wouldn't have been misinterpreted as much.

Spolsky: Oh, we learned that, didn't we.

Atwood: It wouldn't have taken that long either. [chuckles]

Spolsky: We learned that.

Atwood: Yes.

Spolsky: We have a couple more examples of, er- I do think that there is something about anecdotes, which is that they don't really prove a point.  If I had given one anecdote and then said, "This proves that you should never disable menu items", I-- In other words, we got two- we got three possible things that I could've done.  One is that I could've posted what I did, which is "Do this, don't do that."  Uh, number two: I could've given some examples or anecdotes. So it would've been, you know, "Do this, don't do that because 'A', 'B', 'C'."

Atwood: Right.

Spolsky: And that's what I've done for years, actually, if you haven't noticed.  And I've been feeling kind of guilty about it.

Atwood: Well, but, you also put tons and tons of words in-between. I think you could've just said, <the stuff you want to say>,  <example>,  <sentence>, <example>, <sentence>, <example>, <sentence>.

Spolsky: So I could've done this like one of those design patterns.

Atwood: Yes.

Spolsky: Like, shown a couple good examples, a couple bad examples, and just done it like a design pattern.  Yeah.

Atwood: Yes.

Spolsky: That's a page of- Yeah, um- Now, the other thing I could've done -- which is something I'm going to be experimenting with increasingly -- and I'm doing this as much as my editor lets me get away with it in Inc. Magazine, where I have a monthly column- Which is, you know- And it's part of just getting to the age in my life where I don't feel like I know anything. [laughter] [Where is that nothing is helpful.]

Atwood: [laughs] Wait, wait. You're going backwards!  You're going backwards!  So as you get older you feel like you know less and less?  Is that what I'm hearing?

Spolsky: Yeah, you're on the other side of that hump.  You learn - know - more and more and more until you get to a certain age and then you know less and less and less.  Um, anyway... [laughs]  Did you ever learn a second language, Jeff?

Atwood: No, I did not actually... well, no, I know Spanish.  Took a lot of years of Spanish in high school and middle school.

Spolsky: Okay, so, you can translate things to Spanish, right?

Atwood: I know enough to be a little bit dangerous in Spanish, that's about it.

Spolsky: Like you can say things like, um, "Excuse me, is the cow on your table?"

Atwood: Yeah.  I could get by in Mexico if I was stranded, barely.

Spolsky: So, like, how do you say "table" in Spanish?

Atwood: Uh... I don't know. [laughs]

Spolsky: Probably-

Atwood: I know enough of... really basic words.  It would be like speaking to a child, really.

Spolsky: Okay.  Uh, well, what happens as you're learning a language is you go through a few phases.  In the first phase you can't say anything, because you don't know enough words.  And in the second phase it's just real easy, you know all the words, you've learned the vocabulary, you're like "blah blah blah blah blah."  The third phase you start having -- in the third phase you start to have all these doubts.  Because you try to translate a word, and you know about all the shades of grey and the way this word is not exactly like that word in this particular language, and dialects and... you know.  Yeah, you could translate that, that would be the same thing, but it wouldn't convey the same sense of existential angst that that conveys in the original German.  And so, as you become a better and better translator, you actually get worse at simultaneous translation.  Because you start to get confused about the various synonyms and shades of meanings and the cases where the words don't exactly overlap.

And so, training people to be translators, actually -- or simultaneous translators -- is in part training them to get to that next level of skill, which is above and beyond just knowing both languages, where you can actually translate quickly, because you don't -- you've removed all this kind of doubt that you gained in the phase where you were learning all the shades of grey and all the details and the minuscule.  And I think that's something that happens a lot, I think that you start your career out saying, "You know, I don't know anything about this software development process, but I'm eager to learn," and you read a lot and you read a lot of blogs and you listen to people and you talk to people and you go to conferences and whatever it is that helps you learn your field, and you just practice.  And you learn more and more and more and more.

And as you start to get those first anecdotes and the second anecdotes and that particular story about the way a particular manager in your first job did a particular thing and it worked, or didn't work, you start to form rules from very little information.  And you start to say things like "never throw away all your code, you can't throw away all your code and start over.  Think of how far behind that will put you in the competitive world if you throw away your code and start over."

 

Atwood:  And you have said that.

Spolsky:  Yeah, you will say things like that, and that was based on a decision--partially it was based on a few anecdotes which are mentioned in that story, of companies that did that and failed, and so I think it's correct, and that that is where the overwhelming evidence is: that once you have shipping code you probably shouldn't throw it all out and start over--in a large system, not in a small system.  You can throw out pieces of it and start over. 

Atwood:  Well, people kind of gloss over, too, that, first of all, it took a long, long time.  It was, like, five plus years.  Also, the business model totally changed.  Where does Mozilla get their money from now?  It's a totally different world -- they get it from Google, basically, right?  Through the fact that Google is integrated into the application.  Every time somebody searches in Firefox using Ctrl-E, the search box, they get, like, a penny (or whatever).

Spolsky:  I still think that was right.  Anyway, the point is that you get to this point in your career where you start to feel like you actually do have all the information about a lot of things.  And that was the grand old halsee... halcy... halcyon--there's a word I can't pronounce--

Atwood:  HAL-see-yahn, I think, is correct.

Spolsky:  --days of Joel on Software.

Atwood:  I'm really not the person to ask on pronunciation, but go ahead.

Spolsky:  The halcyon days of Joel on Software.  I sort of had that confidence, I'd sort of come of a really--ten years of working in software development, and reading a lot, and talking to a lot of smart people, and working in some places where they really knew what they were doing.  And I basically just sort of dumped down the knowledge that I had learned in those ten years as quickly as I could.  But over time you start to realize that there are actually all kinds of weird shades of grey, and slightly different variations on things, and it becomes harder and harder to make absolute statements that are interesting.  Because, if I were to write an intellectually honest blog post now, it would be like, "63% of the time--you're probably in a situation, where, 63% of the time, you should do A, and the rest of the time you should do B.  Here's some cases where you would do A, and some cases where you should do B," and the whole thing would just be too mushy.  Nobody would wanna read it, it would be all full of--for example, one thing that I was pretty absolute about is the idea that programmers should have private offices.  Which I still believe, that programmers are much more productive with private offices, and they're more willing to work for you if you give them private offices, because the conditions are better. 

However, since I have said these things, I've learned that a lot of programmers actually prefer to socialize, and not have private offices, because they think of it as being more sociable and more fun.  And they are less productive for it, and they're not going to admit that, they'll tell you "Oh, well, we're having accidental productivity," or whatever.  But it's just more fun for them.  And so one of the reasons that there isn't as strong of a movement towards private offices as I think there should be based on the productivity gains and the recruiting gains that you could get, is that a lot of programmers imagine private offices as being lonely compared to their very, very social workspace where they're laughing and chatting and joking and talking about the bar they went to the night before, pretty much all day long.  But that's just a big old caveat, and am I supposed to put that caveat on everything that I say?  I still think that private offices are the way to go, it's just that as I've learned more about the shades of grey, the kinds of things I might be able to say about particular topics become more muddled and more boring.

And so, what I'm going to do, and what I'm doing in Inc and what I will do on my blog I guess is I'm making a real strong push towards anecdote only.  In other words, my whole job is just to tell you stories.  And whether or not they're relevant to your life is your problem to figure out and if they have a moral they have a moral and if they don't, they don't and maybe there's a little plot there and maybe there isn't a plot there and maybe you can figure out the moral.  But I don't have any kind of agenda in the stories that I'm telling.  That's what you'll see increasingly -- you'll see me doing increasingly in Inc Magazine.  And on my blog.

Atwood: Well, I think storytelling is very fundamental.  And I think, also, if you want to include some data, I think that you could kinda have it both ways.  But you don't have to.  Like for example on the private offices thing: I think the most radical form of that is when you actually take a small group inside a company and say "look, you guys can configure your workspace how you want it to be."  Because there are certain developers that just want the private offices.  They just like to be isolated.  They don't like to have people all up in their grill all day.  And those people will be more effective if they work in an office.  Whereas, if they were at some workplace where, okay, everybody does X or everybody does Y... why not let the group configure the workspace the way that they want to?

 

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, [pretentious voice] "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: Now I'll have to track that down.  You've added work to my list.

Spolsky: I'm sorry.  Don't do it!  Just don't do it!  There's somewhere among--

Atwood: No, I have to do it.

Spolsky: --videos that, I believe it was Scoble, maybe it wasn't Scoble, anyway.  It's about an hour at Microsoft Research, following around some guy, looking at their office base and how they did everything and how they collaborate and how they can rearrange their space at will.  And I think what's interesting is that people probably won't rearrange it very much.

Even though they can.

How did we get on to that?

 

Spolsky: I'm sorry.  Don't do it!  Just don't do it!  There's somewhere among--

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 haven't 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 you could write your application that way, where you just query stuff out of the database, and you are just directly working on these essentially arrays that come back from the database, but it is kind of awkward.  Particularly 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 redundant.  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 known as 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'Reilly, or whatever we are going to change it to and then user dot, 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 Relational 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 squirrelly on the versions.  They've become very "dynamic" in the way that they number the frameworks.  To put it charitably...

Spolsky: It's based on whatever their checkin, their last checkin to source code repository. 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 invoice 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 indexes, they figure it out ...

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 actually 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 list 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 dot-where and then add a clause, and it's all typed code.  So the other problem with SQL is that it's strings.  Your compiler doesn't know anything about the SQL, it's just 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 traditionally 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 have 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 -- [exasperated exhale] --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 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, 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 very frustrating.  So I was frustrated that it couldn't just be SQL.

Atwood: Right -- it is aggravating, but the advantage of learning it is that it's applicable to any circumstance, not just the data circumstance.  Say you have an array: you can apply LINQ methods to the array to get the data back out of it, or some just class -- some random class that's like a data structure that you have.  Any fundamental data type, you can use these constructs so the power of having sort of semi set-based logic built into the language-

Spolsky: So you're good with LINQ -- have you done that yet? Have you done that yet?

Atwood: Have I done what?

Spolsky: Used LINQ on something other than a SQL database.

Atwood: Uhh... not currently.  I, like you I'm still struggling, I mean there's definitely a learning curve.  I don't wanna, [Joel Laughing] I don't wanna underestimate it, seriously, I'm not kidding.

Spolsky: I believe this may be an over-sold feature that you may wind up not actually needing in daily application development. [garbled as Joel and Jeff talk over one another]  I think the ability to do queries on in-memory things like arrays -- why do you even have an array?  Who has an array anymore? [Jeff chuckles]  No seriously!  It's a table!

Atwood: Hold on, hold on.  I actually, in my HTML... so I have two sets of code.  One that does HTML tag balance, and one that does sanitizing HTML.  And for the tag balance, I have an array of regular expression matches -- so it's an array, but it's not an array of like integers, it's an array of some kind of object, which you use generics for that, right?  Like array of type whatever... so yeah, no I definitely use it.  And I was playing with using a stack, I think some of these fundamental data structures are still used...

Spolsky: Right right, well alright.  So I'm looking at the world a little bit from the perspective of people who are building data driven kind of CRUD-type applications basically.  Which is who LINQ is designed for really, it's not designed for the people who are building operating systems and need an array of memory allocations or something.  You don't really use arrays that much... I'm trying to remember the last time I met an array in any of the database code that I've been writing... So wait, so, here's the second, uh, here's my second thing about LINQ -- or ORM in general -- is like you say it's the Vietnam, it's the unsolved problem of um... Vietnam, I think, was solved, I guess [Jeff laughs] might want to find a different metaphor.  Um the uh... nobody really solved the ORM problem completely, LINQ is a nice lightweight way of doing it.  Actually, Microsoft, especially in the development tools group has a pretty good track record of going into problems that have been big thorny hairy problems and not really solving them but doing something kind of lightweight that gets you a lot of the way there.  And I'm thinking of MFC as a great example: trying to create these big highfalutin object-oriented graphical development environments just failed again and again and again and again, and MFC they just finally just said, "let's just do some lightweight wrappers around the Windows API to make it a little more object-oriented and we won't be too ambitious but we'll still save everyone a lot of work" and they weren't and they did.  But think about this: I've got a database, and it has a customer record, and it has first_name, last_name, address, dot dot dot, it's got a bunch of stuff in there.  So it's got address_first_line, address_second_line, suite, apartment, ummm... city, state, zip, country, phone_number, billing_address, shipping_address... it's got all that.  Suddenly you have 23 fields to keep track of a customer that everybody else has -- which is annoying which is why the hell doesn't the SQL Server team yet have a first class address data type that knows about addresses all over the world, we have to keep writing this code again and again but I'll move on -- I won't complain for now.

Atwood: It's a good point.

Spolsky: It's just ridiculous there's all kinds of stuff.  You know what?  There's weird stuff about addresses: in Yugoslavia you put uh... well, sorry Serbia, you put the country name first, and then the city, and then the street, and then the guy's name.  And you know what, Microsoft Word knows that and when it does mail merge it will do that for that address in Serbia.  And it's not impossible to have this knowledge and to wrap it up and it should be done by... you know?  There's a great feature for SQL Server 2008, and there's a great feature for the next version of HTML giving an address editor that is just universal, you know? And yes I know: it would have to know about all sorts of weird addresses in Serbia, but it's not the end of the world, it is possible to write that code and having it in one place would be a great thing... um... so wait.  That was just a crazy distraction.  You've got these 27 fields, street_address, city_name, etc, and what the object relational mappers do is they get those things into properly typed variables in your source code.

Atwood: Right.

Spolsky: And that's great, And that eliminates a lot of these big blocks of code that you used to have where you'd have 22 lines of copying out individual fields, casting them to the appropriate type, and setting them to variables which had the same name as the column name in SQL.

Atwood: Yes -- it definitely saves time.

Spolsky: 22 lines, pssht, gone.  That's great.  The next problem is now I need to put it into my HTML page and I have all these HTML controls that need all their text values assigned. [gasps]  And what LINQ doesn't do is it doesn't go that step for you, yet.  In fact, it was actually, it seemed to have been written, and I might be missing something gigantic here, but there seemed to have been two big things that we got in Visual Studio 2008: 

The first was this ability to embed our SQL right in the HTML page, and have these data bindings, and have it all happen in a declarative fashion, so those variables never stop in your code, they're never seen in your code, so you don't need variable names for them, they go literally directly from the database column, and all you've got to do is map a database column to a particular ASP.NET control that's on a web page; 

And then there was the LINQ guys that were doing something completely different, which is they were getting that stuff into C# land (or VB.NET land) and you can sort of do one or the other and they each solve half the problem, so it's kind of -- there's kind of a new impedance mismatch which is we have finally solved the problem of getting all of these columns into our programming language, but we don't even want them in our programming language, we want them on our HTML page.

Atwood: Even in Rails land, where they have the flexibility of essentially redefining the language at will, to solve all these problems -- at a steep performance cost, obviously, but still, the productivity is worth it -- they still, if you look at the HTML that they emit, it's still a mishmash it's basically tag soup.  It's like HTML tag, and then a left-begin tag -

Spolsky: That they emit, or they write?

Atwood: Well, no no no, these are just template files, these are files on disk that are essentially mail-merge forms, right?  There's little holes where you push in the data, and--

Spolsky: Right, yeah, the programmer creates these.

Atwood: Yeah, you have to, but the mishmash of tags is still very painful, the tag soup, because it's really hard to read, because sometimes you'll have conditional logic in the view page, like "oh, if you're not an administrator, you shouldn't see this administrator menu on every item," right?

[57:05]

Atwood: Well, that's logic that has to be in your template somewhere.  And it's really difficult to read, and we have the same problem in ASP.NET MVC, because it follows the MVC pattern, and I don't know, the tag soup problem to me is still very much unsolved, it's like that stuff is so hard to read once you start getting a lot of variables and a lot of logic, and, uh, it's a challenge.

Spolsky: I've actually found that if you use some of the, er, you know what?  For me in ASP.NET programming, probably one of the best and most underused features is user controls which allow you to take a little blob of HTML and make your own control out of that, and this basically gives you the ability to take some HTML presentation like a small piece of the HTML template, and collapse it down to effectively one tag.  It lets you create an abstraction basically and it can have its own code and you can use it in lots of different places.

Atwood: Yeah we do that.

Spolsky: Yeah, and that's just a fantastic way to avoid large and convoluted and messy files.  It just basically lets you use the same tools as you had for the programming of subroutines and lets you extend that capability of creating a simple abstraction to code that has some HTML piece as well or some tag piece.

Atwood: Right, I have a blog post I'm gonna write about that and I think cover some of it but I think the tag soup problem is very much alive and well in even the most advanced and radically new, you know, web, the fanciest web programming environments you can think of.

Atwood: Before we go too 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.  They're 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 aspiring Mac programmer, but my experience so far is mainly with web development; Javascript, and Python.  I'm looking to learn C as a foundation for working with Objective C on the Mac, and to hope to receiving an approving nod from Joel.  My question is: Where should I start?  Although 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's 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?  [phone rings]  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 argument 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... Okay... 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 eliminates 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 Cocoa 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 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 and again and again because they were missing some of the early concepts that nobody cared to explain to them.

Atwood: So do 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 actually 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 similar 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're 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 invite you to the Fog Creek office: New York NY 535 8th Ave. That is in between 36th and 37th street, kinda on a shmutzy [dirty] street here in the middle of the shmata [garment] 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 and cheese, or something.  And you'll get to meet the Fog Creek interns, and the software management trainees, and our new sales department, and a whole bunch of other 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 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.  A listener wrote in with some machine transcription, and I was kind of appalled.

Spolsky: Yeah, it was appalling, 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 appalling, and I think, my personal experience has been the machine transcriptions are harder to edit than to just type it in right in 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... et cetera. 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 today.  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... [sighs]  It's like the iPhone 3G, except, at least the iPhone 3G if you wait in line for six 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.  Unfortunately for that we need another 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 vorbis file using your computer's 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 that's 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, too.  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 acquired 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 written 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, outro

[1:11:07]

Last Modified: 10/20/2008 12:24 AM

You can subscribe to this wiki article using an RSS feed reader.