Announcing Stack Overflow for Teams

Hey, we have a new thing for you today!

Today’s new thing is called Stack Overflow for Teams. It lets you set up a private place on Stack Overflow where you can ask questions that will only be visible to members of your team, company, or organization. It is a paid service, but it’s not expensive.

I meet people who use Stack Overflow every single day, but a lot of them tell me they have never needed to post their own question. “All the questions are already answered!” they say. Mission accomplished, I guess!

Still, when I think about what questions developers have every day, only the ones that have to do with public stuff can be asked on Stack Overflow. Maybe you don’t have a question about Python or Android… maybe you want to ask something about your team’s own code base!

That’s the idea behind Stack Overflow Teams.

Helicopters

Quick background: every development team since the beginning of time has been trying to figure out how to get institutional knowledge out of people’s heads and into written, searchable form where everyone can find it. Like new members of the team. And old members of the team working on new parts of the code. And people who forgot what they did three years ago and now have questions about their own code.

For a while developers thought wikis might be the solution. Anyone who has used a wiki for this purpose has probably discovered that not very much knowledge actually makes it into the wiki, and what does is not particularly useful, doesn’t get updated, and honestly it just feels like a bunch of homework to write a bunch of wiki documentation about your code when you don’t know if it will ever help anyone.

Another solution being sold today is the idea of having some kind of online IRC-style chat rooms, and hoping that by searching those chat archives, you can find “institutional knowledge.” Ha ha ha! Even if that works, all you really find is the history of some conversation people had. It might have clues but it’s not knowledge.

But you know what does work? A Q&A system. Like Stack Overflow.

Why? Because unlike wikis, you don’t write documentation in the hopes that one day it might help someone. You answer questions that are going to help someone immediately. And you can stop answering the minute you get the green checkmark that shows that you solved their problem.

And unlike chatrooms, searching actually works. It finds you a question and its answers, not a conversation-captured-in-amber.

This is why Stack Overflow worked so much better on the public internet than the previous generation of discussion forums, and we think that it will work for all the same reasons with teams’ proprietary questions and answers.

When you join a team, you’ll see your team’s private questions right on stackoverflow.com (although they actually live in a separate database for security). Your teams are listed in the left hand navbar.

Screen Shot

Everything else works pretty much … like you would expect. When you ask a question, you can direct it to your team or to the whole world. The UI makes it very clear whether you are posting publicly or privately. If you are asking a question of your team, there’s a Notify field so you can type the names of some people who might be able to answer the question, and they’ll hear about it right away.

Screen shot

When you search, you can search everywhere, or just within your team. You can set up tags that are specific to your team, too.

The pricing is designed to be “no-brainer” pricing, starting at just $10 per month for the first ten users.

I think Stack Overflow for Teams is going to be almost as important to developers’ daily work as public Stack Overflow. It brings Stack Overflow’s uniquely powerful system to every developer question, not just the things that can be discussed in public. You can stop asking your teammates questions in email (where they help nobody else) or in chatrooms (where they are impossible to find) and start building your own private knowledge base to document your code and answer future teammates’ questions before they have them.

Strange and maddening rules

There’s this popular idea among developers that when you face a problem with code, you should get out a rubber duck and explain, to the duck, exactly how your code was supposed to work, line by line, what you expected to see, what you saw instead, etc. Developers who try this report that the very act of explaining the problem in detail to an inanimate object often helps them find the solution.

Stack Overflow April Fools Joke 2018This is one of many tricks to solving programming problems on your own. Another trick is divide and conquer debugging. You can’t study a thousand lines of code to find the one bug. But you can divide them in half and quickly figure out if the problem happens in the first half or the second half. Keep doing this five or six times and you’ll pinpoint the single line of code with the problem.

It’s interesting, with this in mind, to read Jon Skeet’s checklist for writing the perfect question. One of the questions Jon asks is “Have you read the whole question to yourself carefully, to make sure it makes sense and contains enough information for someone coming to it without any of the context that you already know?” That is essentially the Rubber Duck Test. Another question is “If your question includes code, have you written it as a short but complete program?” Emphasis on the short—that is essentially a test of whether or not you tried divide and conquer.

What Jon’s checklist can do, in the best of worlds, is to help people try the things that experienced programmers may have already tried, before they ask for help.

Sadly, not everybody finds his checklist. Maybe they found it and they don’t care. They’re having an urgent problem with code; they heard that Stack Overflow could help them; and they don’t have time to read some nerd’s complicated protocol for requesting help.

One of the frequent debates about Stack Overflow is whether the site needs to be open to questions from programming novices.

When Jeff and I were talking about the initial design of Stack Overflow, I told him about this popular Usenet group for the C programming language in the 1980s. It was called comp.lang.c.

C is a simple and limited programming language. You can get a C compiler that fits in 100K. So, when you make a discussion group about C, you quickly run out of things to talk about.

Also. In the 1990s, C was a common language for undergraduates who were learning programming. And, in fact, said undergraduates would have very basic problems in C. And they might show up on comp.lang.c asking their questions.

And the old-timers on comp.lang.c were bored. So bored. Bored of the undergraduates showing up every September wondering why they can’t return a local char array from a function et cetera, et cetera, ad nauseum. Every damn September.

The old timers invented the concept of FAQs. They used them to say “please don’t ask things that have been asked before, ever, in the history of Usenet” which honestly meant that the only questions they really wanted to see were so bizarre and so esoteric that they were really enormously boring to 99% of working C programmers. The newsgroup languished because it catered only to the few people that had been there for a decade.

Jeff and I talked about this. What did we think of newbie questions?

We decided that newbies had to be welcome. Nothing was too “beginner” to be a reasonable question on Stack Overflow… as long as you did some homework before asking the question.

We understood that this might mean that some of the more advanced people might grow bored with duplicate, simple questions, and move on. We thought that was fine: Stack Overflow doesn’t have to be a lifetime commitment. You’re welcome to get bored and move on if you think that the newbies keep asking why they can’t return local char arrays (“but it works for me!”) and you would rather devote the remaining short years of your life to something more productive, like sorting your record albums.

The mere fact that you are a newbie doesn’t mean that your question doesn’t belong on Stack Overflow. To prove the point, I asked “How do you move the turtle in Logo,” hoping to leave behind evidence that the site designers wanted to allow absolute beginners.

Thanks to the law of unintended consequences, this caused a lot of brouhaha, but not because the question was too easy. The real problem there was that I was asking the question in bad faith. Jeff Atwood explained it: “Simple is fine. No effort and research is not.” (Also this.)

To novices, the long bureaucratic rigmarole associated with asking your first question on Stack Overflow can feel either completely unnecessary, or just plain weird. It’s like Burning Man. You just want to go to a nice glittery dance party in the desert, but the Burning People are yammering on about their goddamn 10 principles, and “radical self-expression” and so on and so forth, and therefore after washing your dishes you must carefully save the dirty dishwater like a cherished relic and remove every drop of it from the Playa, bringing it home with you, in your check-in luggage if necessary. Every community has lots of rules and when you join the community they either seem strange and delightful or, if you’re just desperately trying to get some code to work, they are strange and maddening.

A lot of the rules that are important to make Burning Man successful are seemingly arbitrary, but they’re still necessary. The US Bureau of Land Management which makes the desert available for Burning Man requires that no contaminated water be poured out on the ground because the clay dirt doesn’t really absorb it so well and it can introduce all kinds of disease and whatnot, but who cares because Burning Man simply will not be allowed to continue if the participants don’t pack out their used water.

Similarly for Stack Overflow. We don’t allow, say, questions that are too broad (“How do I make a program?”). Our general rule is that if the correct length of an answer is a whole book you are asking too much. These questions feel like showing up on a medical website and saying something like “I think my kidney has been hurting. How can I remove it?” It’s crazy—and incidentally, insulting to the people who spent ten years in training learning to be surgeons.

One thing I’m very concerned about, as we try to educate the next generation of developers, and, importantly, get more diversity and inclusiveness in that new generation, is what obstacles we’re putting up for people as they try to learn programming. In many ways Stack Overflow’s specific rules for what is permitted and what is not are obstacles, but an even bigger problem is rudeness, snark, or condescension that newcomers often see.

I care a lot about this. Being a developer gives you an unparalleled opportunity to write the script for the future. All the flak that Stack Overflow throws in the face of newbies trying to become developers is actively harmful to people, to society, and to Stack Overflow itself, by driving away potential future contributors. And programming is hard enough; we should see our mission as making it easier.

We’re planning a lot of work in this area for the next year. We can’t change everybody and we can’t force people to be nice. But I think we can improve some aspects of the Stack Overflow user interface to encourage better behavior, for example, we could improve the prompts we provide on the “Ask Question” page, and we could provide more tools for community moderation of comments where the snark currently runs unchecked.

We’re also working on new features that will let you direct your questions to a private, smaller group of people on your own team, which may bring some of the friendly neighborhood feel to the big city of Stack Overflow.

Even as we try to make Stack Overflow more friendly, our primary consideration at Stack Overflow has been to build the world’s greatest resource for software developers. The average programmer, in the world, has been helped by Stack Overflow 340 times. That’s the real end-game here. There are other resources for learning to program and getting help, but there’s only one site in the world that developers trust this much, and that is worth preserving—the programming equivalent to the Library of Congress.

A Dusting of Gamification

[This is the second in a series of posts about Stack Overflow. The first one is The Stack Overflow Age.]

Around 2010 the success of Stack Overflow had led us into some conversations with VCs, who wanted to invest.

at the Getty

The firm that eventually invested in us, Union Square Ventures, told us that they were so excited by the power of gamification that they were only investing in companies that incorporated some kind of game play.

For example, Foursquare. Remember Foursquare? It was all about making your normal post-NYU life of going to ramen noodle places and dive bars into a fun game that incidentally generated wads of data for marketers. Or Duolingo, which is a fun app with flash cards that teaches you foreign languages. Those were other USV investments from that time period.

At the time, I had to think for a minute to realize that Stack Overflow has “gamification” too. Not a ton. Maybe a dusting of gamification, most of it around reputation.

Stack Overflow reputation started as a very simple score. The original idea was just that you would get 10 points when your answers were upvoted. Upvotes do two things. They get the most useful answers to the top, signaling that other developers who saw this answer thought it was good. They also send the person who wrote the answer a real signal that their efforts helped someone. This can be incredibly motivating.

You would lose points if your questions were downvoted, but you actually only lose 2 points. We didn’t want to punish you so much as we wanted to show other people that your answer was wrong. And to avoid abuse, we actually make you pay one reputation point to downvote somebody, so you better really mean it. That was pretty much the whole system.

Now, this wasn’t an original idea. It was originally inspired by Reddit Karma, which started out as an integer that appeared in parentheses after your handle. If you posted something that got upvoted, your karma went up as a “reward.” That was it. Karma didn’t do a single thing but still served as a system for reward and punishment.

What reputation and karma do is send a message that this is a community with norms, it’s not just a place to type words onto the internet. (That would be 4chan.) We don’t really exist for the purpose of letting you exercise your freedom of speech. You can get your freedom of speech somewhere else. Our goal is to get the best answers to questions. All the voting makes it clear that we have standards, that some posts are better than others, and that the community itself has some norms about what’s good and bad that they express through the vote.

It’s not a perfect system (more on the problems in a minute), but it’s a reasonable first approximation.

By the way, Alexis Ohanian and Steve Huffman, the creators of Reddit, were themselves inspired by a more primitive karma system, on Slashdot. This system had real-world implications. You didn’t get karma so that other people could see your karma; you got karma so that the system knew you weren’t a spammer. If a lot of your posts had been flagged for abuse, your karma would go down and you might lose posting or moderation privileges. But you weren’t really supposed to show off your high karma. “Don’t worry too much about it; it’s just an integer in a database,” Slashdot told us.

To be honest, it was initially surprising to me that you could just print a number after people’s handles and they would feel rewarded. Look at me! Look at my four digit number! But it does drive a tremendous amount of good behavior. Even people who aren’t participating in the system (by working to earn reputation) buy into it (e.g., by respecting high-reputation users for their demonstrated knowledge and helpfulness).

But there’s still something of a mystery here, which is why earning “magic internet points” is appealing to anyone.

I think the answer is that it’s nice to know that you’ve made a difference. You toil away in the hot kitchen all day and when you serve dinner it’s nice to hear a compliment or two. If somebody compliments you on the extra effort you put into making radish roses, you’re going to be very happy.

This is a part of a greater human need: to make an impact on the world, and to know that you’re contributing and being appreciated for it. Stack Overflow’s reputation system serves to recognize that you’re a human being and we are super thankful for your contribution.

in Utah

That said, there is a dark side to gamification. It’s not 100% awesome.

The first problem we noticed is that it’s very nice to get an upvote, but getting a downvote feels like a slap in the face. Especially if you don’t understand why you got the downvote, or if you don’t agree. Stack Overflow’s voting has made many people unhappy over the years, and there are probably loads of people who felt unwelcome and who don’t participate in Stack Overflow as a result. (Here’s an old blog post explaining why we didn’t just eliminate downvotes).

There’s another problem, which is that, to the extent that the gamification in Stack Overflow makes the site feel less inclusive and welcoming to many people, it is disproportionately off-putting to programmers from underrepresented groups. While Stack Overflow does have many amazing, high reputation contributors who are women or minorities, we’ve also heard from too many who were apprehensive about participating.

These are big problems. There’s a lot more we can and will say about that over the next few months, and we’ve got a lot of work ahead of us trying to make Stack Overflow a more inclusive and diverse place so we can improve the important service that it provides to developers everywhere.

Gamification can shape behavior. It can guide you to do certain things in certain ways, and it can encourage certain behaviors. But it’s a very weak force. You can’t do that much with gamification. You certainly can’t get people to do something that they’re not interested in doing, anyway. I’ve heard a lot of crazy business plans that are pinning rather too high hopes on gamification as a way of getting people to go along with some crazy scheme that the people won’t want to go along with. Nobody’s going to learn French just to get the Duolingo points. But if you are learning French, and you are using Duolingo, you might make an effort to open the app every day just to keep your streak going.

I’ve got more posts coming! The next one will be about the obsessive way Stack Overflow was designed for the artifact, in other words, we optimized everything to create amazing results for developers with problems arriving from Google, not just to answer questions that people typed into our site.

 

The Stack Overflow Age

Hi, everyone! A lot of stuff has happened since I was writing all those blog posts about Aeron chairs 18 years ago. Some of those blog posts are old enough to go to college.

And, also: Stack Overflow will be ten years old soon! Wow! So I thought it would be cool to get the old band back together for a little reunion tour over the next few weeks. I want to catch you all up on some stuff but mostly I want to tell the story of Stack Overflow in a not-completely-disorganized way. With some perspective, it’s clearer now what we did right and what we messed up, so I’ll try to cover the good and the bad over a series of blog posts.

And, also: we’re just a few weeks away from launching Stack Overflow Teams, the biggest upgrade to Stack Overflow ever, so that’s going to be really cool. I’ll get to that in a future blog post!

Today is chapter one. I want to talk a little bit about what it was like for developers before Stack Overflow, the problem that Stack Overflow tried to solve, and early origins.

In the early days of the Internet, before the Web, there was a system called Usenet which created primitive online discussion forums. When programmers had problems with their code, they could ask a question on a Usenet forum. (They were technically called newsgroups, not forums (even though they had nothing to do with news. (You couldn’t even get news on Usenet.)))

As soon as the world wide web became a thing, Usenet was immediately technically obsolete. We programmers started asking about our problems on various web-based forums, of which there were thousands.

One of the biggest such forums was called Experts Exchange. The first version of Experts Exchange was not successful financially. Apparently they went bankrupt in 2001. Eventually new owners bought the assets and resurrected the site with a clever business model: charging money to read answers.

This actually fixed the business, which started making money, but it caused some problems.

The first problem was that programmers with problems would search on Google, not on Experts Exchange. And Google only knows about free, open websites, not websites that you have to pay to access. So EE did a bamboozle: when the Google Robot came by, they showed it the full question and its answers. But when regular people went to the same page, they saw the answers were scrambled, with instructions to pay (I think it was about $250 a year) to see the results. Most programmers couldn’t be bothered.

The second problem was that EE let you get a free membership if you answered a certain number of questions. As it turned out, the people who were most desperate for free memberships were not exactly the best programmers in the world, and they wrote low quality answers to questions just to get those free memberships. And the quality of answers on the site went down.

For a long time (at least five years, I think) programmers would constantly come across EE in the Google search results, try to click on them, discover that it was a pay site, grumble, and just go back to Google and try to find an answer for free.

And I kept thinking, how hard is it to run a discussion forum on the Internet? For fudge sake, I had written one in Visual Basic in a weekend. (Not kidding, actually. Yeah I know that I am always saying “I could do that in a weekend in Visual Basic” when developers tell me some feature is going to take a year. This is why). So I was confident that it was only a matter of time before one of the 9,000,000 smart programmers in the world decided to route around this EE damage and make a free forum.

You know what? Nobody ever did. I kept waiting.

Another thing I wrote in a weekend (well, to be precise: a fortnight (shut up, I’m telling this lie)) was a job listing board for this blog. And in the first month of running that job board I think we sold about $90,000 of job listings. Huzzah! And then I thought, wow, if we smashed these ideas together—replace Experts Exchange with a free site, and pay for it with job listings—we could undo the damage to the internet and let developers get work done again.

I kept thinking “Man, this is so obvious, somebody is going to do it.”

And they never did.

And I went to one of the programmers at Fog Creek, and explained my idea, and he was like “yeah yeah sounds like a great idea, but I really like working on FogBugz.”

And more time went by.

And eventually, early in 2008, a developer/blogger named Jeff Atwood called me up, and said, “Hey Joel, I’m thinking of quitting my day job to be a Pro Blogger; you’re a blogger: what do you think?”

And I said, “Jeff, I’ve got a better idea” and I told him about the idea to combine the job listings with the Q&A site for developers, and, it took more than a weekend, but eventually I convinced him. We started talking about all the ways our Q&A site would be amazing. Jeff started working on the code in April 2008, recruited two other programmers to join him (Geoff and Jarrod, who are still here), and the three of them heroically launched what became Stack Overflow in September 2008.

 

The original Stack Overflow

 

And thus began the Stack Overflow Age.

Stack Overflow was better because it was free, but it had a ton of other “innovations” (which I put in quotes because we stole them from other Internet pioneers) which made it a much, much better site for getting answers to programming questions.

We wanted the whole thing to be a fun game, with incentives to answer questions, so we had a reputation system. The more you answer, the more reputation you earn. The reputation idea had been seen before on sites like Slashdot and Reddit.

As you earn reputation, you also earn moderation privileges on the site. So the site actually moderates itself, which is pretty cool.

Instead of putting all the Java programmers in one little forum and all the C++ programmers in another, we dumped everyone together and just let them tag their questions. This idea was stolen from flickr (remember flickr?) who, I think, stole it from del.icio.us (now gone)—who knows, anyway, the point is, tags were the new hotness and made Stack Overflow work great.

Most importantly, we realized that each question is asked by one person but the answers are seen by thousands of people who found it through a search. So we decided to optimize everything to be useful for the thousands, not the individual. We literally have 1000 visitors for every person who asks a question. That’s why we sort the answers by votes. It’s also why we optimize for questions and answers that will be helpful to other people, later.

Interestingly, when Jeff and I started Stack Overflow, we didn’t really care if it was a business and we didn’t need it to be a big profitable success. We created it because the internet sucked for programmers and we needed to make it better. We thought the job listings would pay the bills, and we’d fix the internet, and that was all we cared about and it’s what motivated us to work so hard.

Of course, it turned out a lot bigger than we thought it would. The company today has 250 employees, is profitable, and has made it possible for millions of people to learn how to code and to deal with the new, super-complicated world of APIs and frameworks that we live in. But we just wanted to fix the internet.

I have met a lot of people who started businesses because they wanted to start a business. Paul Graham calls this “Playing House.” And they didn’t really care what the business did; they just wanted to “be entrepreneurs.” Which is weird, because being an entrepreneur really sucks. It’s really hard to get through all the extraordinary difficulty, pain, and stress of starting a company if you’re not super, super motivated to solve a problem for the world.

The entrepreneurs who succeed do so because it is incredibly important to them a thing exist in the world, and it does not exist, so they work like crazy until it does. When we started Stack Overflow we didn’t expect it to be a big business; we just wanted there to be someplace where developers could get help to daily problems, while showing off how smart they were helping other developers.

Ok, that’s chapter one. I’ve got a lot more to talk about. In the next installment, I’ll talk more about how Stack Overflow’s light dusting of gamification made it really take off.

Birdcage liners

My new year’s resolution was to give up on reading Twitter and Facebook.

I gave up on the feeds because they were making me angry. A lot of times I was angry because of politics, but even on non-political things, the feeds seemed like they were full of conflict and stress.

I can’t tell you how much happier I am without them. Am I the only one that hated reading feeds? Do they make everybody unhappy? And if they make people unhappy why are they so popular?

Since I design social software for a living I feel like I should have a professional opinion on why Twitter and Facebook made me unhappy.

Let’s start with Twitter. I used Twitter to keep in touch with friends and colleagues because I cared about them. Unfortunately, those friends mostly didn’t use Twitter to share happy news and tell me how things were going. They used Twitter for bumper sticker flame wars. These were not the thoughtful long essays on blogs of yesteryear. 140 characters is too short for that.

Here’s what happened with the 140 characters. You would start out having some kind of complicated thought. “Ya know, dogs are great and all? I love dogs! But sometimes they can be a little bit too friendly. They can get excited and jump on little kids and scare the bejesus out of them. They wag their tails so hard they knock things over. (PS not Huskies! Huskies are the cats of the dog world!)”

Ok, so now you try to post that on Twitter. And you edit and edit and you finally get it down to something that fits: “Dogs can be too friendly!”

All the nuance is lost. And this is where things go wrong. “@spolsky what about huskies? #dontforgethuskies”

Ten minutes later, “Boycott @stackoverflow. @spolsky proves again that tech bros hate huskies. #shame”

By the time you get off the plane in Africa you’re on the international pariah list and your @replies are full of people accusing you of throwing puppies out of moving cars for profit.

Yeah, I get it, this 140 character limitation was just a historical accident, and now it’s 280 characters anyway, and you can always make a Twitter Story, but the flame wars on Twitter emerged from the fact that we’ve taken a medium, text, which is already bad at conveying emotion and sentiment and high-bandwidth nuance, and made it even worse, and the net result is a lot of outrage and indignation.

The outrage and indignation, of course, are what makes it work. That’s what keeps you coming back. Oooh shade. Oooh flamewar. We rubberneckers can’t keep our eyes off of it. I don’t know what the original idea of Twitter was, but it succeeded because of natural selection. In a world where the tech industry was cranking out millions of dumb little social applications, this one happens to limit messages to 140 characters and that happens to create, unintentionally, a subtlety-free indignation machine, which is addictive as heck, so this is the one that survives and thrives and becomes a huge new engine of polarization and anger. It’s not a coincidence that we got a president who came to power through bumper-sticker slogans, outrageous false statements chosen to make people’s blood boil, and of course Twitter. This is all a part of a contagious disease that is spreading like crazy because we as a society have not figured out how to fight back yet.

But Twitter is small potatoes. Facebook is where the action is. Facebook quickly copied Twitter’s idea of the “feed” as a mechanism to keep you coming back compulsively. But whereas Twitter sort of stumbled upon addictiveness through the weird 140-character limit, Facebook mixed a new, super-potent active ingredient into their feed called Machine Learning. They basically said, “look, we are not going to show everybody every post,” and they used the new Midas-style power of machine learning and set it in the direction of getting people even more hyper-addicted to the feed. The only thing the ML algorithm was told to care about was addiction, or, as they called it, engagement. They had a big ol’ growth team that was trying different experiments and a raw algorithm that was deciding what to show everybody and the only thing it cared about was getting you to come back constantly.

Now, this algorithm, accidentally, learned something interesting—something that dog trainers have always known.

Dog trainers give dogs a treat when they get something right. When they say “come,” and the dog comes, he gets a treat. Woof. I can train any arbitrary dog to do that with some reliability. But here’s what happens. Once, just once, I forget to give the dog a treat. And then the dog thinks, well, heck this, I guess “come” doesn’t always mean “treat.” So the trained behavior goes away. It’s technically called extinction: the trained behavior goes extinct.

How do we prevent extinction? By only giving treats some of the time. So the dog learns something more subtle. When my master says come and I obey, I might get a treat. Sometimes I do, sometimes I don’t. That way, if I obey and don’t get the treat, I shouldn’t panic. I should still always come when he says come because that’s still the best way to get the most treats. Intermittent reinforcement works better.

This sounds like what Facebook was doing to me.

Rather than providing a constant stream of satisfying news and engagement with friends, Facebook’s algorithm had learned to give me a bunch of junk I didn’t need to hear, and only gave me intermittent rewards through the occasional useful nugget of information about friends. Once in a blue moon I would hear about a friend’s accomplishment or I would find out that someone I like is going to be in town. The rest of the time I would just get the kind of garbage newspaper clippings circulated by someone who had too much coffee and is misattributing the kick from the caffeine to something they just read online and now MUST share IMMEDIATELY with EVERYONE because this news story about something that happened to a baby bear is SOOOOO important to THE ENTIRE WORLD. And so 9 of out 10 things in my feed are complete garbage—last week’s newspaper lining the birdcage with the droppings already on it—but then once every two weeks I find out my niece is engaged or my best friend got a great new job or my oldest friend is in town and I should make plans to hang out. And now no matter how full the Facebook feed is of bird droppings I still have to keep going back.

Both Twitter and Facebook’s selfish algorithms, optimized solely for increasing the number of hours I spend on their services, are kind of destroying civil society at the same time. Researchers also discovered that the algorithms served to divide up the world into partisan groups. So even though I was following hundreds of people on social networks, I noticed that the political pieces which I saw were nevertheless directionally aligned with my own political beliefs. But to be honest they were much… shriller. Every day the Twitter told me about something that The Other Side did that was Outrageous and Awful (or, at least, this was reported), and everyone was screeching in sync and self-organizing in a lynch mob, and I would have to click LIKE or RETWEET just to feel like I had done something about it, but I hadn’t actually done anything about it. I had just slacktivated.

What is the lesson? The lesson here is that when you design software, you create the future.

If you’re designing software for a social network, the decision to limit message lengths, or the decision to use ML to maximize engagement, will have vast social impact which is often very hard to predict.

As software developers and designers, we have a responsibility to the world to think these things through carefully and design software that makes the world better, or, at least, no worse than it started out. And when our inventions spin out of control, we have a responsibility to understand why and to try to fix them.

This blog post has a surprise piece of good news. The good news is that Facebook suddenly realized what they had done, and today they announced a pretty major change of direction. They want the feed to leave people feeling “more connected and less lonely,” so they have actually decided to sacrifice “engagement.” Mark Zuckerberg posted, “By making these changes, I expect the time people spend on Facebook and some measures of engagement will go down. But I also expect the time you do spend on Facebook will be more valuable.” That’s amazing, but it’s amazing because it demonstrates that Facebook has finally grown up and joined the rest of us in understanding that software developers are designing the future.

Developers’ side projects

Pretty much 100% of developers working for other people end up signing some kind of “proprietary invention agreement,” but almost all of them misunderstand what’s going on with that agreement. Most developers think that the work they do at work belongs to their employer, but anything they work on at home or on their own time is theirs. This is wrong enough to be dangerous.

So let’s consider this question: if you’re a developer working for software company, does that company own what you do in your spare time?

Before I start: be careful before taking legal advice from the Internet. I see enough wrong information that you could get in trouble. Non-US readers should also be aware that the law and legal practice could be completely different in their country.

There are three pieces of information you would need to know to answer this question:

1. What state (or country) are you employed in?

There are state laws that vary from state to state which may even override specific contracts.

2. What does your contract with your employer say?

In the US, in general, courts are very lenient about letting people sign any kind of contract they want, but sometimes, state laws will specifically say “even if you sign such and such a contract, the law overrides.”

3. Are you a contractor or an employee? In the US there are two different ways you might be hired, and the law is different in each case.

But before I can even begin to explain these issues, we gotta break it down.

Imagine that you start a software company. You need a developer. So you hire Sarah from across the street and make a deal whereby you will pay her $20 per hour and she will write lines of code for your software product. She writes the code, you pay her the $20/hour, and all is well. Right?

Well… maybe. In the United States, if you hired Sarah as a contractor, she still owns the copyright on that work. That is kind of weird, because you might say, “Well, I paid her for it.” It sounds weird, but it is the default way copyright works. In fact, if you hire a photographer to take pictures for your wedding, you own the copies of the pictures that you get, but the photographer still owns the copyright and has the legal monopoly on making more copies of those pictures. Surprise! Same applies to code.

Every software company is going to want to own the copyright to the code that its employees write for them, so no software company can accept the “default” way the law works. That is why all software companies that are well-managed will require all developers, at the very least, to sign an agreement that says, at the very least, that

  • in exchange for receiving a salary,
  • the developer agrees to “assign” (give) the copyright to the company.

This agreement can happen in the employment contract or in a separate “Proprietary Invention Assignment” contract. The way it is often expressed is by using the legal phrase work for hire, which means “we have decided that the copyright will be owned by the company, not the employee.”

Now, we still haven’t said anything about spare time work yet. Suppose, now, you have a little game company. Instead of making software, you knock out three or four clever games every few months. You can’t invent all the games yourself. So you go out and hire a game designer to invent games. You are going to pay the game designer $6,000 a month to invent new games. Those games will be clever and novel. They are patentable. It is important to you, as a company, to own the patents on the games.

Your game designer works for a year and invents 7 games. At the end of the year, she sues you, claiming that she owns 4 of them, because those particular games were invented between 5pm and 9am, when she wasn’t on duty.

Ooops. That’s not what you meant. You wanted to pay her for all the games that she invents, and you recognize that the actual process of invention for which you are paying her may happen at any time… on weekdays, weekends, in the office, in the cubicle, at home, in the shower, climbing a mountain on vacation.

So before you hire this developer, you agree, “hey listen, I know that inventing happens all the time, and it’s impossible to prove whether you invented something while you were sitting in the chair I supplied in the cubicle I supplied or not. I don’t just want to buy your 9:00-5:00 inventions. I want them all, and I’m going to pay you a nice salary to get them all,” and she agrees to that, so now you want to sign something that says that all her inventions belong to the company for as long as she is employed by the company.

This is where we are by default. This is the standard employment contract for developers, inventors, and researchers.

Even if a company decided, “oh gosh, we don’t want to own the 5:00-9:00 inventions,” they would soon get into trouble. Why? Because they might try to take an investment, and the investor would say, “prove to me that you’re not going to get sued by some disgruntled ex-employee who claims to have invented the things that you’re selling.” The company wants to be able to pull out a list of all current and past employees, and show a contract from every single one of them assigning inventions to the company. This is expected as a part of due diligence in every single high tech financing, merger, and acquisition, so a software company that isn’t careful about getting these assignments is going to have trouble getting financed, or merging, or being acquired, and that ONE GUY from 1998 who didn’t sign the agreement is going to be a real jerk about signing it now, because he knows that he’s personally holding up a $350,000,000 acquisition and he can demand a lot of money to sign.

So… every software company tries to own everything that its employees do. (They don’t necessarily enforce it in cases of unrelated hobby projects, but on paper, they probably can.)

Software developers, as you can tell from this thread, found this situation to be upsetting. They always imagined that they should be able to sit in their own room at night on their own computer writing their own code for their own purposes and own the copyright and patents. So along came state legislators, in certain states (like California) but not others (not New York, for example). These state legislatures usually passed laws that said something like this:

Anything you do on your own time, with your own equipment, that is not related to your employer’s line of work is yours, even if the contract you signed says otherwise.

Because this is the law of California, this particular clause is built into the standard Nolo contract and most of the standard contracts that California law firms give their software company clients, so programmers all over the country might well have this in their contract even if their state doesn’t require it.

Let’s look at that closely.

On your own time. Easy to determine, I imagine.

With your own equipment. Trivial to determine.

Not related to your employer’s line of work. Um, wait. What’s the definition of related? If my employer is Google, they do everything. They made a goddamn HOT AIR BALLOON with an internet router in it once. Are hot air balloons related? Obviously search engines, mail, web apps, and advertising are related to Google’s line of work. Hmmm.

OK, what if my employer is a small company making software for the legal industry. Would software for the accounting industry be “related”?

I don’t know. It’s a big enough ambiguity that you could drive a truck through it. It’s probably going to depend on a judge or jury.

The judge (or jury) is likely to be friendly to the poor employee against Big Bad Google, but you can’t depend on it.

This ambiguity is meant to create enough of a chilling effect on the employee working in their spare time that for all intents and purposes it achieves the effect that the employer wants: the employee doesn’t bother doing any side projects that might turn into a business some day, and the employer gets a nice, refreshed employee coming to work in the morning after spending the previous evening watching TV.

So… to answer the question. There is unlikely to be substantial difference between the contracts that you sign at various companies in the US working as a developer or in the law that applies. All of them need to purchase your copyright and patents without having to prove that they were generated “on the clock,” so they will all try to do this, unless the company is being negligent and has not arranged for appropriate contracts to be in place, in which case, the company is probably being badly mismanaged and there’s another reason not to work there.

The only difference is in the stance of management as to how hard they want to enforce their rights under these contracts. This can vary from:

  • We love side projects. Have fun!
  • We don’t really like side projects. You should be thinking about things for us.
  • We love side projects. We love them so much we want to own them and sell them!
  • We are kinda indifferent. If you piss us off, we will look for ways to make you miserable. If you leave and start a competitive company or even a half-competitive company, we will use this contract to bring you to tears. BUT, if you don’t piss us off, and serve us loyally, we’ll look the other way when your iPhone app starts making $40,000 a month.

It may vary depending on whom you talk to, who is in power at any particular time, and whether or not you’re sleeping with the boss. You’re on your own, basically—the only way to gain independence is to be independent. Being an employee of a high tech company whose product is intellectual means that you have decided that you want to sell your intellectual output, and maybe that’s OK, and maybe it’s not, but it’s a free choice.

RIP CityDesk

Here’s a quick history of the technology behind Joel on Software.

Version one was on Manila, created by Dave Winer. Dave was the one who convinced me to blog, by blogging himself, and by creating what was, I think, the first public blogging platform at editthispage.com. My site was joel.editthispage.com and back in 1999 people thought it was pretty spiffy that you could get your own subdomain like that.

In order to use my own domain, I registered joelonsoftware.com and took an old IBM desktop computer (probably running Windows NT 4.0), shoved it in a closet, and ran my own copy of Manila. The first time Slashdot linked to me it melted down. We upgraded the memory from 256M to 512M and it recovered.

In those days all the cool kids wrote their own blogging platforms. I wrote CityDesk. In what turned out to be a monumentally wrong bet, I thought that people would want to blog on Windows, with all the slick WYSIWYG editing goodness that wasn’t yet available in early versions of HTML. CityDesk kept your entire website in a SQL database (Microsoft Jet, the backend of Access) and had a frontend like a word processor. Every time you needed to publish, it generated the entire site as a set of html pages, which it then uploaded to an ftp server for you. That worked “OK” for 10 pages. By the time this site was over 1000 pages, even on modern super speedy computers with flash drives, it took something like 5 minutes to publish.

Over the years the CityDesk code base (VB 6.0, another bad bet) stopped running on the latest versions of Windows. Nobody else cared but by that time I was using a custom version of CityDesk which only ran on Windows XP. So until recently, I had a virtual machine set up with Windows XP running in there, and a copy of CityDesk. That virtual machine runs on a modern Windows box which I don’t use for any other purpose, so it lives under a desk in a cave somewhere and I have to remote desktop into it. Lately, I haven’t been able to do that. I’m not sure why.

Doesn’t matter. Matt Mullenweg over at WordPress has been trying to get me to move Joel on Software over to WordPress for so long it’s not even funny. I finally gave in. An astonishingly talented group of people were collected who created the port you are looking at now. I owe a huge debt of gratitude to Chris HardieSarah SemarkValerie KalantyrskiMichelle LangstonDaniel RobertJames Tien, and
Steve Seear for weeks of hard work on creating this almost perfect port of 16 years of cruft, preserving over 1000 links with redirects, hand crafting html and css to preserve awful formatting, some of which was created before CSS was in use, and doing some monumental heroics to keep just about everything about the old site in its new WordPress home.

I also want to thank our host Pressable.

OK, I haven’t blogged too much since getting a puppy and “officially” retiring on the tenth anniversary of Joel on Software. I won’t have too much time to blog now, either, but now that we’re on WordPress, it’s a million times easier, so I’ll probably throw up some things here that I’ve written anyway, like internal documents from Fog Creek and Stack Overflow.

See you soon!

 

Anil Dash is the new CEO of Fog Creek Software

I have some huge news to share with you.

For the first time since Fog Creek Software was founded more than sixteen years ago, we have a new CEO, Anil Dash.

Who?

I’ve been friends with Anil since the earliest days of Fog Creek Software. He’s a pioneer of blogging (beat me to it by about five months), and has been a tech industry entrepreneur, activist, and writer for almost two decades.

You can read Anil’s full bio here. For those of you that want the top level bullet points:

  • Blogging pioneer
  • Helped start Six Apart, the company behind Moveable Type and TypePad
  • Founder of Expert Labs, ThinkUp, and MakerBase (which is joining Fog Creek)
  • Advisor and board member to a whole slew of companies and non-profits
  • Lives in New York City, with his wife Alaina Browne and their son Malcolm.

I’ve gotten to know Anil much better since he joined the Stack Overflow Board of Directors in 2011 and discovered that he’s a remarkable creative thinker and really, really understands developers, how the work developers do fits into society, and thus, how we can make technology more humane and ethical from our unique position of making things for software developers. There is no single person I would trust more to help Fog Creek figure out how to make something big, important, and valuable.

Fog Creek is a weird company here, with unique values that you don’t find in a lot of other companies. That’s why we’re so successful, and that’s why we love working here. Some of the weird stuff we do is non-negotiable. We would never dream of having just any competent person from outside the company come in, let alone give them the CEO role, if we weren’t convinced that they were 100% fanatical and excited about Fog Creek Software’s unique operating system. We’ve been friends with Anil for so long that we’re confident that the combination of his talents and worldview with our quirky operating system will be a stellar combination.

In short, we need Anil to help support us with ideas and leadership for HyperDev (now renamed Gomix) and any future products we come up with, and we need his soapbox and industry connections to continue to keep Fog Creek Software relevant. Thus I think the perfect position for him is as CEO of Fog Creek Software.

A typical startup is built around a single product, and some theory that people will pay money for that product. This theory eventually become false, and the company goes away. But Fog Creek was different. We were just a place where great people come together to build great things. People come here because of the other people that are here. And that makes it fundamentally much stronger and longer lasting. We build new products every year, some of which work, and some of which don’t; we can spin off other companies; the individuals who work here can change; but as long as we remain dedicated to being a place where great people come together to build great things we’re going to remain a highly respected and successful company for a long long time.

What are you doing, Joel?

I’m the full-time CEO of Stack Overflow, which just hit 300 employees and really takes all my time now.

Where’s Michael Pryor?

He’s the full-time CEO of Trello, which is about to hit 100 employees and takes all of his time.

So, what’s going on at Fog Creek?

Fog Creek is focused on two things:

  • Fog Creek’s developer tool, FogBugz, is still going strong. We have a dedicated development team continuing to work on it and are still regularly releasing new features and enhancements, especially in the area of agile development.
  • Fog Creek’s newest project, Gomix (formerly “HyperDev”) is relaunching. This is a developer playground for building full-stack web-apps fast.

Anil as CEO will be assisted by COO Jordan Harris, and Michael and I are still heavily involved but now at the board level.