ALTERNATE UNIVERSE DEV

The Stack Overflow Podcast

Podcast #52

This is the 52nd episode of the StackOverflow podcast -- our one year anniversary -- where Joel and Jeff discuss the launch of Server Fault, how you determine if your code is smelly (or just aromatic), how programmers learn by doing, and how good ideas are often too crazy to copy until it's too late.

  • We've been podcasting for one full year now. Hopefully we've gotten better at this podcast stuff and not worse, but the jury is still out.

  • Server Fault, the first sister site to Stack Overflow, is now in private beta. Server Fault is for system administrators and IT professionals. If that's you, come join us!

  • We've only done one major branch in Stack Overflow to date, and it was excruciatingly painful in Subversion, even after updating to 1.6 which has "better" support for merging. We're considering switching to Mercurial to make future merges feel a bit less like gnawing our own limbs off.

  • Joel announces that Fog Creek is working on a hosted version of Stack Overflow, and they are looking to hire a software engineer to work on the project. If it works out, you get the whole Fog Creek relocation package! If you've ever wanted to work on the Stack Overflow codebase (and you're looking for a full time gig) this is your chance!

  • The prospect of an outside developer looking at our Stack Overflow code base makes us nervous. Maybe this is a healthy reaction -- is any code ever good enough? Probably not.

  • We do believe in continuous refactoring, and part of that is developing free from fear. Don't be afraid to break stuff! Have some unit tests, and when things do break, be able to fix it very rapidly.

  • Test Driven Development is possibly the worst and most incorrect name ever applied to a concept in software engineering, ever. And that's saying a lot. TDD is more about design than testing, but when every TDD tutorial starts with "ok, we write a test to verify.." it's sort of hard to justify. Perhaps Behavior Driven Development would be a better name.

  • TDD, as far as testing is concerned may be a bit too programmatic. Never underestimate the power of a skilled human tester.

  • We learned ASP.NET MVC as we went. This is a surprisingly common pattern; Joel can't ever remember a time when he wasn't building a new application in a new framework. Programming is, almost by definition, continuously learning: your entire career will be one long, unbroken string of learning one new bit of technology after another. Programming is shorthand for learning how to learn.

  • Joel asks: as a professional programmer, how often do you start a new major project that's going to have a long life expectancy? It's startlingly rare. Even at Fog Creek they've had maybe four in the entire time the company has existed. So when you start a new project, you almost have to bet on the new framework that you think will be vibrant and alive five years from now -- that means you'll be learning as you go, again! There is a double whammy of learning the framework and a language at the same time though -- that's extra-risky.

  • A brief discussion of why unconfirmed "no-touch" user actions are so dangerous on the web; they are a XSRF playground! If the user holds a cookie to your site, and an attacker can get them to click on a GET or POST, they have just forced the user to take that action. We added an interstitial confirmation to a few actions to prevent this; the particular case that was extremely dangerous was associating a new OpenID provider in one click. If that OpenID provider was rogue and controlled by the attacker, they now own the account.

  • Joel notes that if you're shy about putting things online, you are letting other people control your online identity -- and that will hurt you much more in the long run than any potentially questionable things you might possibly put online.

  • One of the goals of creating Stack Overflow was as a vehicle to build your online identity as a professional programmer, a virtual set of bread crumbs showing that you indeed know your stuff, and your programming peers recognize you for your knowledge.

  • Joel gave a speech about Stack Overflow at Google recently. What question did Guido van Rossum, the creator of Python, ask?

  • A brief mention of stackoverflowoverflow ... overflow.

  • By the time anyone tries to copy an iPod, Apple is already a generation ahead. Continual innovation and evolution is always the best approach to defeat those who would blindly copy what you're doing, and that goes double for software which is infinitely malleable. If your software isn't continually evolving, it is effectively dead!

  • Good ideas sound too crazy for anyone to even consider copying them. The type of people who copy are not interested in anything that remotely resembles risk; they are only going to copy proven successes. So if you're starting out with a new crazy idea (and you should be!), this is unlikely to be a practical concern.

  • Joel's computer has apparently been taken over by a Mexican wrestler named Gordo. I have no idea.

We answered the following listener questions on this podcast:

  1. Paul: "I've seen some companies do background checks online with MySpace, Facebook, Twitter, etcetera. Should developers be concerned about old, embarrassing code being posted online?"

  2. Tom: "As a startup entrepreneur, what steps should you take, if any, to protect your intellectual property?"

Our favorite Stack Overflow questions this week are:

None! Every single Server Fault question I've asked is my favorite this week! I've had all these sysadmin and IT pro questions welling up inside me for months, and it was so intensely satisfying to finally be able to ask them and get really great answers. Please join us in the beta!

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.

Episode source