The Stack Overflow Podcast

This is the 51st episode of the Stack Overflow podcast, where Joel and Jeff sit down with Joel's business partner, Michael Pryor of Fog Creek Software, at Stack Overflow world HQ (i.e., Jeff's house) in El Cerrito, California.

At my home, Joel discovers my secret clock fetish. I have a pong clock, a nixie clock, and I'd love to have an oscilloscope clock!

Joel and Michael went to the Computer History Museum, one of my favorite places in the world. It's not just big iron; Michael geeked out over his old Apple //gs, and Joel enjoyed revisiting old HP calculators.

Stack Overflow comments are now elevated to the main page. We've gone through several user feedback cycles on this, and we feel the current comment layout is a good balance. The preference for this is still in the works. This was partially inspired by the way comments are displayed on SFGate articles (scroll to the bottom to see how comments are displayed there).

A discussion of the value of meta -- discussing Stack Overflow on Stack Overflow. How much meta is acceptable? Where should meta-discussion go? Isn't the podcast and the blog meta enough? Is there a need for stackoverflowoverflow?

One problem is that the system we've built is good at focused, directed Q&A but quite bad at arbitrary discussion. It's why Joel objected to me proposing the use of the Stack Overflow engine for the Joel on Software discussion boards and the Business of Software discussion boards. Not a good fit!

Consider an analogy with school -- if you don't like the after school activities students are engaging in, it's because you didn't provide a good set of alternatives for them. But perhaps a better analogy is that of students who become teachers; they need a "teacher's lounge" area.

The whole point of Stack Overflow is synthesizing _better _answers than what you can commonly find on the open internet. If the answer is already good and easily findable elsewhere on the internet, leave it there! Don't repost the answer on Stack Overflow unless you're enhancing and improving the answer in some small way.

How is Babby Formed has been removed from Yahoo Answers, and we have removed Programming at Sea.

Part of the philosophy of doing lower-level things yourself, such as building your own computers (or even learning C), is to do it enough to understand it -- and learn something along the way. It doesn't mean that you need to (or even should!) do those things forever, but the journey of learning and discovery is its own reward. The best reference for programmers who want to learn what goes on underneath their code is Charles Petzold's outstanding book, Code.

Learning black hat techniques is important, because when good is dumb, evil will always triumph. Don't be dumb. Know what's out there, and how to exploit it. The morality of studying black hat techniques derives from what you do with that information. Will you sell it? Distribute it and actively attack ? Or quietly disclose it to the vulnerable software or website?

Joel marvels at the enormous size of the Microsoft campus since he worked there; when he was at Microsoft in the early 90's, there were around 5,000 employees and it was not uncommon to see Bill Gates walking around the campus. The Redmond visitor center is a disappointment; it should be more like the Computer History Museum, highlighting Microsoft's central role in so much of that history to date.

Apparently the best estimates are that there are around 9 million programmers in the world, roughly the population of New York City. Imagine a whole city of nothing but programmers. On second thought, that's too scary -- let's not.

A small clarification on last week's Steve Yegge project; Steve is not the author of the Google JavaScript compiler, but a client of it.

We answered the following listener questions on this podcast:

Peter: "What do you think about the practice of finding an answer, and re-posting it...

This is the 50th episode of the StackOverflow podcast, where Joel and Jeff sit down with Steve Yegge of Google and the most excellent Stevey's Blog Rants.

This episode was recorded on site at the Kirkland, Washington Google office, where Joel gave a talk earlier in the day.

A brief discussion about the APL language, whose keywords are symbols. Imagine how challenging it would be to program in a language where you need a special keyboard. There's a more popular (not sure "popular" is the right word) version of APL named J which drops the symbols in favor of plain ASCII.

How big a fan of working at Google is Steve? He worries that new hires from college will expect the rest of their working life to be as good as their Google experience.

Steve can finally talk about what he was working on, which he was so vague about on our previous podcast with him. Mostly, he was disturbed at the state of JavaScript tooling at Google -- "dude, you spelled it fuction again."

The state of the art in tools means painstakingly adding support for each individual language into each individual editor. What if there was a way to plug first-class language intellisense / compilation functionality into any editor -- in a generalized way? That's the problem Steve set out to solve.

Take compilers that are defined for IDEs -- Eclipse has three Java compilers built into it -- a fast inaccurate one as you type, a better batch one, and then a great big one that does exhaustive analysis on large trees (Steve says Eclipse has "a better Java compiler than the Java compiler".) This is all necessary to get good editor support! Why not take these compilers and run them on the google infrastructure, so they are commoditized and available to any editor?

Steve says the way tools and languages integrate today is utterly backwards. Languages should support the tools, rather than the other way around. "We should have been doing this for 20 years!"

Prototype doesn't play well with the JavaScript compiler at Google, partly because nobody has actually tried to compile the code before! It exposes some problems that weren't immediately obvious. All the common JavaScript frameworks require some tweaking for the JavaScript compilation process.

Steve likens the comparison between compilation and dynamic typing to taking a shower and brushing your teeth. You should do both! The only reason we can't do both of these things is because, as Steve points out, our tooling currently sucks.

JavaScript has a more interesting origin than I realized -- it was originally based on Scheme.

Per Steve, Scala is like Haskell but with more concessions to real world programming. He points out that the great thing about Java is the fantastic tooling, which means it's ultimately a better programming experience than a theoretically "superior" programming language.

Joel doesn't hate Unix; FogBugz supports Unix (although that support tends to be complex and costly) and Joel regularly runs cygwin on his laptop. That said, modern Unixes have their faults too. Steve observes that the only way to determine what packages are installed on Ubuntu is to diff the dpackage output against a clean machine. Also, Firefox is very slow on Linux relative to Mac and Windows.

Stack Overflow is for programming related questions, but defining programming related isn't easy. There will always be a gray area, which is further complicated by the fact that we do want the _occasional _fun questions -- we just don't want the system overrun with the stuff.

Steve points out that even Amazon has examples of "fun" product reviews that wouldn't normally be permitted, such as On Amazon, All of a Sudden Everyone's a Milk Critic and The Story About Ping.

We answered the following listener questions on this podcast:

"What is Joel's history with Unix? He mentions Unix a lot in vaguely pejorative ways. Did he have a bad early Unix experience?" No, Steve, the caller did not say "eunuchs"!...

This is the 49th episode of the StackOverflow podcast, where Joel and Jeff sit down with Alex Papadimoulis of The Daily WTF to discuss the distinction between IT/sysadmins and programmers, online justice for webforums, user-friendly IDs for databases, and the future of software distribution.

Some of our favorite Daily WTF entries: Spaced Out and Have You Tried JavaScript? Alex likens their writing process to the Vital Signs column in Discover Magazine.

As we build up serverfault.com , the already grey area of "which question goes where?" becomes even .. greyer. The animal, vegetable, mineral problem is not going away any time soon. That said, if you can attach code to your question, it probably belongs on stackoverflow.com. And if your question involves a server (and no code), it probably belongs on serverfault.com. But there are always exceptions, like this question about working conditions.

I was surprised to find that there seems to be no critical mass of sysadmin/it bloggers online, certainly no equivalent to the legions of high profile programming bloggers. Thus, we'll be initially seeding serverfault.com with those programmers from stackoverflow.com who cross over and also wear the sysadmin/it hat in their work.

What if there was a programming language that used only abstract symbols instead of existing words in a human language? There is! But it's only a research project. (And I found out that Joel wasn't kidding about APL!)

Some clarifications about the localization discussion last week. Joel and I continue to disagree about priorities here, is what it boils down to.

Joel and Michael are fans of the hellban concept, but I find it to be a bit much like the guys in black masks making people disappear overnight. We implemented a penalty box instead. The hellban might be appropriate for random spammers, but for engaged members of a community, it's a terrible system of justice. We also improved our flagging system ala Craigslist so it's easier to communicate with moderators.

The specific source of friction was editing. It turns out that the spirit of an edit is as important as the technical rationale for it. We love and encourage editing, of course, but it's possible to follow the absolute letter of the law and still be toxic to the community. Joel says that the typical programming mindset makes us particularly prone to this behavior.

You have to be able to let things go. One of the curiosities of Wikipedia is that the most obsessed users always win. You can't compete with someone who devotes hours every day to maintaining their pet topic, with scripts to protect it. This system, on some level, must work because if it didn't Wikipedia would be permanently broken.

In addition to software increasingly running in the browser via various mechanisms, we view services like Valve's Steam as the future of software distribution. Ultimately it should be as easy and painless to install software as it is on the closed-ecosystem iPhone and its App Store. The tension between digital distribution and traditional retail channels is still a major hurdle, however.

Alex liked this Stack Overflow question:

Database-wide unique-yet-simple identifiers in SQL Server. Great question having to do with the human readability of IDs for unique database records. Lots of food for thought. Alex recommends unique lengths per record type, or the "Smart Key" approach of encoding dates and other unique things in the id.

We answered the following listener questions on this podcast:

Andy Brice: "What will happen with the market with downloadable software? Everything in the browser? Hybrid between the downloadable executables and stuff running in the browser? Or will it be business as usual?"

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...

This is the 48th episode of the StackOverflow podcast, where Joel and Jeff discuss planning your career, the importance (or not?) of localization, what makes a good moderator, and dealing with programmers who lack interpersonal skills.

Until 2004, I felt sort of like that feather in the movie Forrest Gump, or the plastic bag in American Beauty. I had no real plan for my career. This prompted me to think about what I wanted from my career, and it's why I wrote The Eight Levels of Programmers. Think about who you respect, and why, and whether those paths work for you.

If you're very lucky in your career, perhaps you'll be able to build Bongo's Dream House.

Joel and I have a long (REALLY LONG) discussion about the Chinese Stack Overflow clone, cnprog. It's excellent that we are inspiring other programmers, but we do draw the line at copying our look and feel down to the tiniest detail (including the blog). Don't be a content stealing jerk!

One reason localization has been a very low priority is that we feel for our particular audience, namely programmers, English is the de facto standard language. Not that other languages aren't important, but it's easier to get engineering work done when everything coalesces around a standard language.

It is true that localization is not even close to being on our radar. Programming communities need to form in local languages, too.

We're open to providing a dump of our cc-wiki licensed content, but we don't want to have an AOL data scandal. That would be .. bad. It's the biggest risk blocking that from happening at the moment.

Joel believes that there are five "important" languages that programming content should eventually be localized into: German, Spanish, French, Chinese, and Japanese.

We're beginning the process of promoting a notable user from our community to full-blown moderator status. Shaya Loney, who works at answers.com, had some excellent advice for us -- one of the risks is that when you take one of your best teachers and turn them into the principal of the school, you lose a great teacher. We also want moderators with a variety of different backgrounds for diversity.

We were able to test our datacenter disaster contingency planning a little with a recent server error. Lesson: always have your contingency plans ready to go in practice, not just in theory. We only lost time, but we're considering the use of remote KVMs if this becomes an ongoing concern.

One way to deal with programmers who come off as abrasive and perhaps lack interpersonal skills, is to focus on the specific behaviors that are problematic. Detail the very specific, ultra-narrow things that they could change to improve the way other people react to them.

There's a good reason to fix this, beyond the bad apple theory. As Joel points out, "for marginal performers, the people who don't get along, are probably going to get fired, and the people who everybody likes, are probably going to stay around."

Revisiting the "architect" title. We still think it's a bad idea, but perhaps it's more palatable if you think of it as "software engineer with lots of experience." And get rid of the title! That said, there are the rare few, with Joel's example of Dave Cutler, who truly was the Architect of Windows NT in every possible sense of the word.

We answered the following listener questions on this podcast:

Demitrios from Brazil "What do you do with a solid contributor who on a personal level is very annoying, nobody likes him, and nobody can get along with him?"

Rudy from Denver "Is it possible that Architect is a valid title, for those developers who have the skill to develop large applications?"

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 lea...

This is the 47th episode of the StackOverflow podcast, where Joel and Jeff discuss Eclipse, plugin architectures, sketching mockups, and optimizations that don't optimize.

I had the honor of keynoting EclipseCon this year with Clay Shirky. Eclipse is an open source IDE with an excellent plugin ecosystem. It's also a great Java GUI framework.

A brief discussion of the communal relationship between applications and plugins.

I am cautiously optimistic about the release of Internet Explorer 8. The betas were very scary, but the final released version is surprisingly solid and fast. A totally respectable update from Internet Explorer 7, and it has a very convenient "switch to IE7 rendering mode" (along with a HTML header that does the same thing) that means it's super easy to essentially have both browsers.

Joel explains that he'd rather spend any amount of money than have his developers "take a few weeks" to optimize the FogBugz compiler. Remember, hardware is cheap, and programmers are expensive. This may include buying 8 GB of memory (cheap!) and the super-fast Intel SSD hard drive. It's recommended by Linus! Be careful with SSDs, the only ones worth having at the moment are the very high end models like the Intel one. Cheaper ones can be slower than regular hard drives!

I continue to recommend the two-spindle approach for desktops for optimal performance. It's the same reason, on a database server, you typically have the OS on one drive and the data on another drive. It reduces contention.

We joke about pure architecture software releases, where nothing visible changes in the product, except the underlying code. There are reasons to do this, such as performance, scalability, and simplicity. But for a product users pay for, a pure architecture release would be suicide.

Our live podcast from MIX went great -- thanks to everyone who participated! You can watch our 5-minute bit at about 50 minutes into the day one keynote on the official MIX website.

The classic example of a free site attacking the business model of a pay site is Markus Frind's Plenty of Fish. What's odd is that PoF has been so successful that Markus is looking to acquire a pay dating site at this point. On the other hand, he's adding some pay features to his free site as well.

Joel talks about how smart the design of Balsamiq Mockups is. It actually forces you to stay simple and abstract, which is the whole point of sketching.

Sketching is on our minds because the Bill Buxton book Sketching User Experiences was provided to every MIX attendee, and Bill Buxton was the first day 1 keynote speaker.

Joel complains that so many design books start by talking about the design of the iPod, to the point that it's cliche. Perhaps one design lesson is that people care more about the content than the design -- the websites they load are far more important than what browser widget they load it in, despite how important choice of browser is to us geeks.

One of the points Clay brought to our EclipseCon keynote was that social software ends up being a mirror, a reflection of the community you drop it in to. Unlike PhotoShop, which works exactly the same no matter how many times you copy it or who is using it, the same social software may behave completely differently for different communities. This is why Reddit cloning itself into weheartgossip isn't really working -- the audience is too different.

Make sure your "optimizations" are actually optimizing, otherwise you're pessimizing -- with the best of intentions, you make your code slower. Benchmark first, not last!

There are huge categories of premature optimization you should avoid, but you also want to avoid making big design mistakes early on. It's not necessarily optimization, per se, but don't do things that are so incredibly boneheaded you will regret them forever.

We answered the following listener questions on this podcast:

"What about Stack Overflow for car questions...

This is the 46th episode of the StackOverflow podcast, live from MIX09, where Joel and Jeff answer questions from the live audience.

This podcast is live from the MIX09 conference! Joel and I also had a small 5 minute segment in the Day 1 keynote, which you can view online. It's at around the 50 minute mark or so.

We had a live audience, so the focus of this podcast is on questions from our live audience.

We answered the following live audience questions on this podcast:

"What's the point of Silverlight?" The short answer is, it's like Adobe Flash, but much more programmer oriented. Silverlight 3 beta was just launched at MIX, with lots of new developer-y goodness.

"What's the most number of questions asked by an actual Stack Overflow user?" That would be Edward Tanguay with 210 questions, closely followed by Thomas Owens who asked 207 questions. One reason the "ask a question" button isn't more prominent on the site is that we encourage people to read and answer a while before asking anything. Good questions take some effort!

"Have you ever considered moving Stack Overflow to the cloud?" The cloud makes more sense for experimental projects that may or may not succeed. We did the math and decided that owning the hardware was a better deal for our project. It could also make sense for hot-standby disaster recovery backup servers. It depends whether or not you prefer flexibility, or fine-grained control.

"What issues did you have with using ASP.NET MVC?" Other than the typical beta issues, not much. The big advantage, to us, is that MVC is a much more web-centric development model. It is a much closer match to our mental model of how web programming should work, and how URLs should be formed.

"What does the new guy do on the first day?" Fix the simplest possible bug in your product. And on the next day, fix a slightly more complex bug. It helps to do this in an environment of active pairing or mentoring.

"Are there some things about the web platform (HTML, CSS, etc) that you wish worked differently?" Sure, the platform barely works. There's something inspiring about so many programmers are building great stuff on such a rickety platform. And it's creating a whole new generation of programmers. There's a certain inexplicable elegance to the madness.

"We have a lot of relatively unstructured data that we're storing in a database, is there some other way do deal with this? And what about REST vs. SOAP access to it?" Joel points to Adam Bosworth's classic talk about the flexibility of loosely structured data. Perhaps something like Lucene or CouchDB would be a better choice than a traditional rigid database. And remember that meta-tags, while worthless on the open web, are trustworthy on local data. Sometimes you don't need a perfect 100% right answer back from the data. Joel describes the advantage of REST over SOAP thusly: you can just type stuff into the browser's address bar and see the results in real time.

"Should you teach the framework, or the underlying languages?" Joel points out that maybe students shouldn't be studying programming at all. You can learn a lot about programming through related fields. Joel and I disagree a bit on this one. I think good developers are inherently curious, so they can learn the framework and dip into the lower level language as necessary to solve whatever problem is at hand. Joel says you should start with the language and scale up.

"How different is the world view of a programmer who is twenty-something and grew up with the web, versus a thirty-something who didn't? How important is historical context?" Can developers who only know JavaScript, HTML, and CSS grow into being generally great developers? I argue that there's an inherent intellectual curiosity in all great programmers, so they can start anywhere and get amazing results. Joel notes that some of the historical context can become a burden and possibly even incorrect over tim...

This is the 45th episode of the StackOverflow podcast, where Joel and Jeff discuss what a program manager does, the value (or lack thereof) of a functional spec and vision statement, building developer community, and planning your development time.

Joel and I will be at the upcoming MIX09 conference. We're also trying to set up a live podcast there on Tuesday, March 17th in the evening.

Joel's essay How to be a Program Manager attempts to explain the essential role this person plays on a software project. It's a shame the job has such a nebulous title.

Is writing a functional spec at the heart of agile development? What is a spec, exactly? There has to be something between sitting down and pounding out the code with no planning whatsoever, and meticulously, bureaucratically documenting every tiny detail of your application.

Not all storyboarding has to be painful. Wireframing the user interface with tools like Balsamiq can take the pain out of a lightweight "functional spec". Describe every screen, and have some annotations about how stuff is supposed to work. I call this UI-first software development.

The often cited article No Functional Spec doesn't actually mean no functional spec, if you read it closely. At least in our interpretation of the text.

Can your team pass the elevator test? You also need a vision statement or "elevator pitch". Everyone on your team should be able to explain what your application does, in a few simple paragraphs, to a layman. If they can't, it's sign of deeper problems on your project.

The book Dreaming in Code, which documents the Chandler project, might be a good example of a project that had a vision statement that hurt the project instead of helping. It described where they wanted to go, but not how they planned to get there. Flock might be another example -- what does "we're a social web browser" mean?

Dave Winer maintains that, if you read the description of some new technical thing and can't understand it after the first readthrough.. it ultimately isn't important and can be safely ignored.

Has Joel Spolsky been honest about his time at Microsoft? Realize that the article in question is one of Joel's first non-blog blog posts, way back in 2001, describing something that happened in 1992. So it's ancient history. Joel maintains that Greg Whitten's 2005 email is simply the other half of the story. There's no conflict, just two sides of the same coin.

For all the talk about how Reddit comments have degenerated, we felt the programming reddit comments on the Joel article were generally quite insightful.

Joel and I are big fans of Hacker News. Although I have criticized the lack of downvotes in the Hacker News system, it's important to note that there is a secret cabal of 30 editors that will kill flagged articles. So it's not entirely subject to the whims of user voting, either.

Joel thinks that every hacker who maintains a community comes up with a manifesto that puts them squarely in Clay Shirky a Group is its Own Worst Enemy land. Even he has done it, with Building Communities With Software. You have to make very different decisions based on the size and the composition of the group at any particular time.

Joel and I both dislike threaded discussion formats. When I delved back into threaded discussion this week on the programming Reddit and Hacker News I was reminded how awkward they are. I think developers have a myopia about tree structures, which are incomprehensible to the average person but a daily part of their programming work.

I was shocked to discover that SQL Server will sometimes look at a parameterized query and come up with an incredibly bad query plan, which it will then store in the query cache, and (even worse!) use over and over! The trick is to use the optimize for unknown hint, which tells the query plan generator to use a statistical sampling of potential inputs rather than basing its decisions on whatever random paramet...

This is the 44th episode of the StackOverflow podcast, where Joel and Jeff discuss the enduring influence of C, the questionable value of the title "Software Architect", and the evolution of Java.

Joel brings the YouTube video Write it in C to our attention. "Pascal won't quite cut it, write in C." Did you know that there's a new version of C++ on the horizon, C++0x? It even has its own tag on Stack Overflow.

Speaking of C, Joel had lunch (and just guest-taught a class at Princeton for) Brian Kernighan. Brian is of course the co-author of the classic K&R book, and the creator of the Awk language. And his second favorite language is Visual Basic, surprisingly.

I'm a little bitter that so many languages (C#, Java, JavaScript, etc) followed the "look" and many of the important design decisions of C, but Joel blames Algol-68.

One C design decision I agree with: using carriage return as your programming line terminator is not a good idea. Having an explicit line ending character like semicolon gives you so much more flexibility, and is far less awkward than weird line continuation characters.

Extension methods in C# are a poor man's way of extending the underlying language.

One new feature in C# 4.0 is named parameter arguments. Joel notes that Excel's VBA implementation went through this same evolution, and it can potentially mask problems, like "why the heck do we have a function with 7 parameters in the first place?"

We implemented the fantastic open-source Cacti tool to graph how much bandwidth and CPU time we're using on our servers. Our ISP does burstable billing at the 95th percentile, and this graph is built into Cacti. Right now we're doing about 750 KB/sec or 6 megabits/sec under those terms, which is (unfortunately) more than we agreed on with our ISP. This throughput number is 99% GZIP compressed text.

What is the rationale for expressing all network bandwidth units in terms of bits? I prefer bytes. And while I'm at it, what the heck is a kibibyte?

Remember Alexa? They're still around. It is sort of a mystery how sites like Alexa, Compete, etcetera can infer web traffic for any random website without access to the webserver's logfiles. It's essentially client sampling, but the accuracy of this approach is anyone's guess.

Joel's classic article on unnecessary choice in software reminds us how customization is a double-edged sword. We've resisted a lot of per-user customization options on Stack Overflow for similar reasons.

Joel and I both are unsure that the title "Software Architect" is a good one. We're leaning towards it being almost.. a net negative. "It's almost disrespectful of the actual architects who work in construction, to use that word to refer to some kind of high-falutin' big-picture UML-drawing code monkey."

To the extent that the architect is not in the trenches with you doing

the work, they don't have enough context, and will inevitably make the wrong

decisions.

If we had the power, we'd do away with the title "Architect". But if you're stuck with it -- and the architecture astronomy that it frequently engenders -- what is the proper role for a so-called Architect? They could work to connect disparate groups at large organizations, to provide context and reduce duplication for disparate groups that are working in isolation. It can be hard for groups working locally to see the context of the larger organization. But I traditionally think of this role as an evangelist and educator, not an architect.

The catch-22 of rekindling a nascent programming career is that.. good programmers can't stop programming. So if you can give up programming, it sort of almost means that you shouldn't be doing it anyway. This is Joel's tough love answer. Bottom line: if you want to be a programmer, get out there and start writing code.. yesterday.

Joel thinks that Java on the desktop is essentially dead. I don't necessarily disagree, but I think Java is still a fine choic...

This is the 43rd episode of the StackOverflow podcast, where Joel and

Jeff discuss dealing with incompetent programmers, whether salaries should be public, dealing with technical debt, and programming for small businesses.

Joel is away this week in Florida at the Future of Web Applications conference, where he was a speaker. He mentioned that the new Atlas web GUI builder was particularly impressive.

We will try to be more careful about our use of Begs The Question.

Joel asks about the rationale behind requiring 50 reputation to leave a comment, but allowing a brand new user to post a question or leave an answer. The reason is mostly because we have no mechanism for voting or marking offensive on comments, because they're ultra-lightweight.

One way to avoid the dilemma of dealing with bad programmers is to be selective who you work for -- only choose employment at companies where they Hit the High Notes. It's even in the Joel Test itself: do new hires have to write code?

I'm not a fan of puzzle-based interview processes. I met with a Stack Overflow user this week, Chris Jester-Young, and he revealed a clever and potentially more useful strategy: give interviewees a C program full of bugs, and have them try to debug them! Of course, Chris is a big Code Golf enthusiast, so of course he nailed that one.

Sometimes you have to try to change your organization to fix the root problems, otherwise you're just fighting the symptoms and not the disease itself. This can be quite a challenge when you have no real authority. Joel offers some advice in Getting Things Done When You're Only a Grunt.

Are there happy incompetents? I argue that there are; Joel argues that there aren't. Among the Inept, Ignorance is Bliss. Perhaps the better question to ask is, how can you help this marginal programmer find a career they'll enjoy? Many so-so programmers can make outstanding testers, for example.

We wonder: what would it be like to work at a commercial for-profit company where everyone's salaries were public knowledge? I imagined it as something like The Lord of the Flies. Just make sure you aren't Piggy!

At Fog Creek, salaries aren't technically public, but they have a formula through which everyone's pay can be derived. This is the Fog Creek Professional Ladder. Fog Creek also does profit sharing, so when the company does well, everyone does well.

Is there a two-class society at Microsoft, between Testers and Developers? Joel wonders why they need different titles. I had always heard Microsoft did a great job of giving test engineers a viable parallel career track.

Joel believes manipulating compensation to motivate people does not work, almost by definition. Top developers will do a good job no matter what compensation system you put in front of them. It's a "blunt instrument" that can cause as much harm as good. Joel is an advocate of "taking salary discussion off the table, paying people fairly and justly and well, so they can stop worrying about it so much."

We have a lot of anti-bot code on Stack Overflow. What we didn't think about was human-entered spam! Now we do -- yet another example of the incredible power of rate limiting techniques.

On matters of customer service, we do endeavor to not make the situation worse. Start practicing saying "I'm sorry, it's our fault."

Updates may slow down on Stack Overflow for a little while. We have built up a lot of technical debt around our database, and we have to hunker down and refactor a few core database tables that affect 80% of our code. If you don't pay down your technical debt every so often, you could end up like Twitter -- a reliability laughingstock. But, somehow, still successful.

There's something liberating and energizing about going in and tearing down huge parts of your application to rebuild it and make it better. Unlike our previous discussion on learning languages, I'm more of an advocate of the big bang model here, whereas Joel...

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 [email protected] 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 sho...