Spolsky: Hello! [pause] See the cold... a warm recording is better, a cold recording is cold opening. [sigh]
Atwood: Ha, ha, ha...
Spolsky: You become.. What happens is you become sort of self-conscious. Conscience? Conscious? ... It's aware! It's alive!
Spolsky: This is gonna be it. This is our recording, and what I'm gonna do is uh, cut it in some fashion... No I won't, I think we'll just go by with this - it's better to come in. And by the way if you have...
Atwood: No, no wait. I'd like to restart. Could you at least say welcome to the stack overflow podcast or something, so I actually know we're doing it?
Spolsky: You said it.
Atwood: Ha, ha, ha... all right, ok.
Spolsky: Podcast number th-- four! This is the fourth podcast. It's absurd. We are down to... I saw your list of how many listeners we have and we're now down... it goes down every time, so that's a good sign. This time we're gonna get it down to six.
Atwood: We're getting down to just the true fans -
Atwood: - of Joel, and myself - which is important, because you know I want to have as many avenues as possible to feed my ego. So this is a new one, which is very exciting for me.
Atwood: Uh, so let me start. I have some stuff still left over from our first call.
Atwood: Questions that people had. And one of the questions that people are asking quite a bit about StackOverflow is: Well, why even bother? Aren't there other sites that do this? Isn't this yet another way to re-invent the wheel in the programming community? I mean, it's not like there's any shortage of places for programmers to go to ask questions and get answers. And that's certainly certainly a fair question. And I want to also open by saying that failure is not an option.
Spolsky: It's a ridiculous question.
Atwood: Heh, well this could totally fail...
Spolsky: What is this, communism?
Spolsky: Is this like there's one restaurant, one grocery store, one department store, one airline, one hotel...
Atwood: [laughs] Well I think there's sort of a winner-takes-all mentality that sets in after a while. It's like: would you really start a video sharing site in face of YouTube. And even actually in that example there actually are other video sharing sites that I'm starting to see become pretty big, because they are discriminating themselves from YouTube.
Atwood: One way they do this is actually having high quality videos...
Spolsky: With boobs.
Atwood: [laughs] But I've seen like, viddler and vimeo and a lot of people are starting to use those sites. So you know even in the face of overwhelming dominance...
Atwood: I think it makes sense to have different options. So what are we actually going to bring to the table that actually makes us better, or at least different, than these other programming communities? And I think one of the things we have going for us - and it sounds kinda obvious - is when we have pretty large audiences that we're gonna say, "Hey take a look at this thing we're doing." Right, so... you know, it's kind of like when Nine Inch Nails did digital music distribution, and when Radiohead did digital music distribution, all the commentators, when they talked about that, said, "Yeah, that's no problem, you can do exactly what they did if you have a band. Just one: be Radiohead, right, two: put digital music online." So, we've built up...
Spolsky: Is that where Larry Wall's quote about Perl comes from?
Atwood: No, I don't know that quote.
Spolsky: He says about Perl, "If you don't like the way something works in Perl, make a different language, and then make it popular."
Atwood: Yes, yes, so we're hoping that having large audiences that we're involving in this process, through this podcast and through the blog and so forth, is one of the reasons that it's going to be different...
Spolsky: Also, we're going to have boobs.
Atwood: [laughs] Yes, we're going to have attractive female hosts -
Spolsky: -I'd just like to tell people that-
Atwood: -, and it's not going to be Joel unfortunately.
Spolsky: -There's, there's, we have no rules about frontal nudity like YouTube.
Atwood: yeah, exactly, exactly. That's a possibility.
Spolsky: Let me play, let me play a question here, I've got a question here that somebody, uh-
Spolsky: -that somebody asked, which is sort of relevant.
Kyle (caller): Hi Jeff and Joel. My name is Kyle, I'm a graduate student at the University of Arkansas. First of all I'd like to say that I really enjoy your podcasts and look forward to seeing StackOverflow come to fruition-
Spolsky: (garbled) That's that guy that keeps our --- -casting--- (???)
Kyle: -But one question that keeps popping up in my mind: It isn't clear yet to me how you plan on cultivating enough users in order for the site to become a really useful tool. Maybe I'm underestimating the size of your community on your blogs, but how are you going to provide enough content to reach a critical mass of activity that will convince developers that using the forums on StackOverflow is worth their time?
Spolsky: So that was the question, I guess, that everybody keeps asking, "why another one, and how are you going to hit that so called critical mass?"
Atwood: Right, well, first a bit of terminology. So, it's not exactly a forum. I mean, when I thought about this and Joel and I were initially talking about this, I framed my mind in a way that said, "OK, this is a forum that we're building." But the more we looked at it, it's not really a forum. It's more focused than that. Cause forums have a problem, and I've discussed this on previous podcasts, where you can talk about anything, right? And that ends up sort of, you end up chasing your tail in some way. When you can discuss anything, you end up discussing nothing. So, there's a very laser-tight focus on question/answer that I think sets us apart from forums right out of the gate. And then also, and I don't think we've actually discussed this publicly, but there's going to be a Wiki-like aspect to the pages as well. So the questions won't, hopefully won't go totally stale over time. Because once you get enough trust in the system, you'll actually be able to update the questions, point people to different areas as questions get old, and so on. So those are my first two observations out of the gate. What would you say, Joel?
Spolsky: Well, I'm sort of wondering about this term 'critical mass'. Like what is the critical mass here that we need to achieve? If we have one particular programming topic, let's say... um, let's pick something good... LINQ 3.0. Do they have 3.0? How do they do the version numbering with LINQ? LINQ 1.0 for C# 3.0 for Microsoft Visual Studio 12... 11. Ah, so you got this very very narrow topic, and one of the people participating happens to have studied it and written a couple of programs using it, so he kind of knows the answers, and there's 3 or 4 people who just kinda need some pointers and they're asking questions about this very narrow topic. And, lo and behold, because there are those 3 people asking questions and the one person giving answers, maybe for two weeks until they move on, then you have critical mass! And we've only answered one question, I mean, it's not Wikipedia, but you know, assuming that the question is very specific and that the person got an answer to their question, and that Google indexes us and that that answer doesn't appear anywhere else, and that Google then points to us when somebody else asks that question to Google in the future, then that's all that it really takes. I don't think there's a matter of suddenly like hitting either more people than any other site. I don't think that's necessary. I don't think you even have to hit very many people. You know, I have on my discussion group I have this .NET forum, which is a very very small .NET forum compared to all the other gigantic .NET fora that exist elsewhere in the world. And, uh, it's called .NET Questions and it gets you know a few posts a day. But it's really useful to the people who participate there, and those questions and answers do get into Google, not on every topic. So, I don't think there's any particular point at which it suddenly becomes viable. Or, that point is a lot smaller than you think.
Atwood: Yeah, I would agree with that, and I've also seen... a lot of times when I'm searching for information, as I'm searching for it, I'll sort of realize that I could have actually written a better landing page than almost everything that I've found. And I wrote about Model View Controller last night because we're actually using ASP.NET MVC which is sort of a new lightweight MVC framework that Microsoft is gonna officially bless at some point and release. And in the process of researching that, I was like 'OK, well what does Model View Controller actually mean?' I mean, like what have people done with it, how do you define it? And I actually never found a single page that I actually liked that much. I mean, there were bits and pieces of information that sort of helped me on different pages, but I felt truly after looking at all that information I could have written a better article than anything I found on Google. And I think that same logic really applies - there's a lot of really really smart programmers and the amount of information as you start drilling down into these topics, and you would think MVC is a pretty big topic, there would probably be like 'OK, this is the best page ever on MVC, no one can possibly top this page', but I do not believe that page exists. And I think that's true of so many tiny little topics, that you drill down, I mean, much deep[er], much lower than you know this huge concept of MVC. I think a lot of talented programmers can actually, you know, it doesn't have to be one person, it can be six or seven people contributing to this question and answer thread, would end up building a page that's better than 90% of the information that's out there.
Spolsky: Yeah. Why, why, um... I think that the Smalltalk programmers that coined the term Model View Controller... were all that modeled in their thinking, I don't think they really got it right [laughs].
Atwood: Well, it's confusing. I mean, that's one of the things I found is when I researched it, it really is confusing because the terms are so generic, right? Like 'Model', 'View', 'C[ontroller]', I mean these are generic generic terms. So you-
Spolsky: They're also not exactly... Like what's the... The controller is the way in which you use the view to manipulate the model? Or is the controller some other thing? What's going on here?
Atwood: Well, there is controversy about the controller.
Spolsky: Yeah. And shouldn't, shouldn't... What happens if the model changes? Who tells the view to update itself? Is that also the controller's job? So the controller is like a view/model synchronizer? Or is it... or is the user who's using the user interface, is he the controller?
Atwood: Well, I think it's one of those concepts where you get into it what you... you get out of it what you put into it, and I think for me the best example of it actually sort of working was, you know, taking the web browser, HTML and CSS, where the browser is the controller, CSS is the view, and HTML is the model, e.g., the actual bedrock information that you're trying to transmit out into the world.
Spolsky: Yeah, and that's what the Rails guys do, is they're just like 'well, these are subdirectories, we have the view is...', but they call the view the HTML, and the model is the underlying data, and the controller is just the code. But I don't know if that's really strictly what the object oriented people... I don't think that's strictly the way they were thinking about it.
Atwood: Well, I think the value of it comes in the fact that you're actually thinking about your architecture, which is more than I think a lot of other teams do. You're actually thinking "Okay, how can we actually have some logical separation of what we're doing in the application?" More so then "Are we doing this exactly right?" And the example I like to point to is "Is your app skinnable?" Because, actually, the reason this came up is that I was starting to edit the CSS of the StackOverflow blog to put in our logo. And I realized the easy way for me to put in the logo was to slap an image tag in there. Right? A hardcoded image tag. But once I did that, our site was no longer skinnable, because I have this image hardcoded in the HTML, right? It's linked to a specific image. It's difficult to change that through CSS. The way you're supposed to do it is have a div that you then use an image replacement technique on from the CSS. So even in the very basic level arena of HTML and CSS, you have to sort of think about "Okay, how can I achieve my goal?" And I think the best way to summarize that goal is "How can this be skinnable?" Like I can truly have CSS. I can plug in a totally different look for the site without modifying my HTML. I think that's a valuable concept.
Spolsky: Does any really, does any really quite achieve that with just CSS? It depends what you mean by... Wait don't tell me about ZenGarden.
Atwood: Why do you hate ZenGarden? I think ZenGarden is great, I love ZenGarden.
Spolsky: OK, tell me one example, other than ZenGarden, where somebody actually has a site where just changing the CSS really... and what does really skinnable mean? It's like changing the look but doesn't really let you change the feel in certain rather crucial ways that you may want to change.
Atwood: My point is that this is , and I think what you were getting at, is that this difficult and you have to actually work at this in order for it to be truly skinnable.
Spolsky: I am basically saying that anything you are going to let somebody customize than you are going to have to do something to let them customize it. And if the only thing you are just going to let them customize is fonts and colors by giving them CSS where they can change fonts and colors and maybe put some background images on if you were smart enough to remember to give them an ID or some kinda of tag that they can hang their things off of in the CSS, than you know good for you but do you sort of have to think of these things. And if they want to hang their tag off of something that you didn't actually give an ID or a name or doesn't use a specific class in your HTML file for it, it may be impossible.
Atwood: Well totally, and I think that is why it is important to sort of look at MFC and say, "OK, let's think about this. Like how can we actually achieve this without just rolling along and not thinking about it and then all of a sudden ending up with an app that is so enmeshed in its layout that you can't skin it in any way." It's not that you want to actually go out and say here there are 50 different ways that you can skin this app, but it gives you a cleaner separation of you know the model and the view and you put the controller in there and the controller is responsible for that.
Spolsky: So let me just play the Devil's advocate for a moment. When you say it's "cleaner," let's say that you have some text here and some text there, and this text needs to be positioned to the left of that other text, because that's just what it means. It's just logically oriented that way. It just makes sense for it always to be on the left of that one thing. So, now, the CSS fascists, or shall I say the CSS extremists, would say, "Alright, that's gotta go in your CSS file." So now, there's this code in the CSS file that's relating to a particular ID in a particular HTML page, and saying this ID goes to the left of that ID, you know, maybe it's floated, or something like that. And now, all you've done is you've separated - you've made people have to look in two places, and every time they look in either of those places, in one of those places, they don't understand why the text is winding up on the left unless they run a debugger, like Firebug, or something like that. And, in the other case, they don't know why - they're looking at the CSS file, and they're like, "Hmm, I wonder if anyone's using this particular rule that I have in here," and you have no canonical way of finding out where in the source code that particular thing may be applied. And all you've done is you've basically separated two things in space that are directly related to one another.
Atwood: Well, sure, I mean, okay so there's really two classes of things we're talking about here. One is redefining the behavior of default, built-in tags in HTML, right? Those are generic and universal. So if you wrote an HTML file, and I have css that's only talking about the built-in HTML elements, it's going to work. It's going to format, you know, here's your blockquote, here's your list item, here's your paragraph, here's your H1, H2, all that stuff. But you're right, that when you start digging and say, okay, this is actually an abuse of CSS to call it like the "header div". You're not supposed to mix up semantic meaning like that. 'Cause I might decide, "Hey your header? I'm going to put that at the bottom." So the thing that's called "header" is now a footer, right? That's where it gets weird, where you start naming stuff. But you're right, I mean, to some extent, the view needs to understand the model.
Spolsky: I've, you know - the thing is, look I've worked on a lot of projects where the CSS file only gets larger, and that is because there are things that have been added to the CSS file that manipulate some page somewhere to make it look right, because of this belief that things have to go in the CSS file that have to do with style - which is not completely incorrect - the end result is that you wind up with a CSS file that just goes on and on and is almost impossible to parse, impossible to figure out, and you believe that you can skin your site just by giving your CSS file to a smart web designer, and if you ever tried doing that, the webdesigner would come back and say "I just don't know what any of these things are." And you'd have to point out [that] "Oh, this is the display that appears if you get that particular error message, so here's how you generate that error message, and you can go see it." And without that they don't have any real ability to change the CSS without at least being able to test it, or produce all those particular bits of model in that particular view.
Atwood: Sure, sure and I think you've got to view it as like, you know - a long term goal that you move towards - I mean this stuff is difficult, right? There's the easy way, which is to just muddle everything together, like the spaghetti code. Remember classic ASP?
Spolsky: It's not spaghetti, it's neat. You put the things together that belong together.
Atwood: [laughs] Well, they can belong together but, in the ASP.NET MVC, so we've been talking about HTML and CSS, but this also works at the code level - in my blog entry I posted a screenshot of the project layout, it actually is very clean because you have just webpages with essentially mail merge type formatting, right where you poke stuff through the holes in the template - there's almost, there's literally no code there. It's a very static code template.
Spolsky: Yeah that's what you call -
Atwood: And you plug the stuff into it. So I think it works at the code level and er..
Spolsky: But this calling the separation clean, good Lord, isn't this the opposite of object orientated programming? Like, didn't we a long time ago decide that we want to put the data and the methods that operate on that data together in the same place - because they are related somehow and they should you know, provide some kind of encapsulation by putting them together. Surely, separating out things because this one happens to be view, and that one happens to be model, is a step backwards. Why is that cleaner? It just seems to me like it's just kind of a random artificial distinction. Let's put all the lowercase identifiers in this file, and all the uppercase identifiers in that file.
Atwood: Well, let's think of a concrete example. So in ASP.NET, you know, the traditional web form model, when you have a button on a webpage and you click on it, it would redirect, well it wouldn't even redirect, it's a postback to the very same page. So the code that handles that button click is there with the page. So already you have, you know, you're conflating the layout which is how the button will look, and the visual style of the button, which is the web form. And the code, is, they're sort of right next to each other, they're sort of the same thing. And if you're not using code behind, they're literally in the same file, right, you have HTML sitting next to OK when this button is clicked, do this.
Spolsky: Okay, that's pretty rare but yeah... and you want that.
Atwood: Why would that be rare? That's not rare at all...
Spolsky: No, no, it's pretty rare not to use code-behind.
Atwood: Well, yeah sure, but...
Spolsky: I think most people would probably keep their, try to keep their C# or their VB in a different file than their HTML. But, okay, so the question is where do they, ah...
Atwood: But if you look at PHP and if you look at a lot of the really really popular web programming languages, that's still how it's done. I mean it's very much done that way, that's the default, and people have to unlearn that to learn, okay, that code should go in a different place. And I think this is a question of...
Spolsky: Okay, I understand that that's what we keep telling them to do, but I'm just wondering why are we telling them that separation is a good thing when we just spent three generations of programmers putting the data and the methods that operate on that data together in the same classes?
Atwood: Well, I think that still exists. I mean, that would be the model, right? And the controller could manipulate... it's a question of what do you put in the model and what do you put in the controller, right? I mean, at some point you're going to have a Data Access Layer there, right? I'm unclear whether that would go with the model itself or be considered part of the controller. I think it would be part of the model, personally, so I think what you're describing wouldn't actually be a problem. I think you'd actually have classes that represent the database that actually let you operate on the database, like Customer.Add() and things like that. I don't think the controller would be doing that, I think the model would take that on. So, I think what you're describing is in fact true.
Spolsky: It winds up in 3 different places. And now [you're] even less happy.
Atwood: Well, I don't want to belabor it, but let me bring it back home...
Spolsky: I'm just wondering, I'm just wondering... Listen, I'm all for it, okay, it's Model View Controller, it's great. I'm just kind of wondering, it sort of sounds to me like you're trying to split up things just because of a certain type of anal retentiveness that programmers like to get themselves into. Where they're like 'God, it's cleaner if you separate something' and they just love to have these little separations that they have to spend a lot of effort maintaining. And it makes them feel good in some way, and it's all for some hypothetical goal of being able to skin an app, when the number of skinnable apps in the world is miniscule. It's, you know, less than 1/100th of 1 percent of all apps that are out there can be skinned, or need to skinned, or would benefit from being skinned. And in the meantime, you're telling yourself 'Well, this'll be great because I can just throw this thing off to a designer and...' No, you can't. If you've ever tried to throw a CSS file to a designer, after having built the application, no matter how careful you were, you'll discover that the designer is going to come back to you and ask for 37 changes, and the order in which the elements appear in your HTML, et cetera, et cetera. So, it's kinda weird, I mean it seems to me it's like just one more thing where programmers are looking for ways to make their life difficult. Now I'm gonna get some hate-mail for that one! Anyway.
Atwood: Well, let me give you an example of where I think this will be useful. We've been using FogBugz, and I think we have to be a little careful because there's been a significant amount of criticism around whether this podcast is self-promotional for, you know, Fog Creek basically, so I want to be a little careful but maybe I can balance that out -
Atwood: By being, by being critical
Spolsky: FogBugz - wait, just a minute. You can buy FogBugz for only $199, per user, and it's free for up to two users (Student and Start-Up Edition).
Atwood: Yes, so
Spolsky: This podcast is brought to you by StackOverflow.com, a commercial enterprise of Joel Spolsky and Jeff Atwood. Where you were.
Atwood: And that's true. Let's be clear, this is absolutely a commercial enterprise at some level, so I want to be completely open about that, but I don't want to be, you know, like late-night television commercial either. Um. So FogBugz, although I actually do like FogBugz and it's very cool, this is the first bug tracking system I've used where it hooks into email automatically, 'cos Team System, which is what I sort of know in my previous life, um, definitely didn't do that and it is very cool when somebody emails you that it automatically goes in as a, you know, a ticket and I can reply to it there and it maintains the histories. That's very very cool. I don't really enjoy the spam training aspect of it.
Spolsky: Oh. Our database is already trained. It's already doing 100% accurate job, and that's on about a hundred email messages. I'm sorry, wait
Atwood: Well sure sure
Spolsky: Not advertising [laughs] you're right
Atwood: [laughs] But I didn't enjoy the training period, just put it that way. And one thing I don't like is, I think the visual layout leaves a lot to be desired of FogBugz. And I think that, if I, if you could skin it, I think. First of all, I think it's realistic to say for a web app, you should be able to skin this in some way.
Spolsky: Okay okay okay but if you want to skin it, the, the visual layout is things like, ok there's this drop down menu that appears here, and you decide "hey you know, I don't want that to be a drop down menu, I want that to be over here, and I just want it to be a list of things". But the "over here", that's in the HTML file, 'cos there's an order to those elements, and you have to change the order of those elements, you can't just change the css and say this thing goes after that thing.
Atwood: Well I, okay. I'm not saying it's effortless, right.
Atwood: Like everything else in programming, this takes actual effort, right, but the benefit to me as the customer is I could replace what I consider to be sort of a marginal look of layout with something a lot cleaner, and a lot, you know, nicer looking. Or maybe I could just make it look totally stupid, like iGoogle, right, where you have these, these layouts that are just ridiculous but people love them right, because can customise it and make it their own. I think for a web app it's very, very realistic. I agree that for a desktop app, the concept of skinning is kind of like hard, unless you're doing a Windows Presentation Foundation...
Spolsky: Are you, wait, you're kind of a, you're an expert user, are you really gonna go in and skin gMail, or these, you know ...?
Atwood: Well, I
Spolsky: Isn't that kind of tedious? Who cares?
Atwood: I guess
Spolsky: It looks like
Atwood: But I feel like - Well FogBugz doesn't even use my whole screen, like it's only using like the left quarter of my screen, it's just, it's, it's, it needs some work layout-wise, so. I feel like this is an area where you know your product in particular could benefit from some thing like this. I think there are real benefits at the end of this, it's not just architecture astronaut stuff. It results in, I think, real flexibility that matters to the end user, and certainly to the development team, right?
Spolsky: My philosophy is that it matters to them not in the actual chrome, the UI of the application, they don't really care about. What they care about is, what their documents look like, and what their stuff looks like, and that may mean stuff like discussion groups and wiki pages which they show to the world. It may mean logos and stuff like that. But it doesn't really mean being able to change our user interface in any kind of arbitrary CSS way. I think that a user would have to be extremely--well, how could anybody possibly have time to decide that they want to change major aspects of the layout of FogBugz? Minor things that they want to change, that's OK, they're welcome to try to make the page wider, and they'll discover that it's hard to read, which is why we made it narrower in the first place. OK, that's enough of that model-view-controller. What's next on--
Atwood: No, it's an important topic, because that actually is the architecture we're going to use for StackOverflow.
Spolsky: Oh, good, I didn't realize you were getting somewhere. You're using the new ASP.NET model-view-controller pack that they released.
Atwood: Yeah, we totally have code, we have error handling, we have a data schema, all that good stuff, so we definitely have progress.
Spolsky: What's the data--
Atwood: Well, it's a question and answer site, you see.
Spolsky: Can I put in a question? Can I go into StackOverflow and type a question?
Atwood: Not yet. Well, at a very primitive level it does, but it's not really worth showing at this point. I actually went to the Maker Faire this weekend, which is a Bay-area event, it's sponsored by Make and Craft magazines, and it's sort of a cool event, where a bunch of people come and show off the things they're doing and companies come, and I got to meet somebody from the Wikimedia Foundation. I didn't realize, but the Wikimedia Foundation has moved to San Francisco. They used to be in some crazy place in Florida, and their servers are still there, their main Wikipedia server farm in south Florida.
Spolsky: Wait, did you say "Wikimedia"?
Atwood: Wikimedia is the name of the foundation, and Wikipedia is one of the things that they do.
Spolsky: Oh, I see.
Atwood: And what they're known for. And I found out that their entire Wikipedia database is 10GB, which surprised me.
Spolsky: Not very much.
Atwood: Yeah, I was asking about their server farm and how they back it up and stuff like that, but I was talking to Jay Walsh, who's their head of communications, a very nice guy, and it was just exciting for me to talk about Wikipedia, because we've looked--when we started StackOverflow, you and I were both sort of big fans of what Wikipedia has done, and view it as sort of a role model in the sense of creating evolving, live pages, that I can link to today, and three years from now I know those pages will be as relevant as they were three years ago. And this is something that blogs do very, very poorly. Blogs is another sort of model we looked at for StackOverflow. So it's sort of a hybrid of these two, I think, that makes it really, really compelling. There's a blog aspect to it, like question and answer, like post/comment, which is very simple, people understand that. But on top of that, there's this really nice editing layer that goes on top of it. And I was talking to Jay and just trying to think through the reasons why I can't stop linking to Wikipedia, which has some scary implications, because Wikipedia's eventually gonna own every keyword. I mean, it's already happening. And even in 2006, it was like, I can't see a world where Wikipedia doesn't own like every single search term, because their results are so good. And the thing that makes it OK for me is that Wikipedia, and Wikimedia Foundation, is a non-profit. That's a big deal.
Spolsky: So they're never going to own any commercial keywords, in particular.
Atwood: You think?
Spolsky: Yeah, I don't think so. By which I mean, if you're interested in getting a Jeep, and you wanna know about--well, actually, that's in there. If you're trying to find a local Jeep dealer, and see what their prices are, I don't think you would go to Wikipedia.
Atwood: Wikipedia is the third entry for Jeep. And again, I see them just--
Spolsky: So that's like a list of what the different vehicles are and--
Atwood: Yeah, but still, they're number three for Jeep, so .... it's a little scary. I think there's aspects of Wikipedia that scare me a little--
Spolsky: Yeah, communism!
Atwood: --but on the whole I think it's a really useful resource. And StackOverflow's gonna have some of the same aspects. As you get trust in the system, everything, literally everything, will be editable, with an undo/revision history. And that's a key part of our strategy.
Spolsky: Lemme play a question here, because that's sort of,
Andrew: Hey guys, this is Andrew Marl from Las Vegas, Nevada. I had a question: I understand that you guys are using a Digg-style system, or another style ranking system that'll help push useful comments to the top of a thread, if we have questions, and the obvious junk is gonna get pushed to the bottom. I heard that in the first couple podcasts. One thing that I've seen, though, that is kind of a dynamic with programming sites, is that answers will be posted across several posts, going down, and you have to have read the previous post in order to really understand what these replies mean. And I'm worried that things are gonna go asynchronous if they get pumped up to the top, and it won't be as easy to follow the thread. Will there be a way to view things in context a little bit better, or how are you guys planning on handling that? Thanks!
Atwood: So there's gonna be two main sort orders for the questions and answers. One is rank based on voting, and the second is simple, chronological order. The other thing that will happen, and this is something we talked about earlier, the person who creates the question has one special privilege--I assume, I guess, system administrators will have it as well--but they're able to bless a certain response as "Oh, thank you, this is an answer that really helped me!" And that may also--
Spolsky: Sprinkle it with the special water.
Atwood: Yes, it's like a blue ribbon of some kind. But as the person who created the question, you do have a little bit of special privilege in the thread. Your responses will be highlighted, you can also grant, basically, a boost to an answer, and say, "This was a really good answer," this is my personal favorite.
Spolsky: This is the one that solved my problem.
Atwood: Yeah, it may not be the best one by voting, but this is the one that the original person who asked liked the most, so you close that social loop of, if I go up to somebody and say "Hey, I'm trying to do this, can you please help me," and they help me, then I say "Oh, thank you very much for helping me." So you can close that social loop, and we felt that was kind of important. More important than the voting, even, to some degree. But we hope that the two sort orders will address that concern. Where you can view it chronologically, so it doesn't get out-of-order, and you can also view it based on--
Spolsky: Whaddaya do if you're reading some answers, and the best answer is there, and somewhere else is another answer that's also kinda good, and the combination of them would be great, and you wanna somehow combine these answers in a better answer. In other words, you just want to be an editor, like you're--a lotta the people who have contributed to our transcript pages for this podcast--and thank you all--a lot of them just went in and made a little correction. They just saw something that was obviously a typo, or some case where some previous person who'd been writing the transcript maybe didn't know how to spell someone's name, so they went in and they correct it. How do you do that when you're reading answers on StackOverflow, if you just want to make that little edit, to make that question better?
Atwood: So, it'll be very much like Wikipedia, in that once you have enough trust in the system--this is not something we're gonna grant blindly--so you'll have to not only have an account, but also have a reputation, which is what we're calling it, a little bit of reputation, you can actually unlock and click edit, and literally go though and edit anything in the system, really, except for probably other peoples' profiles. So if you wanted to combine a question with another question, the first thing I would do is consolidate the information across the question, post a link to the other question, it's like, this was also asked here, here, here and here, and then basically cross-reference them. I don't know if there'll be a way to close a question entirely. I assume that that's something we'll have to think about.
Spolsky: So I could theoretically, if I saw somebody, if I had lots of karma or manna or whatever we're gonna call it, and if somebody else had an answer that was slightly wrong, I dunno, they left off a semicolon, could I hit edit, add the semicolon and save it?
Atwood: Oh sure, absolutely.
Spolsky: And do I get some credit, do I get some points for that, or do they get all the points for making their question better?
Atwood: No, you will. You'll get points--and this is--the way to think of reputation in our system is, I'm trying to do it very Google-like in that you can't give yourself reputation. So you can't--there might be one or two things you can do that just result in immediate increase in your reputation--but your reputation comes from other people voting for you. So once--I'm trying to think exactly how we're gonna do this--but perhaps once an edit goes in you get a partial credit for any up-mods on that particular thing--
Spolsky: You're gonna have to do something about like circular link-farms of people voting each other up, and so forth.
Atwood: Oh I'm sure there's all kinds of evil user pathologies we're gonna have to deal with. We have thought about that a little bit. One thing we're gonna do is very much like Wikipedia again, is, if a question becomes very controversial, we can lock it down so that only people with reputation can do really anything with it. As it stands now, we were hoping that guests could come in and add answers, add questions all they want without creating an account. This is another way we're different from some of the other sites where they really force you to create a login almost immediately. We are not going to do that. I believe very strongly in that. But if a question becomes controversial, we can block that and say, OK, look: only people with reputation or people with logged-in accounts, depending on the degree of how controversial it is, can do that. So we've given some thought to "evil users". But I'm sure--people are very wily, and I'm sure they'll come up with new, evil things to do.
Spolsky: I don't there's going to be much controversy in these realms, I don't think that we're really...
Atwood: Any time that you have a score in a system, there's going to be people that want to game it.
Spolsky: That's true. And that's a little different than controversy, there's going to a lot of people going through--and this happens on Wikipedia too--a lot of people going through and making technically correct, but almost meaningless improvements to grammar and spelling and punctuation.
Atwood: Right. As long as it doesn't hurt the system, I'm fine with it. And since your reputation largely comes from other people, not--you can't vote for yourself essentially, that's pretty much the golden rule of Google and the way a lot of these systems work. It will really have to come from other people acknowledging what you've done, so even if you go through and edit thousands of articles, you're not going to have thousands of points of reputation, only in the sense that other people saw your edits and ultimately up-modded it later. So we will be tracking that.
Spolsky: So you can upmod an edit, or you upmod the article after it's been edited, or--
Atwood: Yeah, I think we'll have to give partial credits, fractional credits--
Spolsky: I mean, technically it's possible, you go look at the history of the article and find the diff and upmod the diff. I don't know if--
Atwood: Nobody's gonna do that.
Spolsky: Uhh, hmm. Yeah.
Atwood: I think fractional is the way to go. Because, think about it, if you go and completely rewrite the original question, I mean there might be some way of, y'know, doing a line count, saying "how many lines did this guy edit," this guy or gal, I don't wanna be sexist, and say, OK, you edited 50% of this, now you get 50% of the credit for these upmods. Of course, that could also lead to pathologies, where somebody would go in and just make trivial edits to everything. [laughs] Yeah, there's always new ways to game the system. So yeah, this is going to be very much an evolving thing as we do it, but the guiding principle is basically the PageRank model, where other people have to vote for what you've done to make it worthwhile. And y'know, Google spends god knows how much resources on un-gaming their system. So no matter how good it is, it's an ongoing battle that you fight, so we'll see how far it goes.
Spolsky: I wonder if there's some way to use their PageRanking. I mean, one thing you could do is sort of leverage off of Google's opinions about these articles. I assume we'd use them as a search engine.
Atwood: Yeah, no, that's built in, because we'll have page views, right? But we could also look up, eventually, PageRank. Although, PageRank is kind of a weird metric, like it fluctuates a lot, and it can be kinda strange, but certainly page-views is a metric that we use, and you will get rewarded for that. If you create a question that gets 100,000 page-views, you'll get a special award.
Spolsky: So if Google likes you, then you have a lot of page-views, and if you have a lot of page-views, you get some karma. So we are sort of getting some of the benefit of their algorithms.
Atwood: Yes, absolutely, absolutely. And coming back to another topic that came up, since we're gonna have wiki-like aspects, I set up a Creative Commons license for our podcasts, and I actually didn't check with you, I just assumed this would be OK, but I set up a Creative Commons--
Spolsky: What's that, some other kind of Communism? No, I'm just kidding. Yes, that's absolutely OK. That's a good idea.
Atwood: So, Creative Commons is neat in that everything--and here's the key point that people, I think, don't understand, and I don't think I even understood this for a long, long time--is when you create something, it is copyrighted by default. So there's a default mode of creation: if you create something, like a little drawing on a piece of paper, it's copyrighted by you forever.
Spolsky: That's ridiculous.
Atwood: Yeah, it's kind of a weird system. So when you say, I wanna use Creative Commons what you're saying is, I want to give up some of my inherent copyright, so that other people can remix, reuse, benefit from what I've created in some way. And you can control that, and put rules around it, and it's actually very, very cool. They actually have a wiki, like a pre-formulated wiki Creative Commons license that I think we're gonna use, because StackOverflow's gonna be very wiki-like on a basic level. So I think that's probably the way to go, with the default Creative Commons wiki license, and let people go from there. Because I know people had asked about licensing, and certainly part of what makes the site great, a big part of it is gonna be the listeners, the people using the system. So I wanna do the right thing in terms of licensing their content so we're not abusing the relationship.
Spolsky: I think what we thought is that we wanted to--we don't wanna license their profiles, because that's their personal information, so we don't really have any right to do that. But the information that they put out should be redistributable and so forth. So if somebody puts in information--
Atwood: Yeah, stuff that's meant to go out into the world and be shared and reused. So I think we will adopt this CCwiki license for this content. Do we have any other questions?
Spolsky: We do, but while we're on, sort of, the legal subject, I guess I should mention that we're, I promised to get a lawyer in California, because the idea of using my lawyer to represent both me and the company was apparently a legal mistake, because that person would have a conflict of interest. So I'm working on that. So then I have a friend who's looking for a lawyer out there, and I guess apparently the first attempt was this idea that it would be an LLC, and you and I would own some shares, and there's an investor, the investor would have a smaller number of shares that he would buy, but there's sort of the risk that if we're given a part of an LLC for free, and he has to pay for that part of the LLC, that that's a taxable event for us, and we then have a bunch of income--if you do it the wrong way.
Atwood: Yes. And just to the listeners, so I'm really relying on Joel--I've never run a business before. I think it's one of those things that, it's exciting to be able to do it at some point in your career, but since Joel obviously has a business, he has Fog Creek, I'm really relying on Joel to sort of guide me though this, about what I should and shouldn't do.
Spolsky: And you shouldn't be, [laughs] because Fog Creek, for example, is a C-corporation, and a C-corporation--I was just thinking, earlier today, the difference between a C-corporation and an LLC is sort of like the difference between, shall we say, Microsoft and open-source, in that, the C-corporation, everybody knows how it works, there's shares, you can make it do whatever you want, ultimately you have unlimited flexibility, but it's not a very good way to do things in certain circumstances, it doesn't give you tax pass-through choices. And an LCC is this mysterious form that is extremely sloppy, there's no assumptions, everything is kinda loose and whatever you define. It's really kind of like UNIX software. So in an LLC, for example, there's no assumption that one share equals one vote. There's not even an assumption that you have shares. You can make shares if you want, but that's the first thing you have to do. There are membership interests, and you can define anything you want, you can say, y'know, I get 100% of the votes and you get 0% of the votes, even if you put in all the money and I put in none of the money, and--you can do whatever you want with it, an LLC, whatever you write down. It's just sort of this flexible thing, but of course you run the risk of the IRS then disallowing it. So it's kinda weird. I think if I had to figure this out myself, I would've made it a C-corp, and that would've been wrong. But we'll see what the lawyer says. Just like, when I have to figure out code myself, I just sit down and I write it using Microsoft tools, and it's non-ideal, but it's something that I already know, and I know how to make it work, and I know what all the problems are I'm gonna be suffering because I did that.
Spolsky: Did we?
Atwood: Yeah, we met at your world tour.
Spolsky: It's all a blur. Yeah, I do remember that, yes.
Atwood: Part of this is based on an implicit trust relationship, but I think we have to - in terms of money and all that stuff - I think we have to have it written down and it has to be approved by lawyers, and I told Joel on some level it seems like a scam to create business for lawyers because Joel has to have his lawyer-
Spolsky: We have to have four lawyers.
Atwood: The corporation has to have another lawyer, and there's another person that has to have another lawyer, so it's like a lawyer party. Of course everyone's getting these insane billable rates, but it's a necessary evil because, I hope this is hugely successful, but as I mentioned earlier, failure is totally an option, I mean, you might decide to totally disown me and things might go south and that's where I think the contracts protect you.
[42:00]Spolsky: I even don't think the contracts protect you, if things go south then they go south. The contracts protect you for those cases where you suddenly hit something where you didn't really talk about what you were going to do if this happens, and even if you're both completely reasonable, you look at the situation and you say "hmm, we didn't really decide what would happen in this case" and then you look at your contract and "Oops, it doesn't say anything" And now you have a potential conflict and there may not be what a reasonable person would do, there may not be such an answer and so if you've done it well, then your lawyer has given you a contract that you look at and it's got 26 points and you'll find this point in there and you say "Ah-ha! Look, it says that you can't do that, or if this happens then that extra thing goes to me or that extra thing goes to you"
If you ever sit down and try to think of even the simplest possible relationship that you can have with somebody other than buying something from them - and kind of joint venture or anything like that - and you just try to spend a few minutes thinking about all the different permutations and scenarios, you get to about twenty clauses in your contract pretty quickly. And you don't really need a lawyer to write the contract as long as you've thought about all those things, but a lawyer does help in that they come up with some of the "what if" scenarios that it wouldn't have been polite for you to come up with.
Atwood: So the lawyers have been through these battles, they've seen the problems (theoretically) right? If you get a good lawyer, they'll say "Okay, here's the problem - "
And then our lawyers "What are you talking about?" If we were to say "this is unfair," then that's sort of putting us in the postion that acting like we're not planning to pay our rent on time, whereas if our lawyer says "this is unfair," then that's just lawyers talking amongst themselves and that's what they do. So your lawyer can negotiate in those kinds of situations without it seeming like a lack of good faith, and a lot of times they will put in lots and lots of clauses.
Just to take a simple example, another simple example is this conference that we're doing the Business of Software conference that we're doing with Neil Davidson from RedGate software. Partially, I'm providing some editorial material to the conference in the sense that I'm helping recruit some speakers, and I'm speaking, and you know, giving them brand name and that kind of stuff - calling it the Joel on Software conference. But the list of details that we had to come up with, about: under what circumstances who gets how much of the revenue; what happens if someone gets a discounted fee; and who gets how much of the revenue if we have a student that's not paying; and so on and so forth. And you very quickly come up with about twenty kinda interesting circumstances that are not obvious from what you would get from a hand-shake kind of agreement.
Atwood: Right. I've begrudgingly come around to the necessary evil-
Spolsky: -and the truth is, after this you're not going to see another lawyer for another four or five years.
Atwood: I think I good, I think that's the way it should be.
So, quickly, I do want to mention, our logo design contest now over. We did pick a logo. Joel and I both sort of kind of signed off on it. And, I apologize, there were some really great entries and I think the winner, I do want to actually say his name is... Peter Borlace? Borlace? I don't know if I'm pronouncing it correctly but he's out of the UK. I really liked his entry. There were 3 others that were really strong contenders. And we actually did hook those guys up with TimeSnapper licenses from Leon Bambrick. 'Cause I know, and the more I thought about this, 'cause one of the observations you had about the contest was it's kind of unfortunate that it's winner-take-all. It would almost be better if it was, ok, first person gets this much, or first place gets this much, second place gets this much, third place gets this much, so it's not quite as winner-take-all.
Atwood: So, I'm glad we were able to do that. And I went ahead and put the logo together and set it up on the website.
Spolsky: Yeah, it's up on the site. It's great.
Atwood: Yeah, and one thing I wanted to ask you is, one reason I came up with the 99designs contest is 'cause I had mentioned on Twitter that I was struggling trying to figure out what to do about the logo, and that's how I got hooked up with the guys at 99designs. And I was kinda curious, have you -- I'm a huge Twitter fan-
Spolsky: Oh no, do we have to talk about Twitter?
Spolsky: Agh! [Laughs]
Atwood: I wanna talk about it a little bit because I was wondering if you wanted... 'cause I've... it's very useful, right? Like, I got this 99designs hookup through it, right? I mean that's useful. And I get really great feedback, like, I'll post something and I'll get all these great responses "Oh, have you tried this? Have you tried this?" It's basically public instant messaging. It's kinda like IRC but through the Web, right? So it's...
Spolsky: It's kind of weird, I mean it sounds like it was created something for these web celebrities... like you...
[Uncomfortable silence as Atwood removes dagger from heart]
Atwood: [Laughs nervously]
Spolsky: ...John C. Dvorak.
Atwood: Well, I find it very useful. I, I...
Spolsky: But if you weren't a web celebrity, it wouldn't be that useful.
Spolsky: How many people do you have following you?
Atwood: Uh, like 2800...
Spolsky: 2800 people following you! [Laughs] You have to admit that that's a sort of unusual number of followers. [Laughs]
Atwood: It's relatively high, but I'm not in the top 100. There's certainly way more famous people than me.
Spolsky: Paris Hilton! [Laughs] Does she Twitter?
Atwood: I'm disturbed that you're drawing parallels between me and Paris Hilton.
Atwood: But I think you would actually find it useful, because I love the ability to just share with people. I've always hated instant messaging, frankly - to me this is a palatable form of instant messaging that I really enjoy and get a lot back out of. So I would encourage you to -
Spolsky: Ah yeah I still don't have instant messaging and I feel like I'm kinda behind. I'm just catching up with email now - I don't know if people have realised this, they may have emailed me - but when I get an email my secretary will print it out and bring it into my office, put it in the inbox and then if I have a reply, I call her, she comes in and she takes shorthand.
Atwood: That's - you're lying. That's not how it works. You're exaggerating. I don't believe you.
Spolsky: And so, if I can get my secretary on this 'Tweet -- Tweeter' thing, I might go for that. [Both try and start a sentence at the same time!] I really have a very strong feeling that Twitter is er, is er, it's very, it's not even, it's beyond Silicon Valley specific, it's almost like Silicon Valley news, tech news, specific. Like the people, the big bloggers, the big journalists.
Atwood: Why don't you try it out and see what you think? I mean I - it's kinda like I was very skeptical of blogging [Joel makes stupid noises] in early 2004, you know? But -
Spolsky: I still don't have a blog. I've never called Joel On Software a blog. It was just er - it's a bunch of essays. And I don't put blog posts because I think they're too short. 'Cause if you haven't - my feeling is if it 's not a full length essay that I've thought about, then it's not going to have enough - it's not going to be sorta deep enough to be really worth the time, almost.
Atwood: Well these are very deep philosophical issues you're getting into, so I would suggest trying it out before you conclude that it's not going to work.
Atwood: So did you want to do one final question...
Spolsky: So one Twit... No wait, wait I have to put this down on my "To Do" list: "Get a Twitter". I'm just kidding, I'm not really going to do that. Ahh yeah, let's take a question which is completely unrelated here.
Obvious Troll: Hi guys, this is "Obvious Troll". Ahh... after mocking you on Reddit for your terrible website, I have to admit I've been listening to your podcast and I find it entertaining and very interesting. After your last episode where you talked about the difference between Computer Science and Software Engineering I realised I had a question for you.
I graduated from college in 1987. Now I find myself wondering if it is worth while to go back to school and get a graduate degree. The college I'm looking at has a grad degree in Software Engineering. Which is interesting to me, but is also terrifying because it's been a long time since I've been to school. So I have to ask you; do you think that going back to grad school to get an advanced degree and update my skills is worthwhile? Or if I should just do continuing education kinds of things and, you know, update my Java certification and stuff like that there?
Thanks very much and again, I've really enjoyed your podcast.
Spolsky: Ahh... well thank you. So let's see... 1987. It depends on what the rules are, do you get back into your frat automatically if you go back to school in '87? Do you have to re-pledge and go through that whole hazing thing again? I, I'm sorry.
Atwood: I don't know if I am really equipped to answer that question. I mean I don't know if I have enough background on... I mean, to me, you know as a practitioner, you know I went to the University of Virginia and although I enjoyed it I was really happy to be out in the world. You know I just had a hard time at college because I would just rather be solving real problems [Spolsky murmurs agreement] rather than fake problems and that really bothered me throughout college. It's like, it's so abstract and you have to learn how to learn and I get all that but I was really chomping at the bit to be out there doing [Spolsky: Yeah.] something... ah... practical. And not that school isn't practical but I just don't think that I would ever, ever personally...
Spolsky: Well these software degrees, especially Masters in Software Engineering, are bound to be a lot more practical than a computer science undergraduate degree at a liberal arts school.
Atwood: Well certainly if you look at, I know Google and Microsoft um... certainly hire differently based on what degree you have. In certain companies that really value software engineering will accord you a different salary [Spolsky: Really?] and different title based on the degree you have. Absolutely, absolutely...
Spolsky: We generally have a policy of paying people with a Masters degree one dollar less than people with a Bachelors degree alone. (laughs)
Spolsky: As a symbolic way of indicating to them that we don't feel that masters degrees are necessarily that valuable. But that's not... that's not always the case. It really, it depends a lot on the person. It depends a lot on what you've already learned. It depends a lot on whether the classes you are going to be taking are things that you've learned before, that you haven't learned before.
A lot of Masters in Computer Science are just repeats of the Bachelors curriculum that are intended for people that didn't go to as good of a Bachelors school or that did not get a CS Bachelors degree and are now coming back to graduate school for the first time to learn CS. And so in a lot of schools a Bachelors and a Masters are almost indistinguishable. In computer science at least. So the number of questions there is huge and it just-- it depends. I can't really answer. You know in general I'm very reluctant to answer people's questions about "hey, what should I do in life? Should I take path A or path B?" because I don't really know them well enough to answer that. I don't even know how to answer these questions for myself, let alone for other people.
Atwood: Well, I tend to fall back into the mode of thinking of, you know, it's all about your portfolio. I mean, degrees are great, but what have you done? Right? Like, what have you really done? What have you shipped? What have you [laughs], what can you point to on the web realistically? Right? What can you point to on the web as like artifacts of things that you've created that mattered? And to me, my number one goal is to constantly create things on the web that matter. Could be code, could be blog articles, could be... as long as it has a public face and it's helping somebody, that's a part of your portfolio, so in terms of investing your effort, I think you have to balance that and think "How can I create things that are findable and that, you know, potential employers would know about me?" Certainly, a degree is one way, right? You have a piece of paper that says, okay, I have a PhD from Harvard in computer science or whatever. But there's many many other ways to do that too.
Spolsky: Cool. Alright, I wanna do a tip of the week... something that Leo Laporte does. But I actually found an application today that has saved me so many hours of work that I kinda wanna mention it. Do you do a lot of SQL database work? I guess we're gonna be using SQL Server for StackOverflow. And there's always this problem of how do you get... you've got your development database and you got your live database, and all of the developers on the team they have their own development database. And keeping those in sync and figuring out what changes you've made to one and how to get them onto the other is something that is not necessarily solved using the out-of-the-box tools. Um, so today by chance, I encountered a couple of products by Red Gate Software. And 'by chance' I say because I've known Neil Davidson for a while, he's the guy who organized the Business of Software Conference. And I know that he had this company called Red Gate, and it's based out of Cambridge, England, and they do tools for SQL developers and I kinda knew the concept was there. And I was just sitting there today, desperately needing to copy a bunch of changes that I had made on my development database up to a live database, and even figure out what those were. And I had very carefully kept a list of all the tables I had changed and all the views and stored procedures I had created, and it was still just turning out to be remarkably tedious. So I tried... they have a couple of things, one is called SQL Compare... I think that's what it's called. Let's find out... [Joel checks out red-gate.com]. Yeah, they have SQL Compare, and they also have something called SQL Data Compare. So, SQL Compare looks at two databases and actually looks at the schemas, and the stored procedures, and the views, and figures out what changes you would have to make to one database to make it look like the other database. And then SQL Data Compare will actually go in the actual datas [sic] and the rows and it'll figure out what rows it needs to copy. So, I just thought I'd call that out, if you're doing a lot of SQL development, you should check that out. This is not a paid advertisement. Everybody's gonna say 'What? Are you guys taking advertisements now?' It's just a really fantastic tool that I've been using today and greatly appreciate. So, I'm gonna go pay for that as soon as I get off the phone with you.
Spolsky: Anyway. Recommended... Red Gate SQL Compare, SQL Data Compare. Uh, what else do I have on my list? Not that much. I guess we should tell people one more time where the website is, and the transcripts, and how to leave us comments. We get a whole lot of email that we can't respond to. There are... gee, I only did about three of these, but a bunch of people I wasn't able to play their messages: Kurt Leucht [surprisingly this was pronounced correctly as "Loyt"], John Dire [?], Chris Benitz-Cash [?], James Fisher [?], Sean Paulson [?], Craig Shoemaker [?], and a couple others. And I wanna thank you all for submitting questions and I'm sorry I couldn't get to all of them. In general, the ones that I'm gonna play are gonna be the ones that are, you know, just interesting and so that may vary from week to week. And the way that you submit a question is to record an mp3 question. Uh, record it as an mp3, or Ogg Vorbis, or wav, or whatever format you can figure out how to record, and then email that to firstname.lastname@example.org. Did I get that right?
Atwood: That's right. Yep.
Spolsky: email@example.com. Just email the mp3, put in the subject what it's about, keep it under 60 seconds or 90 seconds, and hopefully we'll have time to get to 3 or 4 of them in every episode. And I really appreciate all those good questions, 'cause they give us something to talk about and they keep us grounded. The other thing is that we do get a couple of emails from people who wanna follow along but are hearing impaired and, um, the other trouble with these podcasts is that being voice, they can't be searched by Google and so-forth. So, for those two reasons, we've made a place available for volunteers to contribute transcripts. If you have a few minutes, a lot of people have been doing this, and about two and a half of those transcripts are up there already. Um, that's also on the website at... where is it? If you go to, um...
Spolsky: Yeah, or you could just go to stackoverflow.fogbugz.com, which is our FogBugz site, and uh, go into the wiki there -- there's a wiki with all the transcripts. And uh, I want to thank a bunch of people; a lot... most of them are anonymous, but those of you that registered: Eric Rogstad, Daniel Pritchett, uh Michael Mathews, Jonathan Rauch, Alex Givant -- I'm pronouncing these all terribly -- Adrian Clark, Christopher Svec -- oh, I know him -- uh, William Merriam. And I wanna thank uh, and everybody else who contributed in some small way: either, just y'know go up to the -- you can go up to the transcript site, find a minute that's not there, and just type in a minute worth of text, and that'll be uh, appreciated by a great number of our, of our uh, listeners and followers.
Any other uh...
Spolsky: ... housekeeping? ... Alright ...
Atwood: No, I think that's it!
Spolsky: ... see you next week!
Spolsky: OK, and now I...