I am Jeff Atwood (@codinghorror), co-founder of Stack Overflow and Discourse. Ask me anything! 4/8 @ Noon PST

So true @codinghorror. People surely seem to prefer hot takes on social media over long-form blogging. Fun fact though: long-form posts perform a lot better on @hackernoon than shorter ones. We will strive to forever be a place for deep tech expertise rather than hottest news.

1 Like

I think amplification of words online is maybe part of the current problem, not the solution. White supremacy, for example, shouldn’t be amplified, nor should hatemongers like Alex Jones.

Freedom of Speech ≠ Freedom of Reach

There’s been excellent progress in this area over the last couple years from the big players like Twitter and Facebook so I’m encouraged we can continue to improve here.


Hi Jeff,

first of all, thank you for your work for the greater good of the internet communities. Sharing knowledge and laughs would not be as easy, nor as fun without the work you have done.

As for my question, I am wondering if you have some tips on how to grow an evening side-project into a viable business one would be able to live off. I’m not aiming for the unicorn buyout here, just a paycheck. The business centres around collecting data from companies regarding municipal reporting.



For Stack Overflow the big marketing push was Joel Spolsky and I being mini-famous within the programming niche, so we effectively cheated there.

We advise Discourse communities all the time on “how do I get famous” – there’s no getting around the central requirement of regularly creating great, interesting content that people enjoy. I’ve summarized some of my best advice at

I guess my main advice is to live in your own creation alongside your users, and eat your own dogfood. Try to feel your customers pain by … being the customer!


Honestly the best thing here is for people to write about the problems and publicize them widely. It works. The squeaky wheel gets the grease, especially if they have the higher moral ground of protecting underrepresented groups.

One of the central problems is this:

The problem is that Twitter and Facebook aim to be discussion platforms for “everyone”, where every person, no matter how hateful and crazy they may be, gets a turn on the microphone. They get to be heard.

Being able to close your community door on problematic members, rather than insisting “everyone” gets a seat at the table, is a critical first step. Everything else follows from that.


Well, you can’t go wrong with Cthulhu :rofl:


4421 upvotes currently!


Hello Jeff. Thank you for this AMA. I would like to ask that what do you think about the communication skills of software developers’ as a founder of stackoverflow and discourse? What’s the weaknesses of developers? What do you think? What would you suggest us?


I can’t say enough great things about what Courtand is doing at indiehackers.com – they have a wealth of amazing resources on this exact topic. We even wrote up what we did at Discourse in some detail there



Courtland is so awesome. @David’s episode with him is one of David’s best podcast yet on the internet :slight_smile: Will be listening to yours now.

1 Like

I’m going to collapse this to “top one” if you don’t mind :stuck_out_tongue_winking_eye:

It’s no coincidence that both Stack Overflow and Discourse directly encourage people to become better communicators, for which they are rewarded with upvotes (SO) and likes (Discourse). This is intentional!

I call it The One Thing Every Software Engineer Should Know

OK, you’re a genius programmer who can code circles around everyone else. But you may never ship any of your code for reasons that you don’t control. That’s an illusion. You can control when, how, and where your code ships. You probably spent too much time building your code and not enough time as an advocate of your code. Did you explain to people what your code does, why it’s cool and important? Did you offer reasons why your code is going to make their lives better, at least in some small way? Did you make it easy for people to find and use your code?

My hope is that over time, participation on Stack Overflow and Discourse makes people better communicators – because being an effective communicator (and often, persuader) is central to getting what you want out of life.


Be interested in everything about the industry you’re working in, not just the coding aspects. Follow those interests wherever they go.

Beyond that, I recommend learning on the battlefield and software apprenticeship.

1 Like

The best way for people to benefit from open source is to participate! Find an open source project you enjoy or benefit from, and look at ways to contribute, starting with small stuff.

For example, at Discourse – which is of course 100% open source now and forever :wink: – we have this guidance:

Have you considered contributing to open source projects? We’ve hired several excellent folks from India who started out contributing to our Discourse open source code, per the ↑ above.


Yes definitely. One I have been apprehensive about is the full-on chat plugins for Discourse. I view Discourse as a system of paragraphs, and at least sentences, and chat is anathema to that. So bolting chat on to Discourse makes me very, very nervous.

To be fair we have evolved a few more chat-like features over time such as forms of presence (you can see if someone is currently replying to a topic if you’re idling at the bottom of a topic), native browser pop-up notifications (these even work on mobile for Android), and so on.

The other one that comes to mind is the invitation system (aka getting users to actually visit your Discourse), there was so much interest in sending invites that we ended up enhancing that system considerably over where it was at launch.



This is a tough one, because honestly (and perhaps controversially…) I believe you can ultimately accomplish more without coding, if you are guiding many other coders towards a collective goal.

I do know many lifelong coders, for example Bill Budge (who I met in person, what an honor) who currently writes lots of gnarly code for Google. So it is a valid path! I’d say keep honing those communication skills as you go, there’s nothing more fundamental. Let me quote my pal Joel Spolsky:

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


At Discourse we focus on making the moderator tools as easy and convenient as possible to use – and involve the community in moderation through our trust system. The longer and more frequently you participate the more we trust you, and you earn tools that help you organize and beautify the site you spend so much time on.

If there’s a trash can on every street corner, you do end up with a cleaner city! :wastebasket:


My main and biggest piece of advice is that it is critical to have a sense of humor at all times. :wink:

Have you read this epic Miguel de Icaza piece? I love it, and it gets better every time I re-read it:


The Recurse Center also has excellent essential “social rules”:


Oh gosh so many ways. A few key ones that I remember:

  • we instituted daily caps on reputation to encourage people to take a break from SO, and prevent “rich get richer” syndrome

  • we reduced the rep value of questions versus answers

  • we instituted the bounty system so you could slice off small bits of your rep and put them on questions or answers to encourage others

All this is documented on old Stack Overflow blog entries as well if you’re curious for the full history :wink:


I’m a big fan of the 10 commandments of egoless programming which is from a book as old as I am, and I’m pushing 50!

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

  5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

  9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

  10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.


OK! I think that’s a good place to end things.

Excellent questions everyone, give yourself a round of applause …


… because you deserve it! Thanks for this opportunity to answer your questions. I hope my answers were useful. :bowing_man:

p.s. If you liked Discourse, consider installing it yourself in 30 minutes or hacking on it with us!