The Wayback Machine - https://web.archive.org/web/20090410040340/http://blog.stackoverflow.com:80/

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 worked 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:

  1. 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?”
  2. 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 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.

 
icon for podpress  Podcast 48 [01:17:39m]: Play Now | Play in Popup | Download

Editing is the backbone of Stack Overflow, and probably (along with the reputation system) one of the single most important distinctions between Stack Overflow and “just another forum”.

What’s so special about editing? You might as well ask what’s so special about editing on Wikipedia? Uh… everything?

As it says in the FAQ:

Other people can edit my stuff?!

Like Wikipedia, this site is collaboratively edited. If you are not comfortable with the idea of your questions and answers being edited by other trusted users, this may not be the site for you.

In The Great Edit Wars, we discussed some general guidelines for good editing. Please do read those. But I realized that I could have been clearer, and more specific. So here’s some additional guidance.

  1. If you are going to edit a post, make sure you’re substantively improving it. Avoid making isolated, trivial edits, as they are the source of much friction. For example, don’t bother changing “its” to “it’s” unless you have several other edits to make in the same post. There has to be a legitimate case that your edit made multiple changes transforming the post from good to great — or at least substantively improving it.

    (Except when you happen to be editing that rare “perfect except for this one misspelled word” post. This is obviously OK to edit. In my experience, the type of posts that really cry out for editing need a lot of editing to be whipped into shape.)

    To be very specific, I would discourage editing a post solely to remove salutations like “hi” and “thanks”. That’s just adding an unnecessary edit on top of an unnecessary set of salutations. I completely agree that salutations add little to a question or answer, but if you’re going to take the time to go in and remove salutations, fix the whole post while you’re at it! If there’s nothing else to edit, then don’t bother.

  2. Be diplomatic in your edit-related comments. If you are going to make edits, you have to be more diplomatic and friendly than “suck it up, the FAQ says I can do this.” Explain that the spirit of SO is collaborative editing, and you’re only trying to make substantive improvements (see rule #1). More readable questions and answers leads to better information for all future travellers! Above all, be nice. And as mentioned in the blog entry on edit wars, if there’s any resistance — even unwarranted and unjustifiable resistance — just let go and move on.

  3. Every edit is a judgment call. Do we encourage editing? Yes! Do we demand that every user accept every edit? No. There’s no way I can make a blanket statement like that. Do I trust my wife? Sure. Do I agree with every single thing she’s ever done? No. It would be irrational to expect any person on the internet to extend more trust than this to me.

    We know editing is a net good, but not everyone does… yet. Forcing the issue does nobody any favors, generating active hostility and ill will. Unless the edit is of critical importance (which seems implausible, except in cases of vandalism or evil, which is a wholly different thing) you have to just let them learn the system at their own pace. As they say, you’ll get more flies with honey than vinegar.

    The vast majority of edits I see, I am fine with. But in the case where the original poster is unwilling to accept the edits and actively rejects them — please do not force the issue. It just leads to heartache. When in doubt, move on. There’s no shortage of editing opportunities, in fact, more are being written every minute. There are thousands of users who would appreciate reasonable edits that improve their post. Do not fight an edit war over a crumb of bread — there’s nothing there worth fighting for! It’s easier to just move on and get work done than create pain all out of proportion to the importance of the individual edit.

Editing is often the difference between crap and not-crap. It is hugely important.

But how you edit — the spirit of the edit — is just as important as the edit itself. By all means, edit away, but please try to keep that in mind.

Are you familiar with the Penalty Box?

The penalty box (sometimes called the sin bin, bad box, or bin) is the area in ice hockey, rugby football and some other sports where a player sits to serve the time of a given penalty, for an offense not severe enough to merit outright expulsion from the contest. Teams are generally not allowed to replace players who have been sent to the penalty box.

It’s not something we looked forward to, but as of tonight, we’re instituting a penalty box on Stack Overflow.

As I’ve mentioned before, our general strategy is to discourage specific negative behaviors, not individual users. We try to let people know when there are problems via direct communication. We don’t hold grudges; if you can address the problematic behavior, you’re welcome back any time. But sometimes you just can’t seem to reach people — even after multiple attempts to contact them and address the problematic behaviors.

There’s only one rule of behavior that really matters, whether on Stack Overflow, or anywhere else:

don’t be a jerk.

How do you know you’re being a jerk?

  • Other users react negatively to your posts, posting negative responses and generally causing a commotion.
  • There is a broad sense of community resentment over your behavior, and you are frequently cited in discussion about the community.
  • The moderators get regular email complaints about your behavior.
  • You make snide or rude comments “behind people’s backs”, in public places.

While there can always be polite disagreement, this level of discontent is unacceptable for two reasons:

  1. it takes up moderator time that could be used to develop or enhance the site.
  2. it actively turns people away from the community, stunting its growth.

So starting tonight, there will be consequences.

penalty-box

If a moderator has warned you several times via email about behavior, and that behavior continues, for a period of 2 to 7 days, your account will be in timed suspension.

  • Your account will be locked at 1 reputation.
  • Your user page will have a visual indication that you are in timed suspension, and for how long.
  • You will be unable to ask or answer questions.

At the end of this period, your reputation will be recalculated, and your account will resume as normal. As I said, we don’t hold grudges; the point of all this is to address the behavior. If the behavior improves, we’re cool.

(This should probably go without saying, but if the problem behaviors continue beyond the timed suspension, your account is very likely to be permanently deleted.)

We get wonderful emails from programmers almost every week, programmers who are impressed with the effectiveness of Stack Overflow and the platform agnostic community spirit it embodies. We consider ourselves very fortunate to be in a position to get such email, and we greatly appreciate each and every one of them. I always reply and share those emails with our team, but I don’t necessarily reprint them here — I don’t want this blog to become a rah-rah marketing effort.

But I do want to share with you one of those emails, the one that made me proudest to be a part of this community. (You may know this Stack Overflow user, so I’ve redacted anything that would make it personally identifiable.)

I’m not sure if you have thought about this side effect or not, but Stack Overflow has taught me more about writing effectively than any class I’ve taken, book I’ve read, or any other experience I have had before.

I can think of no other medium where I can test my writing chops (by writing an answer), get immediate feedback on its quality (particularly when writing quality trumps technical correctness, such as subjective questions) and see other peoples attempts as well and how they compare with mine. Votes don’t lie and it gives me a good indicator of how well an email I might send out to future co-workers would be received or a business proposal I might write.

Over the course of the past 5 months all the answers I’ve been writing have been more and more refined in terms of the quality. If I don’t end up as the top answer I look at the answer that did and study what they did differently and where I faltered. Was I too verbose or was I too terse? Was I missing the crux of the question or did I hit it dead on?

I know that you said that writing your Coding Horror blog helped you greatly in refining your writing over the years. Stack Overflow has been doing the same for me and I just wanted to thank you for the opportunity. I’ve decided to setup a coding blog in your footsteps and I just registered a domain today. Hopefully that will go as well as writing on SO has. There are no tougher critics than fellow programmers who scrutinize every detail, every technical remark and grammar structure looking for mistakes. If you can effectively write for and be accepted by a group of programmers you can write for anyone.

There’s nothing I respect more than a great programmer. But if you can manage to become a great programmer and a great communicator, there’s almost nothing you can’t accomplish. I know I’ve said this several times already, because I tend to repeat myself. I said I tend to repeat myself! But I have to point to my favorite Joel Spolsky quote again:

The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless. By writing clear technical documentation for end users, they allow people to figure out what their code is supposed to do, which is the only way those users can see the value in their code. There’s a lot of wonderful, useful code buried on sourceforge somewhere that nobody uses because it was created by programmers who don’t write very well (or don’t write at all), and so nobody knows what they’ve done and their brilliant code languishes.

I won’t hire a programmer unless they can write, and write well, in English. If you can write, wherever you get hired, you’ll soon find that you’re getting asked to write the specifications and that means you’re already leveraging your influence and getting noticed by management.

To the extent that Stack Overflow is helping my fellow programmers achieve the goal of becoming better writers and communicators, it is succeeding beyond my wildest possible dreams.

And for that, I am immensely thankful.

Thankful to each and every programmer who sees fit to slice off a small bit of their time to share their expertise and knowledge through Stack Overflow. You guys (and gals) rock.

Since we had such good results from our previous community logo contest, we’re doing the same thing for serverfault.com:

We have a serverfault.com logo design contest at 99 designs, with a prize of $29 at stake.

99 designs logo

This time I’ve also added $50 prizes for second and third place. I always felt bad that the logos we didn’t pick for Stack Overflow were so good, and I had nothing to give the designers for their effort. Luckily, our good friend Leon Bambrick stepped in at the last minute with free licenses for TimeSnapper, which was a very nice gesture. No disrespect meant to Mr. Bambrick, but I think they’ll like the 50 bucks even better. :)

I’ve noticed that a few of the logo designs that initially appeal to me are thematically matching to Stack Overflow. I like this trend!

To be clear, we plan for stackoverflow.com and serverfault.com to be “sister sites”, meaning:

  • they run the same underlying software
  • they support shipping questions back and forth to each other

But each one will have

  • its own community
  • its own domain name
  • its own set of moderators
  • its own logo
  • its own set of colors and visual style

We will also have a brief (1 week?) beta period, as mentioned before, and all Stack Overflow users with > 200 rep will be invited to participate.