The Stack Overflow Podcast

This week, Jeff and Joel are joined by Scott Hanselman - tune in for their discussion of everything from MIX11 to the salads at Jack in the Box. Welcome Scott Hanselman! Be sure to check out both of Scott's excellent podcasts at Hanselminutes and This Developer's Life. Joel recently wrote an unintentionally controversial blog post about lunch and how important it is here at Stack Exchange and Fog Creek. Despite the claims that Joel is torturing introverts by forcing them to eat lunch together, the truth is that almost everyone at both companies is introverted and yet enjoy lunch together. Scott wonders how so many people have so much time to sit around on Hacker News and Reddit (and everywhere else) discussing these blog posts when they have work to do. Of course we have to reference Clay Shirky's classic Gin, Television, and Social Surplus here. Scott is busy putting together a new Synology DiskStation DS1511+ to replace his Windows Home Server setup - unfortunately, there's a lot of options (and a lot of bad ones out there). Scott is a wired enthusiast, but he does like his optimized wireless N setup, which is based on a Netgear N600. Microsoft has an amazing video conferencing system known as RoundTable -- now branded as the Polycom CX5000 -- that captures the room in 360 degrees and then automatically detects and shows the person who is talking. Scott also has a mobile remote telepresence device running around Redmond as him, somewhere. He also recommends the Cisco Umi. Over on mechanics.stackexchange.com, Jeff wonders why online car communities are so brand-centric -- there are hundreds of dedicated sites for Ford enthusiasts, and Subaru enthusiasts, and so forth. Whereas programmers can have Java and Python installed side by side on the same PC, you have to own a lot of physical, real world vehicles to have experience with many different car brands -- or, be an auto mechanic. Perhaps programmers are kinda-sorta mechanics in the sense that they spend most of their time practicing the noble art of maintenance programming. Stack Exchange sites do well in professions where you can open a relevant Stack Exchange site in a window side-by-side with the work you're already doing on the computer. But what about people who don't regularly work on computers? Is it realistic to expect people who tend to work offline to take the time and effort to come online after they finish working and keep discussing their work? Or, will the proliferation of computing devices like smartphones and tablets bring the online world to them while they work? It does happen, since diy.stackexchange.com is clearly an offline site but produces a lot of really high quality questions and answers about home improvement. We've improved flagging dramatically on Stack Exchange over the last few months. You may have noticed a public flag weight value on some user profiles. Your flags now carry different weight depending on how accurate and helpful your flags have been in the past ... and the more you successfully flag, the more daily flags you'll get, in a sort of virtuous cycle. Scott asks: why should I care about all these points and flags and badges and reputation systems on Stack Exchange? What's the point of you guys building your own Dungeons and Dragons MMORPG system online? Tune in to next week's podcast when Joel will be "live" from London and our guest will be the infamous Jon Skeet! Also, if you're interested in helping us pick content for Stack Overflow Dev Days - check out Joel's post on it.

This week on the Stack Exchange podcast, Jeff and Joel are back into the swing of the weekly podcast and jump right into business, including: The algorithm for the Stack Overflow homepage changed a little while back, showing you even more relevant content and questions every time you log in. Content farms and how much they suck (but how amazingly funny and well written "The Content Farm" is. The recent launch of the HowThingsWork Stack Exchange and why it never made it out of its private beta.  In particular, it had the issue that it would have turned into almost just another content farm and not fulfill the Stack Exchange mission of making the internet better. The recent move to our new data center and technical changes that have made all of the sites faster and more efficient. How you can utilize improved networking in your data center to greatly improve performance with efficient upgrades The Internet Archive is an amazing service for preserving the history of the internet, but it never seems to get enough support.  Go and donate today! Is there such a thing as a question that is too simple?  What new guidelines should we give people when posting questions on Stack Exchange. And a fun fact about the Stack Exchange podcast: We have listeners in 85 countries around the world. See you next week when Jeff and Joel are joined by Scott Hanselman. One final note - we're re-numbering the podcast to start back at the beginning, so this is now episode #02 and last week is now episode #01.

Welcome back to the first episode of the new Stack Exchange Podcast redux!  Jumping right back into the old groove, here's what happens this week: Jeff and Joel discuss missing the openness that the old podcast provided.  Since the podcast is just a recording of their weekly call, it gives listeners an insight into the decision making and vision behind Stack Exchange. Some of the Stack Exchange metas have been having vibrant debates and discussions about the role of the community and moderators in shaping debates - but what are the unseen upsides to having this vibrant meta community? Joel has spent many hours over the last few weeks looking at user trends and patterns between the Stack Exchange sites - what has he found? The percentage of "civilians" (users whose first login was to a site other than StackOverflow, SuperUser or ServerFault) on Stack Exchange sites has grown to 36% since the launch of SE. * However, the recent stasis of the ratio not changing isn't due to civilian growth stopping, its that programmers are growing just as quickly. * Most interestingly, some of the "geekiest" sites (like Ubuntu, Math, Stats, Physics, TeX) have the highest percentage of "civilian" users. Launching this week is the beta of the brand new HowThingsWork community.  Jeff and Joel discuss its odds for success, challenges it faces, and lessons learned from the launches of past communities. There have been numerous discussionsover the last few months about the closing of questions for being "too localized" - Joel and Jeff discuss their (strong) feelings on how and when this should be used and why you shouldn't ask about why there's a pothole outside your house but you should ask why cities have so much trouble maintaining their roads in general. Plus, did someone successfully troll Joel on this thread? Coming up in September and October this year: it's Stack Overflow Dev Days 2011!  We'll be doing Dev Days in fewer spots this time (4 instead of 10) but they'll be bigger and better - plus running for two days instead of just one.  Dev Days will be taking place in 4 cities around the world, one each somewhere in the US West Coast, US East Coast, UK and Australia.  Stay tuned at the Stack Overflow blog for more details. Help us out - make sure to let us know what topics you want to see covered Joel and Jeff discuss their backup procedures and why you need to be careful whether using hard drives or SSDs.  Plus, why you really shouldn't be too concerned that Dropbox will decrypt your data if they receive a court order. Finally, we're going to have all kinds of interesting and upcoming changes for the podcast including guests, a live stream, a live chat room and maybe even video. A special thanks to our friends at SoundCloud for setting us up on their amazing audio sharing platform - you can check out this episode on their site or below (and even leave comments at specific times during the audio). Also, a big thanks to Friend of George over on audio.stackexchange.com for the recommendation on live recording software that we're using for the podcast now.

Joel and Jeff sit down with our new community coordinator, Robert Cartaino, to record a "bonus" podcast discussing the future of Stack Overflow and Stack Exchange 2.0. We hired Robert Cartaino as a full time community coordinator to act as both city planner, sociologist, and programmer with deep technical background. He will be pivotal in helping us move toward the brave new world of Stack Exchange 2.0. Rather than the old model of "pay us to use our software", Stack Exchange is now free. We're setting up a democratic process where the community itself will determine how and when create new communities. We liken it to Usenet 2.0. The tension for us is that we want to offer a public service -- a community commons that is owned, governed, and mostly operated by the community in a very transparent way -- but like Craigslist, we are walking the line between behaving like a non-profit company while remaining a for-profit company. As a thought experiment, we'd love it if that three years from now a new community is created in a language we don't even understand which meets the same criteria we originally created Stack Overflow, Server Fault, and Super User under. That is, it's a community you'd be proud to be associated with, and it fills the internet with useful, practical information. Our goal is to leave the internet better than we originally found it. The new site creation tool is currently under development and should appear in about a month for public participation. Right now there are 74 (!) site proposals on meta.stackexchange.com for initial discussion. We believe that removing money as a motivator actually frees people to participate simply because they love the topic, without being encumbered by the "don't make me think" factor of "is it worth my time to even do this at all?" We want to bring together the intersection of those people who love a topic, and want to make the internet a tiny bit better, one post at a time. As for ownership, there is a concept of site founders for those who commit to a site and follow through on that commitment, and interim moderators during the private and public beta will be chosen from the most motivated users. And of course all content generated will continue to be Creative Commons licensed and freely available to anyone who wants it. You are by no means alone -- we found that "build it and they will come" didn't work well for Stack Exchange. Under the new system, the community itself, us, will seed and support your site, and we will actively promote it as neighbor in our existing site network. We want to centralize and group community rather than fragment it, which is what the old SE model tended to do. One of our Big Hairy Audacious Goals is to achieve some form of mainstream awareness. This is something that Facebook and Twitter have achieved, but we don't feel that Digg and Reddit have. It's our hope that if we keep taking baby steps outside our core engineering / programmer safety zone that we'll eventually get there. There is a surprising amount of friction when trying to "move" an existing community to a new format. It's almost more practical to set up another community that runs in parallel and those who are attracted to the new format can move, while the old guard can stay with the comfort of what they know. We hope you enjoyed this "bonus" podcast. We're still not sure when or if the next podcast will occur; keep an eye on blog.stackoverflow.com for the latest news. The transcript wiki for this episode is available for public editing.

Joel and Jeff sit down with Anton Geraschenko to discuss the unique qualities of a community of expert mathematicians, how to capture a sphere in a knot, and the importance of off-site backups. The Stack Overflow team will be in NYC from April 2nd to the 9th for a planning session. Expect exciting announcements at the end of that period, including some that will affect the podcast. Maybe there will be a Stack Overflow morning zoo crew! There will also be a Stack Overflow open house in NYC sometime that week, so if you're in the area, please keep an eye on the blog! Anton founded Math Overflow, which runs on the Stack Overflow engine via Stack Exchange. Math Overflow might be the largest community of Math PhDs (and PhD candidates) on the internet. Anton, interestingly, is not a programmer so he was outside our initial audience. Anton attributes much of the initial success of Math Overflow to math bloggers, and most notably Secret Blogging Seminar. He also solicited emails from influential members of the math community and invited them to all participate at launch. Interestingly, Anton also cites the importance of a meta-discussion site to the overall success of a community. This is a conclusion we (well, I) had to be dragged to, kicking and screaming, before we finally created meta.stackoverflow.com. I suppose it is analogous to having a government of some kind before you can have a country. The meaning of Joel's oft-repeated phrase "no question is too easy" -- which I would rephrase as "no question should be uninteresting" -- has a whole different dimension on a site like Math Overflow which is intended for graduate level mathematics questions. Per Anton, you should probably ask "Does my community care about that?" We wondered if any Math Overflow question, given the highly specialized audience, could be popular in the broader internet sense. Anton cites Is it possible to capture a sphere in a knot? as a possible example. Math Overflow did some community specific customization by incorporating jsMath markup in their posts. This has always been the vision, to provide tools that tailor the 'wiki' aspect of the Stack Overflow to the needs of particular expert communities. They plan to switch to the newer MathJax soon. And LaTeX is of course a long term standard in this area. I now appreciate the importance of off-site backups. It's unlikely your datacenter will be hit by a meteor, but the odds of something going wrong with the air conditioning is much more likely. How likely? It happened to us! Remember kids, eat your Wheaties, and do your off-site backups! We're also entertaining the idea of a read-only mode for the website for these rare conditions so we don't have to tackle the very difficult problem of synchronizing data when you are running on a live backup. Since we haven't launched the Stack Exchange site on Siberian husky puppies (yet), Joel asks for some listener input on what type of treats his new dog Taco would like. Remember, podcast will be on hiatus for a bit while we retool it -- your suggestions are welcome in the interim, see you in about a month! The transcript wiki for this episode is available for public editing.

In this episode of the Stack Overflow podcast, Joel and Jeff discuss the pursuit of venture capital, why Joel is ending his blog, and the hidden power of Google's web spider. We were surprised that so many people who read Joel's article about our venture capital experiment were unable to imagine any way we could put millions of dollars to use. If you consider that our core mission is to kill software like vBulletin and phpBB, and you had millions of dollars, what would you do and how would you do it? We were also a little disappointed that some people thought we would be willing to damage the community in some kind of quest to create a business. Hopefully we can be given a bit more credit than that -- Joel and I may be dumb, but we're not dumb enough to destroy the very thing we're trying to create! Choosing a VC partner is like a marriage, and our philosophy is to only marry someone who has compatible views to our own. Even if we didn't take VC, the process of talking to all these smart people who have accomplished so much in the industry was illuminating, and helped us synthesize and crystallize our own strategy for what we want to do with Stack Overflow -- we're excited about it, and we think you will be too once we can talk about it in more detail! I was away for a two week trip with my family to beautiful New Zealand, where I gave a talk at Webstock 2010 titled Stack Overflow: Building Social Software for the Anti-Social. I'm buying a new laptop from Dell, and giving away my old Dell laptop to a deserving meta.stackoverflow.com community member. Joel is a hard-core ThinkPad fan, but I believe what the world needs is more of an Ikea PC hardware experience. Dell's design isn't quite there yet but it has gotten better. Joel elaborates a bit on why he's planning to quit blogging. There's plenty of precedent for leaving while you're still ahead, like Bill Watterson (of the comic strip "Calvin and Hobbes") did. After 10 years of doing the same thing, you might want to evolve and do something different, too -- but hopefully not vanish without a trace. I'm still trying to convince him not to quit podcasting. It's well known that 90% of our traffic comes from Google. But did you know that Google is about the only company with a competent spider, based on our logs? There are so many terrible spiders, even from large companies that really should know better. It's a chicken and egg problem; Google's spidering is so far ahead of every other search engine that I'm unclear how anyone could switch -- the result pages simply wouldn't be there! I have found the Howard Aiken quote "Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats." to be very true with regards to Q&A and Stack Overflow. The corollary to this is that if you don't have to fight people to convince them your idea is good, your idea might not be so hot. Even very smart people have to be in the right place at the right time to be successful. The best success strategy is probably dogged, bullheaded persistence, because there are so many variables you can't control or even predict. We answered the following listener question: Michael from Cambridge: "What if Google, or another large company, decided to clone your product and give it away for free? What should a hypothetical startup do if this happens to them?" If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879. The transcript wiki for this episode is available for public editing.

Joel sits down with the Stack Exchange team, who are working on the hosted version of Stack Overflow at the Fog Creek offices in New York City. Meet the Stack Exchange team -- David Fullerton, Aaron Maenpaa, and Emmett Nicholas. For Stack Exchange sites that have a smaller community, Stack Exchanges may email users more aggressively, to invite users to answer less trafficked SE questions. Joel proposes that weekly roll-up emails might work well on smaller Stack Exchange sites. Stack Exchange is a hosted service; it's currently running on 2.5 servers and soon a third. Stack Exchange has an export feature, so all the data in your site can be dumped out to a file, similar to the way the monthly Stack Overflow cc-wiki data dumps work. Joel blogged about Stack Overflow looking for venture capital -- that should not affect Stack Exchange. In any case, even if it did, you can use your own domain name which you take with you, and as mentioned above, you can export all your data. There should be competition, and smart competitors will support the Stack Overflow and Stack Exchange export formats. Stack Exchange pricing is already at maximum, primarily to reduce demand to a level that the current SE team can support. It can only go down over time! It is definitely our goal to make it easier over time for everyone who wants a Stack Exchange site to have one. We're exploring a lot of possibilities including ad subsidized; it's also possible that larger corporate adoption of Stack Exchange may subsidize the smaller community sites as well. Right now every Stack Exchange site has its own IIS website (even though they all share the same app pool), but that turns out to be not a great performance model for lots of small sites. One of the Catch-22s of a Stack Exchange site is that fundamental actions like voting up and creating tags require reputation, but nobody has any reputation on a new site. The Stack Exchange team added a "bootstrap mode" which relaxes a lot of these requirements so you can get your site up and running. David notes that a smooth admin / owner setup process is essential to the Stack Exchange service model. You also can't have a ghost town -- you need some questions bootstrapped into the system before you even show it to the broader public. This is analogous to the private invitation-only betas we did for Stack Overflow, Super User, and Server Fault. If you'd like to provide additional feedback to the Stack Exchange team, we encourage you to visit Meta Stack Exchange and help us dogfood our own system. If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879. The transcript wiki for this episode is available for public editing.

In this episode of the Stack Overflow podcast, Joel and Jeff discuss the promise and peril of Email (both social and technical), Google Buzz, and the value of training material. I will be at Webstock 2010 and in New Zealand for the next two weeks. I was excited to learn that the singer Wing is from New Zealand. Hear Wing in action. Don't say I didn't warn you. OK, maybe I didn't warn you. I encouraged Joel to have the Stack Exchange team on for a podcast while I am gone for two weeks. There's a lot of interesting re-engineering of the Stack Overflow engine necessary to support lots of small and medium sites on our engine. If you have questions from the Stack Exchange team, please contribute them to this Meta Stack Exchange thread. I am not a fan of email, to put it mildly, as I wrote in Is Email = Efail and Email: The Variable Reinforcement Machine. Given my discomfort with email, I struggle with the role of email on Stack Overflow -- mostly trying to keep it at arms' length while using it appropriately. I agree with Joel's position here, which is that aggressive email notifications are toxic to the growth of a community. That's why our email notifications are somewhat.. slow. It's intentional. Joel describes Jason Calacanis' cessation of blogging in favor of a private invitation only email list. He claims that it's a way of reaching people outside the normal domain of blogging. There are certain folks who just don't read blogs. Joel feels he has totally and utterly saturated the narrow world of programmers who read blogs, so it's worth experimenting with different distribution mechanisms and perhaps reach different audiences. The root of the email problem is that it's the kitchen sink one-size-fits-all communication medium, when in reality, there should be communication escalation (or de-escalation) to fit what you're trying to communicate. Tailor your choice of communication medium to the particular message you are delivering! Is email for old people? I do think younger people are correctly intuiting that there are more efficient mechanisms for online communication. As Joel notes, email is really the only canonical form of online communication that everyone is guaranteed to have. You may not have a Twitter or Facebook or Friendster account, but surely you have an email address. Everyone does! I am highly skeptical of the new Google Buzz because it is built on email. You just can't build a stable structure on top of a broken system, in my humble opinion of course. The act of sending mail is also incredibly complicated because spammers have abused the infrastructure for a decade. There are a few immune responses that are still effective, such as DKIM and Reverse PTR records. SenderID is another method, also based on DNS records, but it's less well regarded. If you're going to send email and you want it to arrive, you need to implement all this stuff! Joel has documented a lot of the process at Fog Creek in a series of training videos and a book, titled Make Better Software. Compared to most companies, Fog Creek is quite transparent in this regard, and I might even say they evangelize for better programmer working conditions. Our featured questions this week are: Server Fault: What's your recommended server room kit? A nice description of the key items any well provisioned server room ought to have. We answered the following listener question on this podcast: Pierre "Good programming training material is expensive. How can students obtain good training materials?" If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879. The transcript wiki for this episode is available for public editing. update: my 2010 webstock talk is...

In this episode of the Stack Overflow podcast, Joel and Jeff sit down with Mac developer Daniel Jalkut of Red Sweater Software to discuss his experience as a longtime Mac developer and small Mac software business owner, and the possible impact of the iPad. Daniel launched Red Sweater software way back in 1999 (and has been an active Mac developer since 1995), but it didn't become his primary business until 2005-ish. The big apps in his stable are MarsEdit, blog composing software, and Black Ink, a crossword app. There has been no iPhone version of these OSX apps to date because it wasn't a good fit, but the iPad is going to be a nearly perfect fit. In Daniel's experience, the primary change in Apple's software developer support story over the last 15 years is that Apple has become much more pragmatic in adopting developer tools from the UNIX and open source world. Remember when Apple had its own Unix, a/ux? Apple has a whole new alternative to gcc, the clang compiler. The Macmillan-Amazon Kindle incident highlighted how Apple entering the eBook market with the iPad and iBooks is actually disruptive in a good way, that benefits both readers and writers. Joel agrees that the iPad will probably kill the Kindle hardware. We think e ink is kind of overrated. It's not clear how much this matters to Amazon. It is bizarre that the Kindle app will be allowed to run on the iPad as a competing "app store" next to iBooks. I'm a little perplexed about the existence of iWork for the iPad, since it highlights the main weakness of the iPad -- while touch is great, the inclusion of keyboard support is odd, and I'm not sure how well it's going to scale to large screens and I think it's a weak replacement for the mouse paradigm. Joel and I think Steve Jobs never really believed that computers made sense as general purpose devices. Computers should always have been appliances, and the iPhone and iPad are manifestations of that. Steven Frank likens the iPad to the new world of computing, a bespoke from the ground up reconception of how computers should work, compared to the classic OSX, Linux, Windows desktop old world. Is lack of support for Adobe's Flash on the iPad the equivalent of dropping the floppy drive from early iMac models? I'd say the floppy drive was already pretty useless by the time Apple dropped it, whereas Flash is still kind of useful in a lot of circumstances, as John Nack notes. Particularly on a large screen device billed as delivering a no-compromises web experience. If Apple choosing to make a political statement about dropping Flash (on the iPhone and now iPad) results in websites built with better Flash fallbacks than an empty box on a web page, that is a good thing. It's just hard for me, personally, to accept that Apple is doing this out of the goodness of their own heart, rather than as a nakedly capitalistic way to protect the income stream from the App Store. It has been pointed out to me that Stack Overflow is powered by bored programmers, so it is in our best interest for programmers to be bored at work. Joel says that being bored says a lot more about a person's state of mind rather than whether the environment is actually boring. If you're bored while programming, "you are doing it wrong." There are several dimensions to improving questions on any site on the trilogy; primary among those is editing (at 2k rep), and there always is voting to close (at 3k rep), flagging for moderator attention (at 15 rep). And meta-discussion about questions is always welcome on meta.stackoverflow.com. Community moderation is an important part of our sites, and we're currently conducting an election to determine the next Stack Overflow moderator. You do need 200 reputation to have the right to vote, though. For more great Mac dev discussion, check out Daniel's podcast with Manton Reece, Core Intuition. We answered the following listener question...

In this episode of the Stack Overflow podcast, Joel and Jeff discuss the value of Deep Blue, the Five Whys process, and whether programmers should blog. If you work at a fancy company like Fog Creek, you'll have access to a Latte machine, and you too can create Latte art! Checkers is now a solved problem. Chess is almost solved, in that no human player can beat the best software chess engines. In other news, Joel solved tic-tac-toe. Deep Blue was amazing technology for its time, but what was the value in IBM doing this, and pitching it as the epic man vs. computer chess battle? What other companies could pursue cool, useful computer science spectacles like this? a followup to our GitHub conversation last week, clarifying some things we didn't quite get right in our previous conversation. Joel notes that a random programmer at JFK approached him and told him how much Stack Overflow Careers helped him. We have a number of success stories that have arrived via email, twitter, and in person. Incidentally both Stack Overflow and Fog Creek are hiring, and guess where we look first for candidates? As we partially covered in Podcast #64, it's difficult to find good testers, because it's a related yet different skill from programming. A discussion of Joel's article Five Whys -- we seemed to have the same problem of failed network autonegotiation, but we discovered at least one more Why. Per our Server Fault question on ethernet autonegotiation sysadmins seem to agree that "problems" with gigabit ethernet autonegotiate, at least, are almost always symptomatic of deeper root problems. When setting up a portfolio of your programming work, what you want to do is stand out among the crowd. What are the shiny beacons you can put in that would get employers excited? Don't get too detailed too fast, so feel free to use pictures and diagrams -- there's always room for details later. We don't like take home programming tests, but is it useful to document the process of how you research and solve a problem? Joel maintains the real win is to over-solve the problem to show what a hard worker you are. Some tips from Joel and Jeff about why and how (or if) programmers should blog. Set a schedule and stick to it. And don't be a commodity blogger! It helps to focus on the storytelling aspect of the writing, per Ira Glass. And remember, writing a better article on any topic is usually pretty easy, because so much of the content on the internet is so darn bad. Please submit your audio questions to the podcast -- we have brand new Stack Overflow t-shirts and the best question next week will get one! We answered the following listener questions on this podcast: Alison: "I work closely with hardware and firmware, and I have trouble figuring out how to show off my work to my prospective employers. How do I build a portfolio?" John: "I recently started a programming blog at simpleprogrammer.com. How important is it for a programmer to have a blog, and why?" If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879. The transcript wiki for this episode is available for public editing.

In this episode of the Stack Overflow podcast, Joel and Jeff discuss GitHub, the value of formal code documentation, and how to decide what features belong in the next version of your software. We've had some difficulty adapting to GitHub, where the reverse engineering of the Javascript Markdown (WMD) editor was performed. It regularly confuses everyone that encounters it, and that's frustrating from a support perspective. For example, why does the MangOS project on GitHub have 854 branches? How is that useful to anyone? The project network is so complex it can't even be rendered! What I specifically object to is that all pulls show up in the timeline as forks; I'd like to see an ability to nominate your pull timeline as either private or "not intended for merging" so it won't show up in the main network. Joel is writing a series of articles about distributed version control in Mercurial -- I'm hoping they will clear up some of my confusion about GitHub. I personally find Google Code much easier to work with. As part of MarkdownSharp, our open source C# Markdown implementation, I've experimented a bit with turning a regex into a state machine -- and I was a bit shocked how many lines of code it takes to "unroll" a regex. Is it really easier to troubleshoot 25 individual lines of state machine code (all with potential bugs) or 3 single line regular expressions? Stack Overflow user William Shields has taken up Joel's challenge to write a Markdown parser the right way -- and produced an excellent series of articles about what he's learned in the process: one, two, three, four. It's a perfect example of the type of learning that Stack Overflow itself is all about; kudos to William for sharing it! Joel and I have mixed feelings about documenting a large code base. Rather than wasting time generating reams of documentation that may never be read, and will rapidly get out of date -- we offer some alternatives. Come up with a unit test suite that lives symbiotically with the code, or spend time documenting the key, central data structures instead of the code. Also, have the new hire guys and gals who encounter the code be in charge of keeping the "how do I get started with this stuff?" bootstrapping information up to date. Joel says the least amount of work you need to do to capture how many hours are spent on programming tasks, is to make each source code checkin assume that all time since the previous checkin was spent on whatever the current task is. This is "good enough" in his experience and produces solid, useful future estimates. At Fog Creek, to determine what features make the cut for the next version of the software they get developers, customer representatives, and the sales team together and do T-Shirt size estimation (S through XXL) of development time for the desired features. Then everyone in the meeting has a dollar to spend on their favorite features. Then, just fit the winners into the allotted schedule. Stack Overflow is a community driven site, so many (but not all) of the new features come from top voted Meta Stack Overflow requests. We try to avoid devolving into design by committee by heavily weighting feature requests that match our vision for the site. Most feedback is not terribly useful -- but if you're willing to spend the time it takes to filter out the bottom 90% of feedback, you may be pleasantly surprised by the cool ideas the community can come up with. We answered the following listener questions on this podcast: Dave: "I work at a large company with an enormous code base in many different languages. As a new guy trying to find my way around, I get frustrated by the lack of documentation. How much documentation is appropriate?" "We had a new year's resolution to capture an accurate work log of hours worked, but we've already relapsed. How do the Fog Creek developers manage to do this?" Chap: "How do you prioritize features and functionality for your products,...

In this episode of the podcast, Joel and Jeff discuss open sourcing Markdown, the necessity of barriers on the open internet, and the importance of design in the software process. We highlight three interesting Stack Exchange sites: Climate Deal (environmental climate change issues), ASCOM Answers (astronomy tech), and Math Overflow (professional mathematicians). Thanks to Anton Geraschenko (the operator of Math Overflow, who I erroneously, embarrassingly, and repeatedly refer to as "Jacob" in this podcast -- my apologies) for his help with improving our client side Markdown implementation. We also have a server side implementation of Markdown, which is now open sourced at Google Code. The original Markdown implementation was in Perl. As a result, there is an unfortunate tradition in the community of writing Markdown parsers using a slew of regular expressions. This leads to some rather dense and complicated code with a lot of hairy edge conditions. Like most Perl, it worked well for the 95% case but that last 5% is extraordinarily difficult to achieve. Joel argues that if the community had started out writing a proper Markdown parser using standard tools like Yacc, Bison, Lex would have produced much simpler, easier to maintain code. I tend to agree that this is kind of a textbook example of where "the right way" would have perhaps been easier in the long run than the quick and dirty hack. Take a look at the core HTML block parser in the much better maintained PHP implementation. It is three full screens .. of a single regular expression. This is the most complex regular expression I've ever seen that was not a joke of some kind, and it's the core of the PHP Markdown implementation. Compiling this enormous regex in .NET causes my super-fast machine to freeze for several seconds. Running an open source project has reminded me of Derek Sivers classic article -- Nobody's going to help you. Does that encourage you or discourage you? You have to be more dedicated to your open source project than anyone else in the world. Your dedication will inspire others to follow. Unfortunately, blessing something as open source does not magically synthesize leadership. This is why I was a bit critical of John Gruber's handling of Markdown, as I felt the lack of action was starting to harm Markdown. Regardless, we donated to Markdown along with all the other parts of our development stack that we rely on. We hope to make these donations a yearly tradition. The idea that you should have no barrier to participation on the open internet isn't just a myth, it's a dangerous and destructive myth. We believe you need a barrier to keep those people who aren't serious out. For example, Wikipedia intentionally does this. We aren't talking about a concrete wall lined with razor wire, but a toddler sized barrier to keep the most bored and uninteresting users (or, if you prefer, "the majority of the internet") away. Joel explains why he no longer believes in outsourcing design; they are hiring a designer to work at Fog Creek full time. We compare the differences in the hiring process for designers versus programmers. Our philosophy of design on Stack Overflow is to try to do as little as possible, but make those few things polished as we can. While there's always room for improvement, and we love whitespace and minimalism, there is an issue of information density that is totally intentional -- particularly on the homepage. Item number 11 of the Joel Test ensures that you work for a company where they ask candidates to write code during the interview. The essential part here is not the production of the code, per se, but observation of the work actually happening. You need to know how the sausage is produced. There is a website that conducts programming tests on the internet for you at Codility, but we're skeptical this can actually work without the one-on-one human element of observati...

In this episode of the Stack Overflow podcast, Joel and Jeff sit down with Paul, David, and Matthew -- the creators of Litmus and DocType -- to discuss ASCII vs. pixels, the power of Amazon EC2, and the unglamorous but critically important topic of backup. The fine folks at Litmus created DocType partly as a homage to the Stack Overflow engine. We were so impressed we invited them into our League of Web Justice. You can view DocType as the intersection of what Litmus does (screenshots of browsers and email clients rendering HTML) and what Stack Overflow does (Q&A). Where the Stack Overflow Trilogy is about programmers, sysadmins, and power users exercising ASCII text, DocType and Litmus is about designers exercising pixels. It's not an audience we can satisfy particularly well, which is why we were happy to partner up. It's all about getting good, effective answers to your questions, regardless of which site provides those answers. A bit on the technical underpinnings of Litmus. This app has to generate screenshots from a ton of different email clients and a ton of different browsers, for both Macs and PCs. The PC side is served by Amazon Elastic Compute Cloud instances, which was an incredible boon for this type of work. They actually scale up to 400 EC2 instances at peak load times. The original version of Litmus was built using nothing but scripting on a single machine, but was enough to get customers. They were effectively running on a prototype; the entire app has been rearchitected several times since then. DocType is built mostly in Ruby on Rails, and Litmus is a combination of C# and Ruby on Rails. In that sense, they also reflect the platform agnostic spirit of Stack Overflow. A brief discussion of the state of the DocType community. One point of integration between the two sites is that people having difficulty solving layouts problems via the screenshot service in Litmus are encouraged to ask for help on DocType. Joel points out that one way to get a critical mass of core users is to get some kind of sponsorship or mention by people who have large audiences. For example, if you're starting a music site, try to get Derek Sivers to mention you or, better yet, become the godfather of your site. Anyway, always have the goal of making something that is useful to somebody -- and start with yourself. We are a little tired of the backup topic at this point, but maybe it's a good thing to remind people that every day is International Backup Awareness Day, and it never hurts to revisit your own backup practices, as we did with our Stack Overflow backup policies. RAID is not a backup, but I sure do wish the server which experienced the hard drive failure had some kind of basic mirroring in place to protect against exactly this kind of routine, mundane drive failure. The moving parts are what tend to fail, which is why all our Stack Overflow servers use RAID. Joel elaborates a bit on the importance of focusing on recovery versus backup. There are a lot of ways a valid "backup" can go horribly wrong, and you will never know any of that until you actively restore a backup. Our featured questions this week are: DocType: How does Doctype generate the screenshots they use on the site? A nice description of the ImageMagick commands used to generate the nifty little DocType screenshot thumbnails. SuperUser: Recovering a lost website with no backup? The short vc"go back in time and do proper backups." The long version is, "How patient are you?" We answered the following listener question on this podcast: Travis from Wisconsin: "I have a music based Stack Exchange site called keyminor.com. I have a ton of questions I plan to seed the site with, and I have a bunch of users I plan to approach for assistance. What's the best elevator pitch for getting people to understand and check out a Stack Exchange site?" If you'd like to submit a question to be answered in our next episode, record an a...

In this episode of the Stack Overflow podcast, Joel and Jeff discuss how to (accidentally) destroy your software business, Google's new DNS and page speed rankings, and why the most productive employees aren't paid 10 times as much. Just as a disaster planning exercise, what kind of things could happen that would destroy your software business? Your website? Joel proposes doing test failovers for live customers. He says the important metric isn't measuring how long you are down, but how fast you can recover from being down. How much down time per month is acceptable for a service? What's your agreement with your customers? Does a free service even have "customers"? If catastrophic failure doesn't get you, what about the more pernicious and subtle problem of users losing interest in your site, such as what is currently happening to MySpace? One software development parallel to Joel's position on recovering from datacenter failure -- how quickly you can iterate and fix your software product is probably more important than having perfect releases. Google may start prioritizing sites in search results by page load time. This makes total sense to me, as I am willing to forgive a lot if a site loads quickly. The quicker it loads, the quicker I can determine if the site's content is what I was looking for or not. Speaking of Google, they introduced a public DNS service which is optimized for speed. Joel theorizes this is to replace broken ISP DNS services. It's ad-free, which is an odd juxtaposition to the free, ad-subsidized OpenDNS service it will inevitably compete with. DNS speed is definitely important; we outsourced our own authoritative DNS servers as discussed in Podcast #68. What would the world we be like if employees who are 10 times more productive than their coworkers were paid 10 times as much? We're not sure, but I predict the rapid end of that company and possibly civilization as we know it. It's an interesting thought experiment. Joel says all developers should know C. I'll counter by saying it's far more important that all developers know the fundamentals of databases than how to write a working pointer based string copy algorithm. In our experience, one of the easiest ways to ensure failure on a software development project is to micromanage, get in their way, and put barriers in front of them. For best results, give the team everything they need, along with a strong vision statement, get out of their way and let them own it. It seems that every programming language has some kind of evolutionary dead end in it -- language features that, while part of the core spec, almost every programmer working in that language will actively discourage you from using. Some of this comes down to issues of programming style that you should agree on as a team, but some of it evolves into generally accepted lore for that language. Joel is offering a free Fog Creek t-shirt of your choice for the best question asked next week — so get those (audio only, please!) questions called or mailed in! And leave us a way to reach you. Our favorite Stack Overflow question this week: Have you ever restricted yourself to using a subset of language features? This is the question C++ was born to answer. We answered the following listener questions on this podcast: Kelly French: "If it's true that some programmers are 10 times better than other, why don't companies pay 10 times as much for these star programmers?" Brad: "What is your opinion on developers creating databases? What if you work at a company where only 'Data Architects' can create databases, and programmers aren't considered competent to create a database?" If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call t...

In this episode of the Stack Overflow podcast, Joel and Jeff discuss the Stack Overflow Careers philosophy, online community growth patterns, and how to tell if you're Sid Meier or not. Stack Overflow Careers is now fully open for business! Joel explains what it's all about, the proverbial programmer search engine. One thing we have resisted is employer demand for a sort order of CVs by Stack Overflow reputation scores. This is sort of like colleges sorting incoming applications by SAT or ACT scores. We have a brief discussion about how the college admissions process relates (or doesn't) to job "admissions". Joel shares his tips on what makes a CV / resume look good to him. And remember, Joel wrote the book on this stuff! So in theory, at least, he knows what he's talking about! Fog Creek does a lot of hiring every year. Now that we have a so-called "Careers" site on Stack Overflow, any perceived crossover between your professional life and online life is 100% intentional and by design -- as correctly noted by the Cerebral Mastication blog. I am now required by law to link to this amazing and hilarious SO post (on the perils of matching XML with regex) which already has a stunning two thousand upvotes! It went hyper-viral. Should we allow Facebook questions (or other questions specific to a website) on Super User? It's a bit complicated because websites are becoming legitimate "software applications" in today's computing world, and even more so in the future. The line between a traditional software executable and a website is becoming less and less clear. Discussing how you scale a community on Stack Exchange -- is it about having lots and lots of questions, or garnering a solid audience of experts? There appears to be a distinct difference between the early, adolescent, and mature stages of a community. You have to plan for and adapt to each stage; there is no "one size fits all" approach. I'm reminded of Robert X. Cringely's classic essay Commandos, Infantry, and Police. Joel's counterpoint is that maybe you're actually working with Sid Meier. My counterpoint: everyone wants to think they're Sid Meier, but as in Highlander, "There can be only one". Per Joel, programming is not about knowing a programming language any more than being a concert pianist is about knowing how to read music. But is programming anything like creating art or music? Joel is offering a free Fog Creek t-shirt of your choice for the best question asked next week -- so get those (audio only, please!) questions called or mailed in! And leave us a way to reach you. We answered the following listener questions on this podcast: Josh from Taiwan: "I'm looking to move from QA into programming. Is it better to know one language really well, or lots less well? Also, does Objective-C pass the Joel Test of knowing C?" If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to podcast@stackoverflow.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879. The transcript wiki for this episode is available for public editing.