Stack Overflow Podcast: Stack Overflow: Podcast #42

Stack Overflow Podcast

This is the 42nd episode of the StackOverflow podcast, where Joel and Jeff discuss ethical email, backup strategies, how to learn new programming languages, and dealing with underperforming developers. The Conversations Network, a non-profit organization that graciously underwrites the bandwidth...

Running time
1h10m
File size
32.00MB

Download Original File | View original post

Episode synopsis

This is the 42nd episode of the StackOverflow podcast, where Joel and Jeff discuss ethical email, backup strategies, how to learn new programming languages, and dealing with underperforming developers.

  • The Conversations Network, a non-profit organization that graciously underwrites the bandwidth costs of this and many other great podcasts, is looking for a sponsor. Email us at podcast@stackoverflow.com if you know of any
  • We finally rolled out email support at Stack Overflow. If you haven’t been to the site in 7 days, and have provided a valid email address, we include all the responses to your questions and answers (if any) in that period. And of course there is a true one-click unsubscribe. We’re still tweaking the parameters of how it works — what is the optimal email relationship between a user and a website?
  • Sending email these days is a bit of a minefield. How do you avoid instantly going into people’s spam folder? One key piece is having a Reverse PTR record, which is set up at the ISP level. There’s a whole “Deliverability” industry around sending email to people.
  • We’re encouraged by the emerging standard of entering your OpenID provider’s address as your OpenID login. For example, “yahoo.com” works for Yahoo OpenIDs, and eventually “gmail.com” will work for Google. (Today you must use “google.com/accounts/o8/id” for Google, which is not optimal for hopefully.. obvious.. reasons.) Microsoft is also coming on board, though their OpenID support is in private beta.
  • We also implemented gold and silver tag-based badges, based on upvotes within a tag. It’s a way of rewarding people who participate heavily in certain topic areas. We did have to rule out discussion based questions for this algorithm to work. We are also considering a tag leaderboard, as suggested by Greg Hewgill.
  • Our backup strategy has been half-hearted so far. To improve this, we invested in an inexpensive embedded Linux based 1u Network Attached Storage device, the QNAP 409u. This will become our dedicated backup device. It has four drive bays and supports RAID 6 (dual parity). Kind of a neat little device; there’s a whole subculture of inexpensive NAS devices I hadn’t explored until now. Drobo, for example.
  • As it turns out, the cost of bandwidth ends up being the gating factor for us when dealing with our daily multiple - gigabyte database backups. Jim Gray had an eye opening piece on the economics of bandwidth and the surprising effectiveness of “sneakernets”, even today.
  • How likely is it that your datacenter is going to explode? Unless you have a fancy multiple datacenter setup for redundancy, it might be more effective to do some trickle uploads to services like Amazon S3, or even some monthly datacenter driving runs to copy data off using a cheap USB 2.5″ hard drive. Luckily, one of our team members lives a mile from the data center, so that’s the approach we’ll be using.
  • We had some semi-serious issues with our IBM ServeRAID 8k controller, having to do with write-through versus write-back caching. Write-through blocks on actual disk writes, whereas write-back writes to a fast RAM buffer, returns very rapidly, and spools the writes over time (e.g. “lazy writes”). The performance of write-back is dramatically better, but we were seeing some eventual system-wide I/O blocking under heavy write load with write-back caching on. Supposedly this is normal for some RAID controllers, but we opted to downgrade to write-through because the nightly backups would always trigger this behavior for us.
  • Speaking of blocking: it’s funny how many of the techniques discussed on the High Scalability blog boil down to hashtables in memory. Memory is one of the fastest things you have in a computer, and it almost never blocks for any significant amount of time. Unlike, say.. hard disks or network.
  • The act of trying to learn a new language will make you a better developer. Where do you go if you only know PHP? I think you should go to Java or C# to build up a bit more structure, then to Python or Ruby to tear down that structure, as a sort of natural ebb and flow progression journey that I’ve seen a lot of developers make over time. Joel disagrees, and thinks thinks you should go for something radical right out of the gate, like Haskell. “At some point it has to blow your mind, or you’re not learning.”
  • Joel recommends the classic Abelson and Sussman lectures on Structure and Interpretation of Computer Programs. This of course complements the freely available on-line version of the SICP textbook. Go blow your mind! “Once you learn those concepts, you’ll write better code in any language.”
  • Is it an legitimate argument to say that, if you haven’t tried something, you’re not entitled to have an opinion about it? How much does it add to your opinion to have experience in a subject? Joel references Paul Graham’s How to Disagree.
  • Shouldn’t every software project you work on be a learning experience, regardless of whether the software ever sees the light of day? Why would you work on a project that isn’t teaching you anything at all?
  • Is it possible to help programmers who can’t help themselves? We’re not sure throwing a copy of Code Complete at a sub-par developer will necessarily make them any better. I believe pair programing and mentoring is the only way to get this to work, insofar that it ever does. And tread very lightly here, because it’s quite possible to make things worse by being didactic or overbearing.
  • How do you fix not caring? How do you fix lack of motivation? Perhaps the better way to look at this is to keep your project inherently interesting and relevant. Convince your teammates that you’re working on something that matters, at least in some small way. Are we happy with what we’re doing? And if not, how can we fix that?

We answered the following listener questions on this podcast:

  1. “I am a PHP web developer. I want to learn a new language to improve my skills. What language should I learn? It doesn’t have to be useful for web development, although it would probably help.”
  2. Adam from PA: “I work for a R&D group at a large defense contractor, I’ve been told my project is ending. How do I keep my motivation going when I know this project is going to be put on a shelf and not used?”

Our favorite Stack Overflow qustions this week are:

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.

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Debuggers don't remove bugs. They only show them in slow motion.”