The Stack Overflow Podcast

A collection of clips recorded at the San Francisco DevDays conference, including Joel Spolsky, Mark Harrison, Jeff Atwood, Scott Hanselman and Rory Blyth. This episode runs a bit longer than usual.

Joel Spolsky on web usability

Mark Harrison on Python and the Norvig spell checker

Rory Blyth on iPhone development

Scott Hanselman on ASP.NET MVC 2.0

Jeff Atwood on Stack Overflow

Ad-hoc roundtable podcast with Scott, Rory, Joel, and Jeff backstage at DevDays. Warning: extreme ramblosity ahead!

Joel explains his Duct Tape Programmer post. Apparently DevDays is a duct tape conference, and this section of the recording is a duct tape podcast.

Some discussion of the ubiquity of mobile code. Also, if you are nostalgic for the era "when development was hard", the consensus is that you should be doing mobile development today on iPhone, Android, Windows Mobile, or Symbian.

Rory elaborates on his experience with (and effusive opinions on) iPhone development to date. Is coding in Objective-C best accompanied by a flux capacitor, New Coke, and Max Headroom? Also, his excitement for MonoTouch.

Joel and Scott put on their amateur language designer hats and have a spirited discussion of type inference and Fog Creek's in-house DSL, Wasabi.

Scott covers some of the highlights of new and shiny features coming in the Visual Studio 2010 IDE, the C# 4.0 language, and the ASP.NET MVC 2.0 web framework.

Our favorite questions this week:

How do I create unicode smileys? So far beyond :) it isn't even funny. Who knows, you might even learn some typography along the way!

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 [email protected]. 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 podcast, Joel and Jeff discuss DevDays, the diversity of Stack Exchange sites, the debut of CVs and careers on Stack Overflow, and the viability of WiFi at tech conferences.

Stack Exchange is now officially in public beta! There are a huge number of sites running on the Stack Overflow engine. Far more than I expected at this early stage, anyway.

The Stack Exchange sites are pushing the boundaries of the specific audience (that is, programmers) we designed it for. Consider the audience overlap between answers.onstartups.com, epicadvice.com, and moms4mom.com. I was getting usability reports from my wife on that last one, which was quite surreal. Also surreal: that Jon Skeet is a top user on one of the above. You'll never guess which one!

Do some of the Stack Exchange sites compete with Stack Overflow? Such as ask.sqlteam.com and snippetgood.com? Not necessarily; if you're particularly enthusiastic about some niche, you'll get more questions and tighter focus of community by going to site dedicated to that topic.

Joel feels that Stack Exchange works so well as a support forum that he's shutting down all the other online FogBugz web support tools in favor of fogbugz.stackexchange.com.

What's the minimum number of knowledgeable, invested users you need to have a functional online Q&A community? Joel says one (!). I think it's more on the order of a few dozen. The software part is easy, the real hurdle is this: can you rustle together a core community of a few dozen enthusiastic, knowledgeable folks?

An extended discussion of our new careers section of Stack Overflow, which we launched last week. Joel sort of wrote the book on this topic, with Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent. Our careers approach grows out of Joel (and my) dissatisfaction with the current status quo. It sucks, and we'd like to build something better.

This is the philosophy behind careers.stackoverflow.com : smart companies should be pursuing good programmers, and not the other way around. We also want to cut out the cheesy for-pay contingency recruiters (or any other middlemen, for that matter) from the mix, and directly connect passionate programmers with companies that understand the value of programmers who hit the high notes.

This is Fog Creek's guarantee for every service they charge money for: "The Fog Creek Promise: If you're not satisfied, for any reason, within 90 days you get a full refund, period, no questions asked. We don't want your money if you're not amazingly happy." Stack Overflow has adopted this promise as well. Why don't all companies do this? Why would you want to keep an unsatisfied customer's money -- it generates ill will far out of proportion to the tiny amount of money involved.

As a part of careers, we're planning to roll out free, public CVs with user-selectable "vanity" URLs in a week or two. In retrospect, we should have done this from day one, as it compliments the public record of your Q&A on Stack Overflow. As Joel notes, the best way to control your online presence is to fill it yourself with all the cool stuff you've been doing! Don't let others tell the story of you when you can tell it yourself.

Our favorite question this week is from Server Fault:

Why is Internet access and Wi-Fi always so terrible at large tech conferences? Based on Joel's recent DevDays experience, reliable WiFi at tech conferences seems to be rare. Why? How can this be fixed? What does it take?

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 [email protected]. 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 and Jeff sit down with Peter Seibel to discuss his new book Coders At Work, the effect of listening to music while coding, and the future of programming books.

Peter draws on some commonalities in the 15 famous programmers he interviewed for Coders at Work.

Peter agrees with Joel that concurrent (threaded) programming is some of the hardest programming anyone can do -- even the extraordinary programmers he interviewed concur on this point.

Susan Lammers' book Programmers at Work was the early inspiration for Coders at Work. It's a similarly fantastic read. The other book in the same series, Founders at Work, is a great (albeit less technical) too.

Many of the programmers interviewed (with the lone exception of Brad Fitzpatrick) got their start before home microcomputers such as the Apple II were even available. But they all spent deep, huge hands-on volumes of time on a computer, somehow.

One big sea change in the last 30 years of programming: per Jamie Zawinski, "these days, almost all software is social software". The days of the solitary, disconnected programmer toiling away in a server room are essentially over.

Even a hardcore game programmer like John Carmack (who, sadly, could not be reached for interview in Peter's book) has gone on record with a back to basics approach: "if I were off by myself, I would want to become an iPhone game developer."

Does listening to music affect your ability to program, positively or negatively? Joel cites one unpublished study, then goes on to mention that he occasionally watches video while programming. Is there any actual, verifiable data on this either way?

Have we passed through the "golden age" of technical books? Are technical books dead? What niche will books fill for programmers in the future? Joel and I both remember poring over programming manuals in great detail in the early days because there were no other sources.

We answered the following listener question this week:

Stuart: "Do you have any opinions on listening to music while coding? Is this a viable alternative to having a private office?"

Our favorite questions this week:

Proposal: Free Vote-Based Advertising for Open Source Projects. We'd like to put some of our Stack Overflow remnant ad inventory to work for the community via voting and popular nominations. The goal is to highlight useful and interesting open source projects that programmers might not be aware of.

What is the single most influential book every programmer should read? Why, Coders at Work of course! This was one of the first popular questions posted on Stack Overflow during the private beta; programmers do love their books.

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 [email protected]. 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 and Jeff discuss outsourced DNS, virtual machine "appliances", and programmers as library users versus library writers.

As a dyed in the wool fan of fake plastic rock, I am required by law to mention that The Beatles: Rock Band was released last week. It's great!

We changed DNS providers, as our existing registrar's DNS service was highly ... irregular.

Should you pay for outsourced, dedicated DNS? What do you get for that money? What kinds of value can outsourced DNS provide? What clever things can a smart DNS provider do?

If you need to troubleshoot your DNS, try DNS Stuff.

DNS is heavily cached throughout the internet, but I think we overestimate how efficient these distributed caches are. For example, Yahoo found that 40-60 percent of their users have an empty browser cache experience. There is value in having a fast, distributed core service for the no-cache scenario.

A brief discussion of our use of virtual machines in our little server farm. Since the only trouble spot for VM performance is disk, that gives us the flexibility of using a lot of great Linux and open source tools for networking (no or very little disk dependency), such as HAProxy and Cacti.

Sometimes people should question the premise of your question; as in our Server Fault question about having two default gateways, it turns out that the only sane answer is "don't do that."

When it comes to Stack Exchange, the broader the topic, and the more unanswerable questions you have, the worse the engine will do for you. The engine is designed for reasonably narrow topics, with a majority of questions that can actually be answered in some reasonable way.

Joel likens the classic divide in software developers to "library users versus library writers". At what point do programmers cross that chasm? Do they need to? Joel says "we write one algorithm per year."

How do you deal with the dancing bunnies problem? Also known as the Dancing pigs problem. "Given a choice between dancing pigs and security, users will pick dancing pigs every time."

We answered the following listener questions this week:

Steve: "The etiquette rules for meta are much looser than on the other Trilogy sites. Does this have ramifications for Stack Exchange sites?"

Brian: "Technology changes so fast that most developers burn out in 20 years. How do we retain our historical knowledge if the rate of attrition is so high?"

Our favorite questions this week:

How can I gently explain to non-techie friends they are the victim of a hoax? It is part of the responsibility of a true superuser to tend to those users who can't protect themselves.

What is the worst real-world macros/pre-processor abuse you've ever come across? The C, she is dangerous!

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 [email protected]. 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 ethics of Craigslist, the pitfalls of customer-installable software, and caching for anonymous web users.

If you'd like a Stack Overflow, Server Fault, or Super User sticker, you can now get three! Just send a SASE to Fog Creek software as documented in this blog post. Please don't start a Ponzi scheme with those international reply coupons, though!

There was a excellent, huge Wired article on the pros and cons of Craigslist, titled Why Craigslist is Such a Mess. I am mentioned in the article, as an example of someone who created an tool to do all-city search that got shut down by Craiglist, which is quite militant about controlling the service.

Joel feels that what Craig Newmark is doing with Craigslist is a brand of evil, in that it has destroyed the income stream (classified ads) that supported professional journalism. Craigslist was one of the models we studied extensively when building Stack Overflow, even cribbing their flagging mechanism. Joel and I have an extended discussion about the ethics of Craigslist.

Joel and I disagree about the future of professional journalism; I think the newspaper business model was fundamentally flawed. It is tempting to blame Craigslist for the downfall of newspapers, but if it wasn't Craigslist, someone else would have done the same thing. For a thoughtful discussion of the topic, check out Clay Shirky's article Newspapers and Thinking the Unthinkable.

One side effect of Craigslist being free and incredibly popular (more pageviews than eBay and Amazon combined) is that they are breeding the perfect spammer. We looked at Craigslist as an key example of designing for evil. We suspect that over time Craigslist might have to start charging money for most, if not all categories.

Joel's Stack Exchange playground is biztravel.stackexchange.com, but we need better color schemes. I think we need to have a contest to set some reasonable default color schemes for Stack Exchange customers to choose from.

One thing Joel has learned from selling Fogbugz: software designed to be installed on a server in-house at a customer's site, under full control of that customer, is almost never worth the hassle. Virtual machines, or the software-as-appliance models, are more sustainable. But most companies won't allow outside vendors to remote into the app to troubleshoot it, either.

A tremendously important part of designing a large public website is optimizing for anonymous user access, which will be a large proportion of your traffic. At Stack Overflow, even before our public launch in September, we spent a lot of time ensuring that anonymous usage is aggressively and heavily cached.

Our favorite Stack Overflow trilogy questions this week are:

Countdown app for DevDays. Joel needs a cool app to help start DevDays sessions on time! Here's an opportunity to show off your mad coding skills, and have your software prominently featured at every DevDays venue.

We answered the following listener question on this podcast:

David Smalley from DocType: "Shouldn't websites optimize heavily for anonymous usage patterns?" Absolutely!

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 [email protected]. 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 reverse proxies, the pitfalls of self-support communities, and designing for engagement.

It is my intent to attend the London and Cambridge DevDays, if my passport comes back in time. Speaking of which, is there anything funnier than a baby's passport picture?

We officially disabled the built in ASP.NET Session state, so as to set ourselves up for multiple Stack Overflow servers. Fortunately, we don't need a lot of shared state, but we were using it in a few places. We created a small database table to store the small bits of per-user state that we need.

I take an inordinate amount of joy in deleting code from our project. Nothing is more satisfying!

To switch over to multiple servers, we need some kind of load balancer. We chose HAProxy, but we also had to configure tproxy (transparent proxy) support so that the IP addresses arriving at the web servers are not all the same.

For now we'll be load balancing using a simple hash of the incoming IP address. Depending on which hash you get, you may end up on a different server, but you'll stay on that server as long as your IP address is stable. This is a fairly crude form of balancing, but should be sufficient.

It's incredible how aggressive Google's indexing of our site is; it regularly pulls down a gigabyte of compressed text from us per day, and it wants to do even more. One of the primary motivators for adding a second server is to reduce the traffic load enough so that we can "unleash" google via webmaster tools.

A belated welcome to our newest and third site in the trilogy, Super User -- it's for any general computer software or hardware questions, but we've already had to disallow videogaming questions.

How much overlap will there be between our public websites, and the sites launched through the Stack Exchange service? But remember, the software (however great it may be) is the easy part. Building a community is the truly difficult part! To succeed, that's what you should focus on.

Joel discusses the shifting meaning of "Beta" -- it's been contorted into "the first five years of a product". But there is an art to the classic beta, in terms of releasing in a staggered fashion to fresh testers who haven't seen it yet.

Google's self-support model is often unsatisfying because it is community driven, yet the community is powerless and has no real stake in developing the product. They're given padded rubber rooms to bounce around in harmlessly. That's not a good way to build community.

Google needs a lot more evangelists out there interacting with the community and bringing messages back and forth to the mothership. This is something that Microsoft does extraordinarily well, but Google does not seem to "get it".

A brief discussion of some key changes to (hopefully) increase engagement between question asker and answerers. The goal is for answerers to be able to quickly scan a question and see if they're dealing with someone who cares, or not.

The default votes answer sort order had a flaw: the sub-order was relevant! We now use random as the sub-order to the votes sort, to minimize any effect of the sub-order. Answers will now appear in random order if they have the same number of votes. Answers should be voted up because they're inherently good answers, not because they happen to accidentally be on top at that particular moment.

We answered the following listener questions on this podcast:

Nathan Long: "Is it valid to discuss iPhone and Blackberry questions on Super User?" This has been discussed on meta.

Brian Kelly: "Is there any formal organization for potential candidates to meet employers at DevDays?"

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 [email protected]. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phon...

In this episode of the podcast, Joel and Jeff discuss lessons from a year of building Stack Overflow, the mysteries of COBOL, some YSlow website optimizations, and magic numbers.

What have we learned in a year of building Stack Overflow? If someone wanted to design a system like Stack overflow, I'd give them these two pieces of advice. First, never have any unbounded behavior in your website. Anywhere. Bounding, velocity and rate limiting, should be pervasive throughout your design from day one. Second, provide an outlet for meta discussion from day one. Unless you provide a teacher's lounge, or afterschool activities for the students, you haven't completed the experience.

In our experience, the best way to manage online behavior is to make the positive behaviors fun and rewarding. If you do this right, the bad and negative behaviors fall by the wayside. (Although you also, regrettably, will still need tools for dealing with rare but aberrant behavior.)

Neither Joel or I have ever met a COBOL programmer. That's why we're skeptical of these dramatic claims that the world is overrun with invisible COBOL code. There are, surprisingly, some good COBOL questions on Stack Overflow, but it's a tiny fraction.

How much COBOL code can you fit in the 1 megabyte (at most!) memory that these 60's and 70's era servers had? Or the tiny hard drives?

Is what happened to COBOL programmers eventually what happens to all programmers? Take SQL as an example. If you have 256 gigabytes of main memory -- not very expensive already, and getting cheaper every day -- is all that SQL and disk stuff still relevant?

We recently spent some time improving performance on Stack Overflow, and as always we've learned that whatever we think is slow, is not, and the part that is slow is in a totally unexpected area of our code. Never assume you know where a performance problem is, because I can almost guarantee you're wrong. Profile it and look at the data!

We've seen huge benefits, more than anticipated, by moving our static web content to a rate, cookieless domain. (We registered sstatic.net for this purpose, which explains the rationale.) This is one of the key recommendations from tools like YSlow and Google Page Speed. It's a surprisingly effective form of poor man's web farm scaling.

A brief digression into the "why does anyone still use IE6" argument. Here's Microsoft's official position, as crazy as it may seem.

We may be at the end of the road for the low hanging fruit of website performance optimizations. Of course we can always buy faster hardware. But that doesn't fix the speed of light problem. Given our large international audience, I sort of wish we could have multiple server farms in different geographic locations, but that may be quite a long way off.

Computer "magic number" number bugs are kind of fun; you may remember a very public Excel bug in this vein. Joel once got a credit card with an expiration date set in 2049, which is technically valid, but it barely worked anywhere.

Our favorite questions this week:

Is 23,148,855,308,184,500 a magic number, or sheer chance? A fascinating tale of programmer number forensics.

How to learn Cobol. OK, but first of all, why in the world would you want to do this?

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 [email protected]. 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 and Jeff discuss the disappointment of Google AdSense, the difference in skillset between programmers and testers, and the value of standards groups to working programmers.

If you have feedback for Stack Exchange (still scheduled for beta by September 1st), please leave it on meta.stackoverflow.com under the Stack Exchange tag.

The speaker list for Stack Overflow DevDays is coming soon, it's looking really impressive so far. For example, both John Resig (of jQuery fame) and Miguel De Icaza (of Mono fame) will be at the Boston leg, and there are still seats available! There's also a rumor that Jeff Atwood, whoever that guy is, may show up in London.

We are forming a League of Justice on the web. The first new hero in our league is How-To Geek, of the most excellent How-To Geek website. It's the editorially cultivated content yin to our user-generated yang.

On the crushing disappointment of Google AdSense on Stack Overflow. The theory of AdSense, matching topical ads to the content on the page, is fantastic. The reality of the type of ads we actually saw on Stack Overflow is a terrible disappointment. They were barely relevant, and often quite ugly.

Our hand-selected ads, targetted to our audience, perform 50 times better than AdSense. We believe that if Google could somehow tag a site with a specific audience topic (such as, say, "programmers") it would do much better.

If a site like Stack Overflow, which does almost a million pageviews a day, can't make enough to cover even one person at half time using Google AdSense, how does anyone make a living with AdSense? Does it even work?

Joel says the only people making decent money with AdSense are scammers who specifically build websites to do nothing except target high pay-per-click keywords. I am not sure this is what Google had in mind. It is a stunning indictment of "the power of the algorithm".

Our ad partner is Alex from The Daily WTF, and we take responsible advertising seriously. The right kind of advertising, the relevant, interesting, thoughtful kind is win-win. And always in moderation. We are willing to leave money on the table to have the right kind of ads that we like editorially.

Joel has a great discussion about the difference in skillset between a good tester and a good programmer. "There's something about the nature of the work that's different enough that a lot of good developers are bored by testing, and a lot of testers are too detail-oriented to get anything done as a developer." Some programming skills are helpful, but they're different.

There is great risk in creating standards in advance -- how do you know if you're solving a problem people care about, or even the right problem in the first place? Also, the disconnect between the theory and practice can be rather painful.

Who can we blame for the codified misspelling of "referer"? I would like to have some words with this person.

We frequently use Stack Overflow to build Stack Overflow. It's almost a recursive endeavor. If you browse the questions the team asks on Stack Overflow or Server Fault, many of them are directly related to development and deployment issues on the sites themselves!

Our favorite questions this week are both from Super User, which for now is still in semi-private beta. If you need the password it is "ewok.adventure" without the quotes.

Upgrading from Windows 7 RC to Windows 7 RTM. It's perplexing why Microsoft doesn't officially support RC to RTM without a little hack.

Troubleshooting Failed Upgrade to Windows 7. Three out of four of my Vista machines upgraded to Windows 7 fine. That fourth one, though ... I meticulously documented all the steps I took to troubleshoot it, so maybe my failure will be helpful to someone else in time.

We answered the following listener questions on this podcast:

Adam: "The Fog Creek way of hiring programmers has been well documented. What about hiring tester...

In this episode of the podcast, Joel and Jeff discuss the Mythical Man Month problem, keeping communication in check, Windows 7, and web scaling.

Joel is fielding his largest team ever at Fog Creek -- 9 programmers, 2 testers, and 2 program managers. They only have 10 usable weeks in the summer to build a product with their interns, so they have to parallelize their development.

Contrary to popular myth, it is possible for a large team to be effective, if you mitigate the Mythical Man Month problem, which is really only about adding people to a late project and bringing them up to speed.

How do you deal with an excess of communication (the explosion of paths) on larger teams? First, with program managers. That's what they are there to address, by becoming the conduit for communication. Second, constantly try to reduce the number of meetings and people in meetings.

Speaking of communication excess, is email = efail? This is also why I believe in maximizing the value of your keystrokes, and the value of public communication. If you must email someone, keep it extremely short, a paragraph at most, with a direct question and call to action that is obvious and clear.

One thought experiment: what would happen if all your email became Twitter messages? Or, as Joel proposes, is online communication itself a failed paradigm? At the very least, know the limitations of the communication medium you're using, and escalate as necessary.

Some classes of plugins that can complement a product without competing with it: plugins that make the UI complex or dangerous, plugins that require a subscription fee, plugins that compete with the core business model of the product, and plugins that connect to a different commercial product.

Products that have a vibrant plugin ecosystem and API are almost by definition successful products. It also creates a sort of weird ambient lock-in around the ecosystem, as in Lotus 1-2-3 macros, or Firefox users who won't switch browsers due to their favorite plugins.

A brief discussion of Windows 7, which has much more "curb appeal" than Vista. Joel was not a fan of Vista; I was. And Windows 7 is the best Vista service pack ever.

Stack Overflow almost reached a million pageviews per day last week, and we're consistently doing around 120 requests/sec, or 7200 requests/minute. We're starting to hit peaks of about 80% CPU usage on our single web server, so we may have to add a second webserver to the SO farm soon.

Speaking of sticky sessions, we were surprised to find that there are those rare few users whose IP addresses will change radically from request to request.

We are a Microsoft stack so we're looking at Velocity to share state across multiple webservers. It's a clone of memcached.

Scaling problems are easy to solve. Just throw money at them, like 37signals recently did. The "getting people to give a crap about your application" problem does not respond to money in the same way.

We run a number of LogParser queries on our webserver logs to identify statistically anomalous things that are happening on our website -- what sorts of queries do you run on your web logs to show unusual activity? One of the weirder spiders that's hitting us a lot is Omgili, a sort of forum search tool.

Our favorite question this week is from Server Fault:

Recommended LogParser queries for IIS monitoring? This is an example of putting the sort of information out into the world that we'd like to see exist -- as well as documenting and sharing our own experience in hosting what is now a fairly large public website.

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 [email protected]. 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 pub...

In this episode of the Stack Overflow podcast, Joel and Jeff discuss software updates, the power of APIs and plugins, and leading by example.

A brief discussion of how software should be updated, using Firefox and Apple's Software Updater as examples. In a perfect world, you wouldn't need to care about software updates because you'd always be on the latest version. A smart and silent update mechanism should be architected into your app from day one.

Web apps largely get a pass on the "latest version" problem, but even here, you could update smart by having multiple web servers behind a load balancer, and rotating some servers out of service to update, then back in with the latest version.

Speaking of software updates, Fog Bugz 7 has shipped. It's the first new version in two years, with a brand new, extensive plugin API.

Joel wonders if having a robust plugin model can replace the need to constantly ship new major versions of your software with new features. I question whether Fog Creek got their plugin API right the first time, but if done right, this is totally plausible.

I view plugins as free product design and highly valuable product feedback -- so you should fold the top 5 plugins / add-ons into your product every year or so. But how do you do this without crushing your partners in the ecosystem? There are plenty of examples of popular iPhone paid apps being obsoleted by, say, iPhone OS 3.0. Joel argues that plugins should go vertical, and stay out of the path of that oncoming steamroller.

Now that we have four sites in the er.. trilogy.. it is finally possible to associate your accounts between the sites, and migrate questions fairly painlessly from site to site.

Sometimes we belatedly realize that we got something wrong. We're now thinking that our current +10 upvote, -2 downvote formula nerfs downvotes into oblivion, and lets certain classes of users who tend to ask a lot of low-quality "do my work for me" questions gain a substantial amount of reputation over time. We are pondering making an adjustment here, which is under discussion at meta.stackoverflow.com.

Maybe we should be weighting question votes differently, since users who continue to repeatedly ask dozens of low quality questions are still an ongoing concern. As we get more and more questions in the system, the voting system needs to help us discriminate good questions from poor ones, so we want to encourage question votes.

There is now officially a full time Fog Creek developer working on Stack Exchange -- welcome Aaron Maenpaa to the team! On a related note, one advantage of open source tooling is that you don't have to have painful discussions about licensing expenses and whether the tool is worth using as your team grows.

R language enthusiasts are taking a clever and effective approach to get more R content on Stack Overflow -- we think this is a great way to build a community that is completely in tune with the spirit of the site.

In the post Leading by Example, I proposed that one of the best ways (maybe the only way?) to lead junior programmers is to do the things you wish they'd do, and let them observe your success. Those that can be led, will follow to some degree, and the rest are a lost cause.

Let's broaden the terms. Forget programmers, how do you get pizza guys or car wash guys to get excited about what they do? Joel says you can't. I say there has to be some kind of hippie commune shared ownership business arrangement. At the very least, you can become interested in efficiency, since that might mean you could leave earlier, make more money, or work less.

We answered the following listener questions on this podcast:

J.D. Long: "The R language is attempting to move away from isolated mailing list and adopt Stack Overflow as a resource. What's a good way to do this?"

Sergei: "I am a programmer in a small IT company. I often see my junior teammates program things that are not optimal. I try t...