Podcast #31

This is the thirty-first episode of the StackOverflow podcast, where Joel and Jeff discuss.. stuff!

• Based on some comments from Podcast #30, we now know that "Learning about NP-Completeness from Jeff is like learning about irony from Alanis Morissette". It's funny because it's true!

• It was also noted that "[Jeff] certainly no mathematician." In my defense, I've always been very open about my lack of math skills. It's even item #3 in my Five Things We Didn't Know About You list.

• I noticed that someone posted the halting problem to GetACoder.com, so if nothing else good came of this, at least humor was delivered.

• How useful is math to most programmers? In other words, how often does a typical software developer use something they learned in, say, Calculus class or beyond? Joel cites the original Google PageRank algorithm paper (pdf) and Google's MapReduce (pdf) as good examples of math in practice for mainstream programming.

• I believe it's important for programmers to develop skills that aren't programming, necessarily, but that are complementary to programming, such as graphic design. (Or databases, or HTML/CSS, etcetera) Remember, good programmers write code; great programmers steal code. This applies triply to design.

• Joel and I both believe that status reports should be treated as a "public wall", never as weapons to determine how people get paid or promoted. The single best thing I've ever read on this is Poppendieck's Team Compensation (pdf) -- which I discovered through Joel's first collection of software writing. If I could, I'd print out a copy of this and staple it to the face of every person in the world who manages software developers. Yes, it really is that good. Go read it!

• One team at Fog Creek instituted a daily standup meeting for their project, which is a staple of most agile development approaches. In addition to the "Daily Kiwi" convention, Fog Creek also use a locally hosted instance of Laconica, an open source Twitter clone. It's certainly an interesting alternative to email.

• Joel believes most small to midsize software companies will deal with an economic downturn by (temporarily) deferring development of new versions of their products. For companies that have a lot of "extra" staff, the economy might be an excuse to get rid of the worst performing 10% of your employees.

• Joel justifies having a nice office space as 1) a recruiting tool 2) enabling higher programmer productivity and 3) the cost of a nice office space is a tiny number relative to all your other expenses running a company. I argue that companies which don't intuitively understand why nice office space is important to their employees who spend 8+ hours every day there.. well, those companies aren't smart enough to survive anyway.

• My favorite Stack Overflow question this week is Are Parameters really enough to prevent Sql injections? Joel and I have a long discussion about the importance of parameterized SQL, both for performance and for security (beware Little Bobby Tables!). But you should know that it's not 100% foolproof; it is possible (though rare) to have latent SQL injection exploits even when fully parameterized.

• Joel's favorite Stack Overflow question this week is How do you pull yourself out of a programming 'slump'? Joel knows tons of programmers who have burned out by age 50, and feels it is rare to find programmers who have written code for 20 to 30 years. Joel's article Fire and Motion and my article Moving The Block sort of cover this topic. Joel also recommends the book Death March as a reference book for what to avoid.

We answered the following listener questions in this episode:

• Mike Akers: "How much time should programmers be spending in Photoshop?"

• David from the UK: "How do you handle status reports at Fog Creek?"

• Matthew Glidden: "How do you run a software company in lean economic times?"

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