Jeff Atwood on building Discourse, Stack Exchange, and Coding Horror
Interviewed by Christophe Limpalair on 07/08/2015
From building a very popular programming blog to building the Stack Exchange network and now Discourse, Jeff Atwood has changed millions of lives. Find out how he did it.
You have a knack for community building. How do you do it?
With StackOverflow, we set out with a problem statement. There was the site Experts Exchange and Joel Spolsky reached out to Jeff Atwood and said "Hey, we could have a site like this."
The strategy was to build a better alternative to something that already existed and had demand. They were trying to build a tool for the community that answered the question: "How can I ask a question and get an answer to programming questions, in a way that's community building?"
The same approach was used to build Discourse. There was a need for forum software, but all the options out there were terrible. Jeff wanted to offer a solution that was actually good and that people could build communities on and be proud of installing.
Jeff says that's the key. Think about a problem you're trying to solve.
The main takeaway I got from this question was this: Look at existing industries that have demand but no good solution. You'll know this if you've ever needed something and just couldn't find a good company/product.
A great example of this is what Elon Musk has been doing. With PayPal, the big banks were all doing the same thing and had a bunch of fees. Elon and others set out to create a radically simpler product. Same with Tesla Motors-- car companies are just doing the exact same thing over and over again (buy this car because it has an extra cup holder and gets 5 more miles to the gallon!).
Jeff Atwood did the same thing with StackOverflow and Discourse as a co-founder of both.
What problem were you setting out to solve with CodingHorror?
CodingHorror is a public research notebook and solved a similar problem that StackOverflow solved. Wait, what?
On StackOverflow and StackExchange, anyone can ask a question and answer it themselves. Have you ever gone to ask someone a question, and the process of asking that question actually helped you solve it? As soon as you started explaining the problem, bam, the answer popped in your head. That's, in part, what CodingHorror is to Jeff. Adding comments also takes this to another level, because you then get outside input on your solutions.
Jeff gives us the following scenario: Can you imagine going to Amazon.com to purchase a product without having user reviews? I can't. I always look at reviews before buying something. The comments on his blog were similar. It helped verify his thoughts and approach. Did he miss something? Is there a better way? You can be sure someone will point it out every chance they get ;).
This approach also gave way to ideas for StackOverflow. They wanted to have a voting system after seeing it succeed in bringing out top content on Digg, Reddit, and other sites.
In addition, they wanted work to be associated to people's names. This is a powerful concept. If you were not receiving any credit, you wouldn't have as strong a motivation to deliver good content. This also plays in with awards. By adding awards in StackOverflow, they taught users how the system works by rewarding the behavior they wanted to see.
Did you get initial traffic to StackOverflow with yours and Joel's existing influence?
Absolutely. Having a lot of traffic already always helps, but having all the traffic in the world won't help if you're product isn't any good.
So yes, the initial boost certainly helped, but the quality of questions and answers made the site keep growing. For example, their SEO ranking was very high early on because the content was such high quality.
This is why they were (and are) strict with rules on contributing. The thing with StackOverflow is that it's not about discussion. It's about great answers.
The focus on building a great tool that solves an essential problem was key to success and growth.
How did you get traffic to your blog when you weren't famous? Did you also just have great content?
There really wasn't a strategy. What mattered most at the beginning was consistency. It's not even so much about the quality at first (although that's still important), but even more so about consistently putting out content.
It's not about being great-- it's about being good on a regular basis.
Of course talent also plays an important role, but Jeff says that effort counts for a lot. The more you do something with consistent practice, the better you'll get at it.
You could have 10 years of experience or you can have 1 year of experience 10 times. The goal is to methodically work on improving. Set a schedule early on and stick to it. Adjust as you get more feedback and more experience.
Jeff does add that if you do this, you will definitely get better after a year. That doesn't mean you will be world-famous, but that shouldn't be the mindset. Focus on being better at whatever it is you're doing, and the rest will follow. It feels good to have skill. It's not about the people reading, it's about you-- doing it for you.
Other ways to achieve your goals
Look at the people you respect who are doing what you want to be doing and try to emulate them in some way. Look at what they're doing and how they're doing it and try to think "how can I achieve that?"
It also helps you find the path of where you are going. "If I was the best at this, what would that be like?"
When Jeff first started out, he looked at a lot of people who were doing things he admired. That's actually how he met Joel. He had a lot of respect for him.
Since Jeff had a lot of viewers at this point, he reached out to people he admired and said: "I have this big ball of energy and I don't know what to do with it!" That's essentially how Joel and Jeff connected and later decided to start StackOverflow.
Why do you recommend Code Complete so much?
In programming, people can be very dogmatic about what they think is right. Code Complete is not preachy in that way and instead cites a lot of data.
It uses the approach of: Here's what we think works, and here's the data to prove it, but without forcing it.
We know for a fact computers change quickly, but people don't. The book stresses on the fact that you should program for people and not machines. Programming is a human activity, and a big part of the outcome is determined by how you treat others in the project.
That's also a reason why premature optimization doesn't make sense. Even if shortening the name of a variable will mean faster execution time, it's such a tiny change that making it harder to read for humans is a false optimization.
Here's a quote from the author, Steve McConnell: "Code is read far more times than it's written. Favoring a technique that speeds write-time convenience at the expense of read-time convenience is a false economy."
And another by Martin Fowler: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Steve Yegge came out and said that your most important skill as a programmer is marketing whether you like it or not. Why? Because no matter what you produce, people have to find it. They have to understand it and use it. These are marketing jobs.
Jeff points out that most programmers [that he worked with at least] are so good at technical jobs that they don't need to get better at that. Focus on the other skills that will advance your career.
Think about programmers you admire. You usually don't admire them for their technical prowess. Sometimes you do, but it's usually all the other stuff that goes around that, that makes them who they are. The fact that they can talk, communicate, and convince people are usually what have made them succeed.
It was a stack Jeff knew really well. It's also very fast because it's compiled. On top of this, he just really liked the language. He says it has a great blend of advanced and simple features.
Did you run into any issues as a result of using .NET?
They ran into one or two framework bugs, but Microsoft was very responsive.
It's not a great tool chain for open source software, but for closed source it's great. Pages load very quickly. The home page loads in less than 140ms, for example.
They work with Ruby at Discourse and Jeff commented on how tough it is to get it to run anywhere near that short of a time.
Was running closed-source Microsoft software costly and harder to scale as a result?
The big cost in the Microsoft stack is SQL server. The licensing gets really expensive. Licensing for Windows server is not that expensive.
Would you still use your own hardware or move to cloud?
With open source software, you do end up using more hardware. Sometimes 10x more. But, the licensing costs are so high on the licensing side with closed source that it often times can be worth it.
Another thing to keep in mind is that having more hardware results in more machines and therefore the need for Sysadmins. This can add up to cost rather quickly. They didn't really anticipate this with Discourse and just recently hired a full-time Sysadmin to manage their 12 servers.
The question then becomes: big iron approach? Or multiple smaller services? They both have their own technical debt.
You left StackExchange when it was just growing. Take us back to that mindset and the decision.
By 2012, Jeff and his wife just had twins. Obviously, having twins is a big deal-- it's kind of like parallel programming.
He was getting burned out, and was already very happy with what they had achieved. With somewhere between 50-100 employees and lots of traffic, it was certainly a success for Jeff's first entrepreneurial venture. He wanted to take some time off, figure out what he wanted to do, and spend more time with his family.
During the time that he took a break, he realized that without a mission to accomplish every day when waking up, he just wasn't happy. He can't just wake up and be, he has to be on a mission.
What led you to Discourse?
People were going to him for advice on what to build for their products, and Jeff would tell them to ask their community of users because they would know best.
The problem is that they didn't have a platform to do this. The solutions out there were mediocre at best, and this eventually led to Discourse.
What technologies power Discourse?
Glimmer is also coming to Ember and will speed things up.
Why Ember.js over Angular?
Robin Ward, cofounder of Discourse, made the decision to use Ember. They really believe it's going to be a dominant framework in the future.
They are both growing rapidly and because of it, upgrading to the newest version of the framework is no trivial task. It takes a lot of work, but ends up being worth it in the long-run.
How do you handle everything with such a small team? (7 people)
Open Source makes it easy to have lots of contributors (450+). The project is not just these 7 people, it's a community.
Did you only choose RoR because your cofounder had so much experience with it? Why not .NET?
.NET is not a great choice for open source software. They've changed a lot of this recently, but historically you had to be on a Microsoft platform.
There's an amazing open source community with RoR, Python, and others. It just made more sense.
With the recent .NET open sourcing, would you change if you could?
While open sourcing .NET is a good trend and Jeff believes they should do that, it does not undo the 20+ years of closed source and they have catching up to do.
What kinds of issues have you avoided at Discourse from experience at SO/SE
They really went in a completely different direction. Whereas StackExchange is Q&A and closed source, Discourse is a forum and open source. The only major similarity is with people.
How will people find this? Will they understand it? Will they use it?
Writing code is actually a very small part of most projects. Understanding people's pain points and what will make the site successful takes up the majority of your time. For example, they had to figure out how to build a community and also how to monetize the site at StackExchange.
That's a big part of what Jeff learned from his experience at StackOverflow. Another thing he mentions really hit home with me-- you wake up every day and no one is telling you what to do. You have to figure it out yourself. He didn't learn how to become a better programmer, he learned how to prioritize on what actually matters at that specific time.
How do you figure out what actually matters?
A lot of it is trial and error. He has 3 things he needs to accomplish in a day. Forget the long todo lists, think about what three things you need to accomplish today and work on those.
I have the exact same approach. There is a calendar on my phone and next to my computer where I write down 3-4 tasks that must be accomplished that day. Most of the time it's 3 important tasks and a 4th that I can tackle if there's any time left over that day. This is incredibly efficient for me, because it gets things out of my head. Instead of trying to remember tasks, which takes mental energy, I completely forget about them and write them down. This clears out more mental focus and works great for me.
Since Jeff works with people, he says that important tasks will bubble to the top, and others will be forgotten. If there are important tasks that your coworkers or community needs you to accomplish, they won't let you forget it and it will get done.
How do you find this kind of team that keeps you on your toes?
They have a distributed team of workers who work remotely. When you have remote co-workers, it's incredibly important to hire people who can figure out what needs to be done without being told. In other words, they will figure out what they need to work on.
Can you self motivate? Can you self determine what you need to be working on? These are key points for remote workers. Once you hire these people, you need to back off and let them have the power to make their own decisions.
That's how a lot of decisions get made at Discourse. "You guys tell me how you think we should handle this."
Jeff went on to say that Joel Spolsky is very good at this. When he worked with Joel, he essentially gave him complete control. They had a weekly call which turned into the StackOverflow podcast, and Joel was a master at hiring smart people and getting out of their way.
Do you show people how you work at first, or just let them go about their own way?
They tend to hire people from the community. With the recent Sysadmin hire, however, it was a bit more challenging due to their infrastructure being hidden.
When Jeff hires programmers, he gives them a public facing project and tells them to implement a feature. With a Sysadmin, it's harder to do this. Instead, they gave potential Sysadmins hypotheticals about problems they actually had at Discourse and saw how they would handle it. Scaling problems, and things like that.
Discourse Open Source Software
Ember.js vs Angular.js from Discourse cofounder
StackExchange posts and podcast
Stack Exchange Engineering
What was Stack Overflow built with?
How did this interview help you?
If you learned anything from this interview, please thank our guest for their time.
Oh, and help your followers learn by clicking the Tweet button below :)