The Stack Overflow Podcast

Jeff & Joel are joined by Steve Karantza, better know as Shirlock Homes, our #1 user on the DIY Stack Exchange.  Steve is also our first non-programmer oriented guest on the podcast!

Everyone wanted to know how Steve ended up on the site: turns out his son is a computer programmer who has used Stack Overflow for a while and encouraged his dad to check it out.

Steve is also a big user of This Old House Pro, a community for contractors hosted by This Old House.  The main difference is that he gets answers on This Old House but gives answers on DIY.SE.  Steve would also like to see some more contractors join DIY.SE

The number one problem he sees is people getting in over their heads.  Especially in regards to electrical and plumbing projects, people don't know or understand the codes and safety issues.

How do you know if a contractor is going to be competent and good?  Best advice is to get referrals.  And once you have them, make sure they are real, go out and actually see how the jobs came out.

If you haven't seen There, I Fixed It, go check it out for great examples of what not to do.  Especially, never, ever use a screwdriver as a fuse.

One great question that Steve answered was how to estimate the height of a tree: he recommended an old logger method.

If at any point during a project you stop and think; how the heck do I do this?  It's time to stop and get advice, either from a contractor or other reliable source.  Steve relays the story of a friend who had a fixer-upper and continually called him for advice after getting stuck on a problem for 5 hours.

Ever needed to do plumbing work but don't know how to sweat pipes?  Check out Shark Bites which form secure couplings without sweating.  Unfortunately - they aren't cheap.

If you want to learn how to do home improvement work: just pick a project and start it.  Some contractors will also let you help out on projects on your house instead of one of their lowest level guys (but not all contractors will let you).

Steve tried to build his first house at the early age of 22 right after he left the air force - as with all early projects, there were a LOT of lessons learned.

Jeff also related how learning building is similar to learning code: ultimately one of the best methods is to simply sit down (or stand up) with someone better than you and work on a project with them

One challenge for Steve has been learning all of the intricacies of the software and systems that make up the sites (like the difference between the main and meta sites), since he's not a computer guy.  He'd also like to see some more highly experienced people come into the site.

The writing that Steve has done on the site has also spurred his desire to keep writing and based on it, he's even talked to some of the local papers about doing an "Ask the Contractor" column.

Steve also noticed how long people continue to read and vote on his answers over time.  Joel pointed out this question on sliding glass doors that still continues to get lots of views even though only 3 people originally answered the question.

Steve is excited about the Gardening and Landscaping site (which is currently in public beta) - if you haven't checked it out, you should!

Steve's son Alex is also launching a new website - Axiom Home Services - to help homeowners with their home inspection questions and needs.

Coming up soon, we'll have a weekly newsletter which will recap interesting and popular questions from the week.

We just officially announced the launch of DevDays 2011 tickets (yeah, yeah we've talked about it before, but now its official).  As always, you can get your tickets with a $100 discount by using the code "blog"

Join us next Tuesday for a special surprise guest!  Not to mention, audio mixing provided by our very own Jason Punyon.

Stack Exchange Podcast - Episode #09 w/ Greg Wilson by The Stack Overflow Podcast

This week, Jeff and Joel are joined by Greg Wilson, an author, developer, and former university professor, who is also an expert on open source software development.  Once make it through the jokes and get his mic sounding great, we can jump in and explore all kinds of interesting topics, like:

Everyone's favorite Canadian airline? Porter Airlines!  What makes them so great?  They use FogBugz as their customer service software.

We've hired a math intern to help us mine through all of our Stack Exchange data and (hopefully) improve the site.   And to make it better, he's an MIT student and Math.SE moderator.

According to a study of Microsoft data, what was the strongest predictor of bug rates in Windows Vista?  The answer: how far apart the developers are in the org charts. The more separate they are, the more likely there are to be conflicting orders or different mind sets.

There have been fairly strong opinions for years on what makes a good programming setup/environment, but people are just now beginning to look at actual data to derive conclusions

Greg thinks this is LONG overdue, especially given that software development is an engineering backed profession - why weren't our processes based on science?

Even big companies, who have access to the data, have been avoiding actually using data for their decision making: people treat it as a craft rather than an engineering discipline

Greg has written several books on how to develop software better - two of which came out this year and are must reads.

Making Software: Joel requires that you read this book, because its the first one to take a scientific approach to making software as opposed to the subjective and anecdotal way that most have in the past (eg: everyone who has done one software project and then written a post on HN about how their method is "amazing").

Greg wanted to use the results of his studies to bring actual concrete steps back to professionals on how they could improve their process

His favorite chapter: while Test Driven Development is very popular right now, a survey of all of the studies that have been done on TDD have shown that the better the study done, the weaker the signal as to its benefit.

Another study recently looked at how much effort goes into maintaining the build system: 5 to 30% of all development effort is spent on maintaining the build system.  With the variations being huge even when working on similar projects.  Clearly, there's a huge difference in the efficiency of some developers.

Measuring programmer "productivity": As Joel points out, any metric that you come up with as a method for measuring programmer productivity can be gamed some how.  He even made money as a consultant in the past showing companies why they shouldn't hire consulting companies to improve "productivity" since programmers would instantly game any system (which is how consulting companies appeared to be successful).  Ultimately, it's pretty hard to actually measure.

Greg points out that the irony is that the single most correlated measure of productivity is simply lines of code written.  Joel counters with that only holds true, so long as the developers don't know they are being measured based on that (since its so easy to game).

His second book is The Architecture of Open Source Applications: its entirely CC licensed so you can read it online for free.  if you do buy a hard copy though, all the proceeds go to Amnesty International.

Greg decided to publish it for free online after seeing how quickly Beautiful Code was put onto torrent sites.

His key thesis behind it is that we don't teach people how to read code (only how to write it).  His example: you wouldn't hire an architect who had never looked at other designs before.

What's really important isn't the internals of the code, but rather the architecture - especially when it comes to understand what you're trying to achieve.

The best parts...

Stack Exchange Podcast - Episode #08 w/ Marco Arment by The Stack Overflow Podcast

This week, Jeff and Joel are joined live "in studio" by Marco Arment, creator of Instapaper and formerly the lead developer at Tumblr.  This week's topics include:

What’s the proper numbering format for podcast episodes: decimal, binary, octal?  There’s also an extensive debate regarding whether Marco has ever been on the podcast: everyone but Joel agrees that he hasn’t.

Marco talks about leaving Tumblr to start his own company (Instapaper)

Part of what made the move easier was that he did it on the side for about a year before leaving Tumblr (with the okay of his current boss of course).

By the time he left, Instapaper had become a full time job and Tumblr had become far more than a full-time job – it needed even more time and support.  It became very stressful knowing that even the slightest mistakes in code could cause 1100 people per second to get error messages

Instapaper is also a bit easier to support because it’s inherently designed for offline use, so if the servers go down, people aren’t immediately deprived of the entire functionality like they are if your web service is down.

Instapaper was created by Marco to solve the problem of reading on the train and reading old articles that he had found while at work.

Marco is currently being confronted by the “big player” problem (aka The Starbucks Problem), now that Apple has introduced their “Reading List” feature in the newest version of iOS and Mac OSX.

As Marco points out though, there’s several big reasons that he isn’t really hurt by it: 1) It doesn’t solve the offline problem – it’s only online bookmarks  and (2) It doesn’t clean the text to make it easier to read

Most importantly, it doesn’t solve everyone’s needs and at the same time, it educates the market as to the value of this type of service, thereby enlarging the entire market and creating more customers for Instapaper.

This tends to work really well for the small player when you’re trying to solve a big problem with lots of personal preferences – it doesn’t work well when its one simple task that needs to be completed.

Examples of situations that are good for the little guy: RSS Readers, email clients, coffee shops, etc.  Examples of situations that are bad for the little guy: .ZIP files, regular bookmarks, etc

There’s also tons of successful notes and stock apps, despite Apple providing support for it natively.  So many people want more functionality that it creates a whole new market.

Ultimately, if someone wants a bit more than what Apple provides by default, they are probably going to go to Instapaper and ultimately increase Marco’s user base..  The key to this model: you have to do it better than the big guy

People sometimes also choose random or arbitrary reasons for choosing products (like the color or logo or name)

Jeff finds that the effort of queuing things up (especially reading material) is greater than the benefit he gets from being able to read things later.

Marco points out that he doesn’t want Instapaper to be seen as an obligation – something that many people ultimately feel it can be

To combat this, he is considering a feature where he would email them saying “I noticed that you have X articles more than Y months old, do you want to archive them”, thereby giving them an ‘out’.

People don’t find to tend the app while searching for offline reading – they just find that as an additional benefit after they start using it.

Joel thinks that Facebook created the “Like” button in order to collect data about web pages that would be very good for creating a search engine

Marco also points out that Facebook provides all of these various embed platforms so that they get the cookie on your computer and then can see anytime you visit any of these pages and build a graph of what you (and everyone else) looks at.

Bringing it back to Stack Exchange: Jeff points out that w...

Stack Exchange Podcast - Episode #07 w/ Sam Saffron by The Stack Overflow Podcast

Jeff and Joel are joined by Sam Saffron (aka Waffles), our only Australian developer at Stack Exchange!

Does "Hell Banning" -- making a problematic user's posts visible to just him or her -- make sense? You can see Jeff's post about it over on Coding Horror. When issues like this are presented to the community, the gravity of the situation is often not fully conveyed to the audience. They can't see all the removed content that tells the story of how destructive that person was to the community. Of course, we always encourage discussion of general moderation issues on the per-site metas.

Two pieces of advice about moderation discussions: try to stick to generalized discussions about a broad class of moderation, without delving into minutiae specific to one user and one situation. To keep it useful to the community, avoid devolving into a laundry list of every tiny thing that happened to every user. Also, try to limit discussion about moderation to those users who have an actual connection to the site and these moderation events, and aren't just stopping by to opine about some abstract, perceived wrong on the internet. (insert XKCD cartoon here)

Sam Saffron has been working remotely for Stack Exchange from Australia for about a year now. Sam came to our attention as an avid participant on Stack Overflow and meta, as well as his own homegrown Stack Overflow inspired support tool he wrote, Community Tracker. In addition to being the lead on the Stack Exchange Data Explorer, Sam's touched almost every area of the engine at this point: improvements to badges, privileges, edits, users page, tags page …

We're starting to build a feature we call emacs.stackexchange.com, which essentially gives users a filtered view of Stack Overflow to specific topic groups, as represented by a set of tags. We have historically shut down Area 51 proposals that would factionalize Stack Overflow, and although we feel this is the correct decision, we are sympathetic to the underlying concern. Stack Exchange sites are intended to be groups of topics, identified by tags, that are of broad interest to people who all love a topic -- like, say, programming. This is fine when you follow a large tag like [java] or [c#], but what about when you follow 20 small tags? Yes, you can set up a tag filter, but it might be nice to have some default groupings for certain popular sub-areas -- thus, emacs.stackexchange.com instead of the Area 51 site proposal for emacs.

The bedrock guideline of our Area 51 site creation process is, "I'd like to ask a question about {x} but there's no place on the Stack Exchange network to do so". We've been a bit disappointed that the CSTheory community has been unwilling to accept an expansion of their scope, because there are technical computer science questions on Stack Overflow that aren't being handled correctly and have no other place to go.

The German and Japanese proposals are now public! These are our first baby steps into other languages, as guided by the community. It's already caused a bit of an issue as we "advertise" popular questions to the network that may have very few words in English. This also comes up with http://judaism.stackexchange.com/ questions which can have quite a bit of Hebrew in them.

As Joel builds out the CHAOS (NYC community development and evangelism) team out, they start with a generalized online SAT/ACT style aptitude test.

Which Jeff did not pass. :) But the far more interesting test that we're giving candidates is what we call the "Internet competency test" -- how would you test someone to see if they are experts at using the internet? How to find things, how to send email, how to link, what "The Facebooks" and "The Twitters" are, and so forth? Building such a test is an interesting thought exercise. How would you do it?

A question from the chat room -- are there any metrics around how much the new suggested edits feature has improved the site? One thing we've l...

Stack Exchange Podcast - Episode #06 by The Stack Overflow Podcast

It's our first test of a live podcast!  In case you missed it, we streamed this week's podcast live during the taping. It's something we're playing with and may continue to do in the future if it is popular.  You can tune in to the live tapings Tuesdays @ 4 PM Eastern / 1 PM Pacific -- check Joel and Jeff's Twitter feeds for the location.

We've found that hosting a podcast while running a business is more useful than you might think -- because it allows you to introspect on your own thoughts and decisions and have a history explaining why you made those bad decisions at the time. Even if you only have 10 listeners, and one of them is your dad.

Jeff is currently reading Super Cooperators which focuses on the prisoner's dilemma and how it applies to social situations. In the real world, people remember your actions, and that history changes how they interact with you. Ultimately our concept of reputation derives from the realization that your current actions will have future consequences not just on other people, but on society and the greater internet.

Some of the NY team went to hear Bing Gordon give a talk on gamification that covered a number of topics.  In particular, he noted that almost everyone (except for males age 18-24) prefer a cooperative game to a competitive one, and people are much more likely to continue with something if at least one other person sees and validates what they did. That's one reason why we're so gung-ho about everything being public -- by keeping everything visible and in the open, you encourage more civic-minded level of behavior than what happens behind closed doors. Sometimes people can be turned off by these types of reputation systems, though.

There's a fantastic article at TheAwl about how Wikipedia made it possible for amateurs who are obsessive about a topic to become, en masse, as reliable as traditional experts.

Stack Exchange is now an OpenID provider!  We did this primarily for two reasons. First, any time you send people off to another site to sign up, you lose visitors. By keeping everything on Stack Exchange, we increase the success rate of sign ups. Second, while MyOpenID is a great service, it's free -- so there's no incentive for JanRain to maintain it and keep it in good repair. There have been some recent ... incidents ... with MyOpenID.

Down votes no longer cost you, the down-voter, any reputation points on questions only.  We found that too many people weren't willing to down vote questions because of the -1 cost to the voter. Downvotes on questions are a critically important signal for us in separating the good questions from the not-so-good questions.

Upcoming guests include Steve Karantza (Shirlock Homes from DIY.SE), Rory Blyth, Dave Winer, Jason Calacanis, and more.  If you have guest suggestions, make sure to add them to the Meta thread!

We're hiring a Community Evangelism Team!  They'll be responsible for promoting our communities and sites out to new audiences, and helping them grow. It's a great job for anyone who wants to get into the startup world or a recent grad with a humanities degree who doesn't want to be stuck working at an agency for the next 10 years.  For more details, check out the job post.

Joel takes his first question from the audience: why does he think great programmers aren't going to be found developing internal company apps?

Tune in next week when our guest is Sam Saffron (aka Waffles) - once again, you'll be able to watch/listen live on Tuesday @ 4pm as we do the taping.  Follow @spolsky and @codinghorror for the link.  You can also hang out in the official chat room during the tapings.

Stack Exchange Podcast - Episode #05 w/ Josh Heyer by The Stack Overflow Podcast