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.

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.

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 Hardie, Sarah Semark, Valerie Kalantyrski, Michelle Langston, Daniel Robert, James 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!

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

One more thing…
It’s been awhile since we launched a whole new product at Fog Creek Software (the last one was Trello, and that’s doing pretty well). Today we’re announcing the public beta of HyperDev, a developer playground for building full-stack web-apps fast.
HyperDev is going to be the fastest way to bang out code and get it running on the internet. We want to eliminate 100% of the complicated administrative details around getting code up and running on a website. The best way to explain that is with a little tour.
Step one. You go to hyperdev.com.
Boom. Your new website is already running. You have your own private virtual machine (well, really it’s a container but you don’t have to care about that or know what that means) running on the internet at its own, custom URL which you can already give people and they can already go to it and see the simple code we started you out with.
All that happened just because you went to hyperdev.com.
Notice what you DIDN’T do.
* You didn’t make an account.
* You didn’t use Git. Or any version control, really.
* You didn’t deal with name servers.
* You didn’t sign up with a hosting provider.
* You didn’t provision a server.
* You didn’t install an operating system or a LAMP stack or Node or operating systems or anything.
* You didn’t configure the server.
* You didn’t figure out how to integrate and deploy your code.
You just went to hyperdev.com. Try it now!
What do you see in your browser?
Well, you’re seeing a basic IDE. There’s a little button that says SHOW and when you click on that, another browser window opens up showing you your website as it appears to the world. Notice that we invented a unique name for you.
Over there in the IDE, in the bottom left, you see some client side files. One of them is called index.html. You know what to do, right? Click on index.html and make a couple of changes to the text.
Now here’s something that is already a little bit magic… As you type changes into the IDE, without saving, those changes are deploying to your new web server and we’re refreshing the web browser for you, so those changes are appearing almost instantly, both in your browser and for anyone else on the internet visiting your URL.
Again, notice what you DIDN’T do:
* You didn’t hit a “save” button.
* You didn’t commit to Git.
* You didn’t push.
* You didn’t run a deployment script.
* You didn’t restart the web server.
* You didn’t refresh the page on your web browser.
You just typed some changes and BOOM they appeared.
OK, so far so good. That’s a little bit like jsFiddle or Stack Overflow snippets, right? NBD.
But let’s look around the IDE some more. In the top left, you see some server side files. These are actual code that actually runs on the actual (virtual) server that we’re running for you. It’s running node. If you go into the server.js file you see a bunch of JavaScript. Now change something there, and watch your window over on the right.
Magic again… the changes you are making to the server-side Javascript code are already deployed and they’re already showing up live in the web browser you’re pointing at your URL.
Literally every change you make is instantly saved, uploaded to the server, the server is restarted with the new code, and your browser is refreshed, all within half a second. So now your server-side code changes are instantly deployed, and once again, notice that you didn’t:
* Save
* Do Git incantations
* Deploy
* Buy and configure a continuous integration solution
* Restart anything
* Send any SIGHUPs
You just changed the code and it was already reflected on the live server.
Now you’re starting to get the idea of HyperDev. It’s just a SUPER FAST way to get running code up on the internet without dealing with any administrative headaches that are not related to your code.
Ok, now I think I know the next question you’re going to ask me.
“Wait a minute,” you’re going to ask. “If I’m not using Git, is this a single-developer solution?”
No. There’s an Invite button in the top left. You can use that to get a link that you give your friends. When they go to that link, they’ll be editing, live, with you, in the same documents. It’s a magical kind of team programming where everything shows up instantly, like Trello, or Google Docs. It is a magical thing to collaborate with a team of two or three or four people banging away on different parts of the code at the same time without a source control system. It’s remarkably productive; you can dive in and help each other or you can each work on different parts of the code.
“This doesn’t make sense. How is the code not permanently broken? You can’t just sync all our changes continuously!”
You’d be surprised just how well it does work, for most small teams and most simple programming projects. Listen, this is not the future of all software development. Professional software development teams will continue to use professional, robust tools like Git and that’s great. But it’s surprising how just having continuous merging and reliable Undo solves the “version control” problem for all kinds of simple coding problems. And it really does create an insanely addictive form of collaboration that supercharges your team productivity.
“What if I literally type ‘DELETE * FROM USERS’ on my way to typing ‘WHERE id=9283’, do I lose all my user data?”
Erm… yes. Don’t do that. This doesn’t come up that often, to be honest, and we’re going to add the world’s simplest “branch” feature so that optionally you can have a “dev” and “live” branch, but for now, yeah, you’d be surprised at how well this works in practice even though in theory it sounds terrifying.
“Does it have to be JavaScript?”
Right now the server we gave you is running Node so today it has to be JavaScript. We’ll add other languages soon.
“What can I do with my server?”
Anything you can do in Node. You can add any package you want just by editing package.json. So literally any working JavaScript you want to cut and paste from Stack Overflow is going to work fine.
“Is my server always up?”
If you don’t use it for a while, we’ll put your server to sleep, but it will never take more than a few seconds to restart. But yes for all intents and purposes, you can treat it like a reasonably reliably, 24/7 web server. This is still a beta so don’t ask me how many 9’s. You can have all the 8’s you want.
“Why would I trust my website to you? What if you go out of business?”
There’s nothing special about the container we gave you; it’s a generic VM running Node. There’s nothing special about the way we told you to write code; we do not give you special frameworks or libraries that will lock you in. Download your source code and host it anywhere and you’re back in business.
“How are you going to make money off of this?”
Aaaaaah! why do you care!
But seriously, the current plan is to have a free version for public / open source code you don’t mind sharing with the world. If you want private code, much like private repos, there will eventually be paid plans, and we’ll have corporate and enterprise versions. For now it’s all just a beta so don’t worry too much about that!
“What is the point of this Joel?”
As developers we have fantastic sets of amazing tools for building, creating, managing, testing, and deploying our source code. They’re powerful and can do anything you might need. But they’re usually too complex and too complicated for very simple projects. Useful little bits of code never get written because you dread the administration of setting up a new dev environment, source code repo, and server. New programmers and students are overwhelmed by the complexity of distributed version control when they’re still learning to write a while loop. Apps that might solve real problems never get written because of the friction of getting started.
Our theory here is that HyperDev can remove all the barriers to getting started and building useful things, and more great things will get built.
“What now?”
Really? Just go to HyperDev and start playing!

Today Stack Exchange is pleased to announce that we have raised $40 million, mostly from Andreessen Horowitz.
Everybody wants to know what we’re going to do with all that money. First of all, of course we’re going to gold-plate the Aeron chairs in the office. Then we’re going to upgrade the game room, and we’re already sending lox platters to our highest-rep users.
But I’ll get into that in a minute. First, let me catch everyone up on what’s happening at Stack Exchange.
In 2008, Jeff Atwood and I set out to fix a problem for programmers. At the time, getting answers to programming questions online was super annoying. The answers that we needed were hidden behind paywalls, or buried in thousands of pages of stale forums.
So we built Stack Overflow with a single-minded, compulsive, fanatical obsession with serving programmers with a better Q&A site.
Everything about how Stack Overflow works today was designed to make programmers’ jobs easier. We let members vote up answers, so we can show you the best answer first. We don’t allow opinionated questions, because they descend into flame wars that don’t help people who need an answer right now. We have scrupulously avoided any commercialization of our editorial content, because we want to have a site that programmers can trust.
Heck, we don’t even allow animated ads, even though they are totally standard on every other site on the Internet, because it would be disrespectful to programmers to strain their delicate eyes with a dancing monkey, and we can’t serve them 100% if we are distracting them with a monkey. That would only be serving them 98%. And we’re OBSESSED, so 98% is like, we might as well close this all down and go drive taxis in Las Vegas.
Anyway, it worked! Entirely thanks to you. An insane number of developers stepped up to pass on their knowledge and help others. Stack Overflow quickly grew into the largest, most trusted repository of programming knowledge in the world.
Quickly, Jeff and I discovered that serving programmers required more than just code-related questions, so we built Server Fault and Super User. And when that still didn’t satisfy your needs, we set up Stack Exchange so the community could create sites on new topics. Now when a programmer has to set up a server, or a PC, or a database, or Ubuntu, or an iPhone, they have a place to go to ask those questions that are full of the people who can actually help them do it.
But you know how programmers are. They “have babies.” Or “take pictures of babies.” So our users started building Stack Exchange sites on unrelated topics, like parenting and photography, because the programmers we were serving expected—nay, demanded!—a place as awesome as Stack Overflow to ask about baby feeding schedules and f-stops and whatnot.
And we did such a good job of serving programmers that a few smart non-programmers looked at us and said, “Behold! I want that!” and we thought, hey! What works for developers should work for a lot of other people, too, as long as they’re willing to think like developers, which is the best way to think. So, we decided that anybody who wants to get with the program is welcome to join in our plan. And these sites serve their own communities of, you know, bicycle mechanics, or what have you, and make the world safer for the Programmer Way Of Thinking and thus serve programmers by serving bicycle mechanics.
In the five years since then, our users have built 133 communities. Stack Overflow is still the biggest. It reminds me of those medieval maps of the ancient world. The kind that shows a big bustling city (Jerusalem) smack dab in the middle, with a few smaller settlements around the periphery. (Please imagine Gregorian chamber music).
View of JerusalemStack Overflow is the big city in the middle. Because the programmer-city worked so well, people wanted to ask questions about other subjects, so we let them build other Q&A villages in the catchment area of the programmer-city. Some of these Q&A villages became cities of their own. The mathcities barely even have any programmers and they speak their own weird language. They are math-Jerusalem. They makes us very proud. Even though they don’t directly serve programmers, we love them and they bring a little tear to our eyes, like the other little villages, and they’re certainly making the Internet—and the world—better, so we’re devoted to them.
One of these days some of those villages will be big cities, so we’re committed to keeping them clean, and pulling the weeds, and helping them grow.
But let’s go back to programmer Jerusalem, which—as you might expect—is full of devs milling about, building the ENTIRE FUTURE of the HUMAN RACE, because, after all, software is eating the world and writing software is just writing a script for how the future will play out.
So given the importance of software and programmers, you might think they all had wonderful, satisfying jobs that they love.
But sadly, we saw that was not universal. Programmers often have crappy jobs, and their bosses often poke them with sharp sticks. They are underpaid, and they aren’t learning things, and they are sometimes overqualified, and sometimes underqualified. So we decided we could actually make all the programmers happier if we could move them into better jobs.
That’s why we built Stack Overflow Careers. This was the first site that was built for developers, not recruiters. We banned the scourge of contingency recruiters (even if they have big bank accounts and are just LINING UP at the Zion Gate trying to get into our city to feed on programmer meat, but, to hell with them). We are SERVING PROGRAMMERS, not spammers. Bye Felicia.
WHICH BRINGS US TO 2015.
The sites are still growing like crazy. By our measurements, the Stack Exchange network is already in the top 50 of all US websites, ranked by number of unique visitors, with traffic still growing at 25% annually. The company itself has passed 200 employees worldwide, with big plush offices in Denver, New York, and London, and dozens of amazing people who work from the comfort of their own homes. (By the way, if 200 people seems like a lot, keep in mind that more than half of them are working on Stack Overflow Careers).
We could just slow down our insane hiring pace and get profitable right now, but it would mean foregoing some of the investments that let us help more developers. To be honest, we literally can’t keep up with the features we want to build for our users. The code is not done yet—we’re dedicating a lot of resources to the core Q&A engine. This year we’ll work on improving the experience for both new users and highly experienced users.
And let’s not forget Stack Overflow Careers. I believe it is, bar-none, the single best job board for developer candidates, which should automatically make it the best place for employers to find developer talent. There’s a LOT more to be done to serve developers here and we’re just getting warmed up.
So that’s why we took this new investment of $40m.
We’re ecstatic to have Andreessen Horowitz on board. The partners there believe in our idea of programmers taking over (it was Marc Andreessen who coined the phrase “Software is eating the world”). Chris Dixon has been a personal investor in the company since the beginning and has always known we’d be the obvious winner in the Q&A category, and will be joining our board of directors as an observer.
This is not the first time we’ve raised money; we’re proud to have previously taken investments from Union Square Ventures, Index Ventures, Spark Capital, and Bezos Expeditions. We only take outside money when we are 100% confident that the investors share our philosophy completely and after our lawyers have done a ruthless (sorry, investors) job of maintaining control so that it is literally impossible for anyone to mess up our vision of fanatically serving the people who use our site, and continuing to make the Internet a better place to get expert answers to your questions.
For those of you who have been with us since the early days of Our Incredible Journey, thank you. For those of you who are new, welcome. And if you want to learn more, check out our hott new “about” page. Or ask!

Hello? is this thing on?
I’m not sure if I even know how to operate this “blog” device any more. It’s been a year since my last post. I’m retired from blogging, remember?
Want to hear something funny? The only way I can post blog posts is by remote-desktopping into a carefully preserved Windows 7 machine which we keep in a server closet running a bizarrely messed-up old copy of CityDesk which I somehow hacked together and which only runs on that particular machine. The shame!
I do need to fill you in on some exciting_ Trello News, _though. As you no doubt know, Trello is the amazing visual project management system we developed at Fog Creek.
Let me catch you up. As legend has it, back in yonder days, early twenty-oh-eleven, we launched a modest little initiative at Fog Creek to try to come up with new product ideas. We peeled off eight developers. The idea was that they would break into four teams. Two people each. Each team would work for a few months building a prototype or MVP for some product idea. Hopefully, at least one of those ideas would turn into something people wanted.
One of those teams started working on the concept that became Trello. The idea seemed so good that we doubled that team to four developers. The more we played around with it, the better we liked it. Within nine months, it was starting to look good enough to go public with, so we launched Trello at TechCrunch Disrupt to great acclaim and immediately got our first batch of users.
Over the next three years, Trello showed some real traction. The team grew to about 18 people, almost all in engineering. We did iPhone, iPad, Android, and Web versions. And Kindle. Oh and Android Wear. The user base grew steadily to 4.6 million people.
Zowie.
Here are some things that surprised me:
* We’ve successfully made a non-developer product that actually appeals to civilians. We tried to avoid the software developer niche this time, and it worked. I think that’s because Trello is _visual._ The board / card metaphor makes every board instantly understandable, which seems to attract all types of users who traditionally had never found online project management to be useful or worth doing.
* It spreads like crazy. It’s a gas that expands to fill all available space. Somebody finds out about Trello from their reading group and adopts it at work; pretty soon their whole company has hundreds of Trello boards for everything from high level road maps to a list of snacks that need to be bought for the break room.
* People love it. We regularly monitor Twitter for mentions of Trello and the amount of positive sentiment out there is awe-inspiring.
We launched something called Trello Business Class, which, for a small fee, provides all kinds of advanced administration features so that the larger organizations using Trello can manage it better, and Hey Presto, Trello was making money!
Taco got big, tooIn the meantime, we started getting calls from investors. “Can we invest in Trello?” they asked. They were starting to notice that whenever they looked around their portfolio companies all they saw was Trello boards everywhere.
We didn’t really need the money; Fog Creek is profitable and could afford to fund Trello development to profitability. And when we told the investors that they could take a minority, non-controlling stake in Fog Creek, we had to start explaining about our culture and our developer tools and our profit sharing plans and our free lunches and private offices and whatnot, and they got confused and said, “hmm, why don’t you keep all that, we just want to invest in Trello.”
Now, we didn’t _need_ the money, but we certainly _like_ money. We had a bunch of ideas for ways we could make Trello grow faster and do all kinds of astonishing new features and hire sales and marketing teams to work on Trello Business Class. We would have gotten around to all that _eventually_, but not as quickly as we could with a bit of folding money.
Which lead to this fairly complicated plan. We spun out Trello into its own company, Trello Inc., and allowed outside investors to buy a minority stake in that. So now, Trello and Fog Creek are officially separate companies. Trello has a bunch of money in the bank to operate independently. Fog Creek will continue to build FogBugz and Kiln and continue to develop new products every once in a while. Michael Pryor, who co-founded Fog Creek with me in 2000, will be CEO of Trello.
So, yeah. This is the point at which old-time readers of this blog point out that the interest of VCs is not always aligned with the interest of founders, and VCs often screw up the companies they invest in.
That’s mostly true, but not universal. There are smart, founder-friendly VCs out there. And with Trello (and Stack Overflow, for that matter), we didn’t take any outside investment until we already had traction and revenue, so we could choose the investors that we thought were the most entrepreneur-friendly, and we kept control of the company.
In the case of Trello, we had so much interest from investors that we were even able to limit ourselves to investors who were already investors in Stack Exchange and still get the price and terms we wanted. The advantage of this is that we know them, they know us, and they’re aligned enough not to fret about any conflicts of interest which might arise between Stack Exchange and Trello because they have big stakes in both.
Both Index Ventures and Spark Capital will co-lead the investment in Trello, with Bijan Sabet from Spark joining our board. Bijan was an early investor in Twitter, Tumblr, and Foursquare which says a lot about the size of our ambitions for Trello. The other two members of the board are Michael and me.
Even though Fog Creek, Trello, and Stack Exchange are now three separate companies, they are all running basically the same operating system, based on the original microprocessor architecture known as “making a company where the best developers want to work,” or, in simpler terms, treating people well.
This operating system applies both to the physical layer (beautiful daylit private offices, allowing remote work, catered lunches, height-adjustable desks and Aeron chairs, and top-tier coffee), the application layer (health insurance where everything is paid for, liberal vacations, family-friendly policies, reasonable work hours), the presentation layer (clean and pragmatic programming practices, pushing decisions down to the team, hiring smart people and letting them get things done, and a commitment to inclusion and professional development), and mostly, the human layer, where no matter what we do, it’s guided first and foremost by obsession over being fair, humane, kind, and treating each other like family. (Did I tell you I got married?)
So, yeah, there are three companies here, with different products, but every company has a La Marzocco Linea espresso machine in every office, and every company gives you $500 when you or your partner has a baby to get food delivered, and when we’re trying to figure out how to manage people, our number one consideration is how to do so fairly and compassionately.
That architecture is all the stuff I spent ten years ranting on this blog about, but y’all don’t listen, so I’m just going to have to build company after company that runs my own wacky operating system, and eventually you’ll catch on. It’s OK to put people first. You don’t have to be a psychopath or work people to death or create heaps of messy code or work in noisy open offices.
Anyway, that’s the news from our neck of the woods. If the mission of Trello sounds exciting we’ll be hiring a bunch of people soon so please apply!

There are a lot of people complaining about lousy software patents these days. I say, stop complaining, and start killing them. It took me about fifteen minutes to stop a crappy Microsoft patent from being approved. Got fifteen minutes? You can do it too.
In a minute, I’ll tell you that story. But first, a little background.
Software developers don’t actually _invent_ very much. The number of actually novel, non-obvious _inventions_ in the software industry that _may_be, in _some_ universe, deserve a government-granted monopoly is, perhaps, two.
The other 40,000-odd software patents issued every year are mostly garbage that any working programmer could “invent” three times before breakfast. Most issued software patents aren’t “inventions” as most people understand that word. They’re just things that any first-year student learning Java should be able to do as a homework assignment in two hours.
Nevertheless, a lot of companies large and small have figured out that patents are worth money, so they try to file as many as they possibly can. They figure they can generate a big pile of patents as an inexpensive byproduct of the R&D work they’re doing anyway, just by sending some lawyers around the halls to ask programmers what they’re working on, and then attempting to patent everything. Almost everything they find is either obvious or has been done before, so it shouldn’t be patentable, but they use some sneaky tricks to get these things through the patent office.
The first technique is to try to make the language of the patent as confusing and obfuscated as possible. That actually makes it harder for a patent examiner to identify prior art or evaluate if the invention is obvious.
A bonus side effect of writing an incomprehensible patent is that it works better as an infringement trap. Many patent owners, especially the troll types, don’t really want you to _avoid_ their patent. Often they actually want you to _infringe_ their patent, and then build a big business that relies on that infringement, and _only then_ do they want you to _find out_ about the patent, so you are in the worst possible legal position and can be extorted successfully. The harder the patent is to read, the more likely it will be inadvertently infringed.
The second technique to getting bad software patents issued is to use a thesaurus. Often, software patent applicants make up new terms to describe things with perfectly good, existing names. A lot of examiners will search for prior art using, well, search tools. They have to; no single patent examiner can possibly be aware of more than (rounding to nearest whole number) 0% of the prior art which might have invalidated the application.
Since patent examiners rely so much on keyword searches, when you submit your application, if you can change some of the keywords in your patent to be different than the words used everywhere else, you might get your patent through even when there’s blatant prior art, because by using weird, made-up words for things, you’ve made that prior art harder to find.
Now on to the third technique. Have you ever seen a patent application that appears ridiculously broad? (“Good lord, they’re trying to patent CARS!”). Here’s why. The applicant is deliberately overreaching, that is, striving to get the broadest possible patent knowing that the worst thing that can happen is that the patent examiner whittles their claims down to what they were entitled to patent anyway.
Let me illustrate that as simply as I can. At the heart of a patent is a list of claims: the things you allege to have invented that you will get a monopoly on if your patent is accepted.
An example might help. Imagine a simple application with these three claims:
1. A method of transportation
2. The method of transportation in claim 1, wherein there is an engine connected to wheels
3. The method of transportation in claim 2, wherein the engine runs on water
Notice that claim 2 mentions claim 1, and narrows it… in other words, it claims a strict subset of things from claim 1.
Now, suppose you invented the water-powered car. When you submit your patent, you might submit it this way even knowing that there’s prior art for “methods of transportation” and you can’t really claim all of them as your invention. The theory is that (a) hey, you might get lucky! and (b) even if you don’t get lucky and the first claim is rejected, the narrower claims will still stand.
What you’re seeing is just a long shot lottery ticket, and you have to look deep into the narrower claims to see what they really expect to get. And you never know, the patent office might be asleep at the wheel and BOOM you get to extort everyone who makes, sells, buys, or rides transportation.
So anyway, a lot of crappy software patents get issued and the more that get issued, the worse it is for software developers.
The patent office got a little bit of heat about this. The America Invents Act changed the law to allow the public to submit examples of prior art while a patent application is being examined. And that’s why the USPTO asked us to set up Ask Patents, a Stack Exchange site where software developers like you can submit examples of prior art to stop crappy software patents even before they’re issued.
Sounds hard, right?
At first I honestly thought it was going to be hard. Would we even be able to find vulnerable applications? The funny thing is that when I looked at a bunch of software patent applications at random I came to realize that they were _all_ bad, which makes our job much easier.
Take patent application US 20130063492 A1, submitted by Microsoft. An Ask Patent user submitted this call for prior art on March 26th.
I tried to find prior art for this just to see how hard it was. First I read the application. Well, to be honest, I kind of glanced at the application. In fact I skipped the abstract and the description and went straight to the claims. Dan Shapiro has great blog post called How to Read a Patent in 60 Seconds which taught me how to do this.
This patent was, typically, obfuscated, and it used terms like “pixel density” for something that every other programmer in the world would call “resolution,” either accidentally (because Microsoft’s lawyers were not programmers), or, more likely, because the obfuscation makes it that much harder to search.
Without reading too deeply, I realized that this patent is basically trying to say “Sometimes you have a picture that you want to scale to different resolutions. When this happens, you might want to have multiple versions of the image available at different resolutions, so you can pick the one that’s closest and scale that.”
This didn’t seem novel to me. I was pretty sure that the Win32 API already had a feature to do something like that. I remembered that it was common to provide multiple icons at different resolutions and in fact I was pretty sure that the operating system could pick one based on the resolution of the display. So I spent about a minute with Google and eventually (_bing!_) found this interesting document entitled Writing DPI-Aware Win32 Applications [PDF] written by Ryan Haveson and Ken Sykes at, what a coincidence, Microsoft.
And it was written in 2008, while Microsoft’s new patent application was trying to claim that this “invention” was “invented” in 2011. Boom. Prior art found, and deployed.
Total time elapsed, maybe 10 minutes. One of the participants on Ask Patents pointed out that the patent application referred to something called “scaling sets.” I wasn’t sure what that was supposed to mean but I found a specific part of the older Microsoft document that demonstrated this “invention” without using the same word, so I edited my answer a bit to point it out. Here’s my complete answer on AskPatents.
Mysteriously, whoever it was that posted the request for prior art checked the _Accepted_ button on Stack Exchange. We thought this might be the patent examiner, but it was posted with a generic username.
At that point I promptly forgot about it, until May 21 (two months later), when I got this email from Micah Siegel (Micah is our full-time patent expert):

The USPTO rejected Microsofts Resizing Imaging Patent!The examiner referred specifically to Prior Art cited in Joels answer ("Haveson et al").Here is the actual document rejecting the patent. It is a clean sweep starting on page 4 and throughout, basically citing rejecting the application as obvious in view of Haveson.

Micah showed me a document from the USPTO confirming that they had rejected the patent application, and the rejection relied very heavily on the document I found. This was, in fact, the first “confirmed kill” of Ask Patents, and it was really surprisingly easy. I didn’t have to do the hard work of studying everything in the patent application and carefully proving that it was all prior art: the examiner did that for me. (It’s a pleasure to read him demolish the patent in question, all twenty claims, if that kind of schadenfreude amuses you).

(If you want to see the rejection, go to Public Pair and search for publication number US 20130063492 A1. Click on _Image File Wrapper_, and look at the non-final rejection of 4-11-2013. Microsoft is, needless to say, appealing the decision, so this crappy patent may re-surface.) UPDATE OCTOBER 2013: THE PATENT RECEIVED A FINAL REJECTION FROM THE USPTO!

There is, though, an interesting lesson here. Software patent applications are of uniformly poor quality. They are remarkably easy to find prior art for. Ask Patents can be used to block them with very little work. And this kind of individual destruction of one software patent application at a time might start to make a dent in the mountain of bad patents getting granted.
My dream is that when big companies hear about how friggin’ easy it is to block a patent application, they’ll use Ask Patents to start messing with their competitors. How cool would it be if Apple, Samsung, Oracle and Google got into a Mexican Standoff on Ask Patents? If each of those companies had three or four engineers dedicating a few hours every day to picking off their competitors’ applications, the number of granted patents to those companies would grind to a halt. Wouldn’t that be something!
Got 15 minutes? Go to Ask Patents right now, and see if one of these RFPAs covers a topic you know something about, and post any examples you can find. They’re hidden in plain view; most of the prior art you need for software patents can be found on Google. Happy hunting!