The Stack Overflow Podcast

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 [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 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 [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 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 [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 sysadmin extraordinaire Tom Limoncelli of Everything Sysadmin to discuss IPV6, dumb things for System Administrators to check, and the sysadmin community as reflected in Server Fault.

Tom has written some classic sysadmin books such as Time Management for System Administrators, The Practice of System and Network Administration.

A brief discussion of the April Fool's RFCs, which go back every year to 1989 per wikipedia. There are even some outliers in the seventies, starting with ARPAWOCKY. These aren't just humor, but artifacts of computing history.

Tom shares his thoughts on the IPV6 transition -- where we are, how much progress we've made, and some of the practical rationales for going to IPV6. What problem does IPV6 solve for us today?

I've often wondered: is the last address space transition we'll see in our lifetime the one from 32-bit to 64-bit? Are 128-bit address spaces necessary for system memory? I press Tom on this topic. He notes that the IPV6 committee was originally going to pick a 64-bit address space, but doubled it to 128-bit.

We examine Tom's hilarious and excellent list of dumb things to check. I guarantee that parts of this list will seem eerily familiar to you.

We attempt to enlist Tom's help in measuring the boundaries of Server Fault. This is challenging, because the sysadmin world encompasses security, networking, databases, websites, hardware, and general operations and support.

We had great difficulty pinning down the sysadmin community, in contrast with the programming community. Tom is as close as we've ever come to the "Joel Spolsky" of the sysadmin world. Tom points out that there is some natural overlap between programmers and system administrators, mostly in the area of release management. Beyond that, there are groups like LOPSA, NPANET, and SAGE.

Tom notes that if you have a small site that can be served by one box, any stack will do. If you have a medium site that needs hundreds of requests per second, go with what your team knows best. But beyond that, once you get the hundreds of thousands of queries per second, everyone builds a custom solution. You do want to think seriously about optimizing for the decreasing price of commodity hardware, however.

Somehow I hadn't seen the classic sysadmin comedy routine The Website is Down yet until Tom mentioned it. There's a series of videos at the eponymously named website.

If you fancy yourself a Google-scale computing endeavor, or if you are simply interested in the ultimate sysadmin fantasy, definitely read Google's Guide to Warehouse-Scale Computing.

We answered the following listener question:

Thomas Arnold: "How feasible is it to host a new web application using the Microsoft stack, considering scalability, performance, and cost versus the open source alternatives."

Our favorite questions this week -- from Server Fault naturally!

Sysadmin Professional Groups and Associations. An excellent resource.

The Data Center tag is awfully good reading for anyone who has a server room.

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 Kathy Sierra and Bert Bates backstage at the Business of Software 2009 conference.

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 meaning of "professionalism" online, the divide between ad-subsidized and pay business models, and the five things everyone should hate about their favorite programming language.

A brief mini post-mortem of DevDays. What makes a good conference? What makes a worthwhile event for software developers?

Speaking of conferences, Joel and I will both be at the Business of Software conference next week in San Francisco.

A discussion of Robert Scoble's article on the chat room / forum problem. Some of this stuff is counter-intuitive: you don't actually want to be too welcoming to newbies, and you don't actually want too much pure discussion. As Robert said, "the more conversations I got involved in the less I found I was learning."

I object a little bit to people proposing social design patterns to me that are historically demonstrated not to work -- or, worse, are known to be toxic. Essentially, they offer opinions without any research or even knowledge of prior research in the field.

We examine Joel's latest Inc article, Does Slow Growth Equal Slow Death?. 37 Signals responded in their blog.

Joel and I both tried to explain our careers strategy. I think Joel's post on careers.stackoverflow.com was clearer than my post on careers.stackoverflow.com, in that I had to post an update to mine because I failed to explain it adequately -- at least based on the reader comments.

To the extent that careers is focusing people on "how can I be more professional online?" we heartily encourage this side-effect. Why wouldn't you behave professionally online all the time, anyway? It is possible to have fun while being professional at the same time.

We posted the results of our Amazon advertising experiment. It looks like software developers are a worst-case scenario for some types of advertising. Unfortunately.

You can use free to undermine your competitors, but Google is going them one better -- they are paying companies to use their products. It's "less than free". Google's strategy is to get as many people online as possible, since more people online equals more ad clicks, statistically speaking.

There's an interesting tension between the "charge for stuff" (Microsoft) and "give people ad-subsidized stuff for free" (Google) models. Having been on both sides of this now, there are definite pros and cons to both.

Joel and I concur: it probably doesn't matter what language and toolchain you use, as long as it has a certain level of critical mass. What you should be more concerned about is the product you're creating.

If you're happy with your current tool chain, then there's no reason you need to switch. However, if you can't list five things you hate about your favorite programming language, then I argue you don't know it well enough yet to judge. It's good to be aware of the alternatives, and have a healthy critical eye for whatever it is you're using.

Most programming languages don't evolve particularly well over time. They're usually replaced by other languages rather than new iterations of themselves. Why? What languages would you point to as the best example of growing and evolving in useful, relevant ways?

We answered the following listener questions on this podcast:

Edward: "What fun technologies are coming up that you think employers are willing to spend money on?"

Colin: "If I'm happy with PHP, why would I want to convert to ASP.NET?"

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 Jon Skeet, software engineer at Google London, and the first Stack Overflow user to achieve 100,000 reputation.

A brief audio snippet of Jon's presentation at London DevDays, featuring Tony the Pony and his sidekick.

A discussion of the Google London offices, which aren't quite up to Joel's high standards, but are quite fun in their own right. And, they do offer free unlimited Curly Wurlies! The London office mostly does mobile development, which in Google world is Android.

Joel explains his analogy of software development as a biology-based process, instead of a physics-based process.

In Coders at Work, Peter Norvig -- chief research guy at Google -- explains that his definition of correctness in software now mostly involves statistics intervals, not absolute boolean "this is right", "this is wrong" tests.

A brief discussion of Joel's painful 14 line AppleScript odyssey.

There is a wall -- literally -- of hundreds of mobile phones at Google London that they use to test against. We wonder how Google's Android will avoid devolving into the same miasma of dozens or hundreds of different versions of hardware, all of which behave differently and require special software support or workarounds.

Is Apple becoming to mobile apps what Microsoft was, and is, to desktop PC apps? Will success in future mobile devices _require _an iPhone emulation layer? Although Apple unquestionably deserves their success with the iPhone, Joel and I are deeply concerned that too much Apple dominance in this area is bad for developers, as Apple serves developers poorly.

Jon spends a lot of time dealing with date and time issues, and shares one particularly horrifying timezone example. Apparently, time is often ambiguous and subject to change by human processes that aren't ... entirely rational.

It is OK to have "fun" questions on Stack Overflow, but a) only occasionally, as we can't have the system overrun by pure entertainment and b) the question must be legitimately programming related and accepted by the community. As with so many things in life, moderation is key.

If you're Jon Skeet, you can post your schedule on meta and it will get 40+ upvotes. Mind you, there is no technical answer there, it's just Jon's schedule.

The daily reputation cap is partly there to encourage programmers to take a break. The goal isn't to be on Stack Overflow, but to generally do things that make you a better programmer. While that certainly includes the fractional time slices of questions and answers that programmers so generously contribute, it also means doing your job, and writing code! To the extent that Stack Overflow itself becomes the goal, we are failing you.

Our listener question this week is from ... Jon Skeet!

Why is the reputation cap (currently 200 points per day) time based? Would other forms of capping reputation work better or be more preferable?

Our favorite Stack Overflow question this week is:

What is the best Battleship AI? A good example of a fun, but appropriate, question for Stack Overflow.

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.