Stack Overflow Was Never Designed for Beginners

Lex Fridman opens with a simple question for the co-founder of the world’s largest programming community: what motivates most programmers — fame, fortune, the process itself, or belonging? Jeff Atwood’s answer is short. It is puzzles. He describes hiding away and beating on a problem until it yields, almost by brute force. Computers are so fast that work which would take a human forever can be run millions of times until the answer appears.

The joy, he and Fridman agree, is the tinkering: the struggle that eventually produces something that actually works. Data itself is part of the fun. Most programmers’ naive shuffle has a serious flaw, which matters a great deal if an unsophisticated programmer writes a casino’s shuffle. The way to catch it is not cleverness. Run the shuffle a billion times and look at the buckets. A fair shuffle should produce an equal distribution of orientations; the naive method does not.

The Monty Hall problem is the same pattern. Three doors, information about one of them, and the correct move is always to switch — a result that “freaks people out.” Write a program that never switches and one that always does, compare the buckets, and you see the answer without having to be smart about the algorithm. You do not have to figure it out theoretically. You can brute-force it with data.

Asked what motivates him personally, Atwood admits he barely writes code anymore. At Discourse he does managerial work, which he once despised. Programmers, he says, think of managers as people who do nothing themselves. Then came a reversal: language is code. The ability to direct other people lets you get more done than you could alone. Writing code tells a machine what to do in a formal language; talking tells people what to do in a natural one. Same act, higher level of abstraction.

What makes a good leader? First, leading by example — being the thing you want others to be. That gets exhausting once you have children, because they watch you even in ways you have stopped seeing yourself. The hardest person on the planet to see is yourself. You judge others easily and are wildly biased about your own behavior, often much harder on yourself than anyone else would be. The practical question is whether you are behaving in a way that represents how you want other people to behave. A lot of leaders mess this up and send the opposite signal.

The second trait is working hard, which he does not mean as exhaustive hours. He means real passion for the problem, not necessarily for your solution. At Discourse the problem is how groups communicate without breaking down into “the howling of wolves” — trolling, incomplete sentences, people hurting each other instead of reaching consensus. People who are passionate about their solution get defensive when challenged. People passionate about the problem get excited when a better answer appears. You can tell the difference in a few days.

Fridman presses on self-awareness. If you cannot see yourself, how do you know which behaviors — including the things you fail to do — are sending the wrong signal? Atwood splits the answer. First, process feedback. Discourse has three co-founders who talk through decisions before making them. Systems where one leader has absolute law are dangerous for communities: that person will have a bad day, or something will happen to them, and the whole community goes with them. Multiple people sharing leadership, giving each other feedback, is the safer design.

Second is the little voice — gut, conscience, the angel and devil on your shoulder. Most people want to do the right thing and want others to think of them as good. A handful of sociopaths may not care, but attunement to how a decision makes you feel still matters. The catch, which Fridman notes, is that for programmers the devil is often too loud. Developers, especially introverts, are overly self-critical. Leadership still requires going through with decisions people may doubt.

The way through is to walk people through the decision-making. This is why blogging and communication matter: language is another kind of code, “the program by which I arrived at the conclusion.” Saying the decision is final is not satisfying. Saying we have been thinking about this, here is what happened, here are our goals, here are the options, and we think this one is best, produces a different reaction. Maybe I do not totally agree, but I can see where you are coming from. It is not an arbitrary verdict “delivered from a cloud of flames in the sky.” If you still disagree, it may simply be that your goals are different — not that anyone is a bad person.

Stack Overflow, Atwood says, is a very specific scalpel: structured, wiki-style Q&A for programmers. When he and Joel Spolsky started, they thought they were building discussions. They quickly realized they were doing Q&A, a narrow subset of human communication. The original wrong they wanted to right was Experts Exchange, a site with great data and a hideous experience that felt like a used-car salesman. Atwood treats it as a measure of success that a lot of people no longer remember the thing Stack Overflow replaced.

They did not invent a new form so much as stitch together things they had already seen working. Voting and reordering from Digg and Reddit. Wiki-style editing, including other people’s posts, so answers stayed up to date. Blogging’s sense of ownership: this is my voice, this is what I know. And a reputation system, because the key insight about programmer motivation was peer recognition. Money from a boss does not last. A peer saying this person really knows their stuff does. Atwood calls the result Frankensteinian, and he means it as a compliment.

Over time the page had little room for tangents. An answer should answer the question, clarify it, or offer an alternative, because in programming there are usually five to ten ways. Early on they saw questions with hundreds of answers and realized those were not questions. They were discussions they had allowed at the start and later banned: favorite programming food, funniest programming cartoon. The test he still likes is whether this is a real problem you face at work. Nobody sits down at their desk unable to continue because they do not know the funniest programming cartoon.

The second rule is about how learning works. Atwood distinguishes accidental learning — Reddit-style browsing, where you wander in and learn that tree frogs live three years, a fact he immediately admits he just made up — from intentional learning. Intentional learning starts with a problem and backfills the knowledge around it, even compiler theory, because you need that slice of theory to unblock yourself. Stack Overflow only serves the second kind. The rules got stricter over time, and people still complain. He had just written a tenth-anniversary post, roughly “What Stack Overflow Wanted to Be When It Grew Up,” that spent most of its length explaining why the site is hard on newcomers.

Reputation itself creates the tension. Programmers resent seeing someone collect 500 upvotes for a joke or a cartoon they did not even draw. That is not the same as a gnarly regular-expression answer that explains the behavior and how to avoid it next time. The second kind of reputation is earned. The first feels like taking credit for someone else’s work. Atwood empathizes: at some level the objectors are correct.

He later reaches for a programming analogy. Loose typing felt great in the Ruby community: skip the declarations, catch bugs with unit tests after the fact. Then Anders Hejlsberg, who built C# and whom Atwood calls one of the greatest minds in language design, bolted a strict type system onto JavaScript. Teams deploying TypeScript kept reporting that they found fifty latent bugs they did not know about. Strictness is not the goal, he insists, and it is not the same as being cruel, mean, or angry. Strictness produces better results. That is the claim people misunderstand about Stack Overflow.

The journey to Discourse starts with a limit. Stack Overflow only works on subjects with data, facts, and science, or a tome of knowledge you can point to. Answers have to be verifiable. The Stack Exchange engine lets the network propose new Q&A sites; poker and Lego were among the launches, and they did horribly. Those topics are too social. Poker players want to talk about cigars, cool decks, and how they would play a hand. Lego fans want to show a build and say look how awesome this is. That is not a question. Nobody is blocked by “what should I do when I have a straight flush.” It is an opportunity to hang out.

In late 2012 and early 2013 Atwood looked at forum software again and found it had not improved in four years, which made him angry. He loves communities of interest, and they had no decent tools. Startups would come to him with an idea; his first question was why they were asking him instead of their users. When they asked how, he says he started playing sad trombone, because every product for talking to customers was software he would be embarrassed to recommend. That is also where the most valuable input lives. On Stack Overflow he spent a lot of time on Meta Stack Overflow. Ninety percent of feedback is not actionable. Ten percent is gold. His favorite five percent is the idea he never saw coming.

The linchpin, for him, is the interest graph rather than Facebook’s relationship graph. Facebook’s idea of the world is the status update: a friend ate at a restaurant. Forums gather people who love the same specific thing — electric cars, Tesla’s approach, a founder’s style, a design ethic. He cites The Oatmeal’s Tesla comic as the origin myth of almost every interest community: someone goes extremely deep and shares it. He describes himself the same way, super passionate about a few things at a time, going deep for years rather than staying shallow on many. Forums unlock that. He does not want a world where everything belongs to Facebook. He wants communities that can own themselves, set their own rules, and not get kicked out of the Barnes & Noble because they did not buy enough books.

He is careful to compliment the thing he is arguing against. Facebook is very good at execution. Buying WhatsApp and Instagram were incredibly smart decisions. They give away VPN software on smartphones that feeds traffic data back so they can see what is getting popular. He still says Facebook has not much of a moral compass: Facebook cares about Facebook, not about you and your problems. Discourse is open source. You can take it, host it anywhere, and go deep on whatever you are into, including the way startups go deep on a specific problem and need to talk to the people who live it.

Fridman asks the practical question: how do you go from one person to a thousand? Luck, skill, timing, persistence, or the tools? Atwood starts with an audience of one. Someone he admires once described blogging as having something interesting to say, and an interesting way of saying it, and then doing that for about ten years. Interesting means not exactly what everyone else is saying. An interesting way of saying it means entertaining. Then comes ritual. Announce that you will blog three times a week, and stick to it, because until you have done that for several years you are not going anywhere. If you are passionate, it will not feel like work.

Coding Horror began in 2004, named after a sidebar illustration in Steve McConnell’s *Code Complete*, still Atwood’s number-one programming book. The icon meant danger in code, and it spoke to him because the key insight in programming is that you are your own worst enemy. Every time you write something, think about how you are going to screw yourself later. He wrote McConnell before launching the blog and asked permission to use the illustration; McConnell said yes, and has kept saying yes. Atwood was working at a pharmaceutical company where programming was not the core output, with nobody nearby to talk to, so he poured the obsession into the blog. He thinks of himself as an execution person, not an ideas person, which is one reason he likes community feedback: the crowd will blue-sky all day if you are willing to read for three hours to cherry-pick one good idea.

About 40,000 people were subscribing when he told Joel Spolsky he had a ball of energy and wanted to build something. Readers voted on the name Stack Overflow on the blog — naming, he notes, is one of the hardest problems in computer science — and almost all the early beta users came from his audience plus Joel’s. When people see that you are waiting on their feedback, not listening to everything, which is impossible, they follow. The best writing advice he has is to read the draft out loud, multiple times, until it sounds like you talking, only with slightly better phrasing because you had more time to think. Mine old programming books for evergreen concepts you can agree or disagree with. You do not have to pretend the idea is original. You need something durable to talk about.

In 2007 someone offered roughly $80,000 to $100,000 for the blog, a year’s salary in one check. He talked to people, hesitated, and refused, because it would no longer belong to him. The guideline he does like to give is that when you face a set of options, pick the one that is a little scarier — not jump-off-a-cliff scary, the one that makes you nervous. The safe choice usually means you are not pushing yourself. For him the scarier choice was to say no and see where the blog would go. If he had said yes, he thinks there probably would not have been a Stack Overflow.

Both companies started from a state of the world that made him upset. For Stack Overflow it was Experts Exchange. For Discourse it was embarrassing forum software that could not compete with Reddit, Twitter, or Facebook, software he would not be proud to put on his own site. He posted about forums, found a parody game called Forum Wars, and was contacted by Robin Ward in Toronto, who loved the same problem. Atwood’s reaction was that they were starting a company. The crucial seed is an idea you feel strongly about plus a co-founder who can check whether you are making a bad decision. Then research the field, with a bias he thinks most people skip: do not just stare at successes. Successes are boring. Look at the failures, because that is where people were experimenting, and they often failed for reasons that had little to do with the quality of the idea.

The Frankenstein design was not free. There is still a ton of tension in Stack Overflow, which is why people complain that questions get closed. Fridman, who has posted a lot on the site, notes the anxiety of asking. Atwood agrees the goal is a question that will help the long line of people behind you, which is a tough sell to someone who only cares about their own problem. He does not think the site can totally change how it works. He is still bitter that the ask page had not changed since 2011, because that is the moment a new user needs the most help. The good news, as of the conversation, is a more wizard-based ask flow, including help writing a title that is not just “I have a problem,” and an opt-in queue for special mentoring. He has no objection to that.

What he will not give up is the big-city ethos they started with. You do not come to New York and expect a welcome wagon. It is not that the city is rude; people are busy professionals, and they assume you are too, so you should ask the best possible question, with research and detail. That rubs some people the wrong way, and he does not think it is wrong to want a chill place for beginners instead. He still thinks Stack Overflow was never designed for beginners, even if Joel has said otherwise. A prodigy can use it. A beginner wants live screen sharing, live chat, resources, and a playground to experiment in, none of which the site gives them, because that was never the audience. Duplicate questions are a brutally hard computer science problem, because people are astonishingly good at asking the same thing with zero words in common. Some of those duplicates should exist, as signposts to one canonical answer. Ten copies of the same answer devalue reputation, which programmers hate.

Why are programmers kind of mean sometimes? Atwood’s theory is environmental. If you work with jerks all day, you become one. And what is the computer if not the world’s biggest jerk? It has no time for your nonsense. One mistake and everything crashes; one semicolon has brought down space missions. You internalize that coworker. You start to think arbitrary strictness is good, and that error code 56249 is a completely adequate message because that is what the machine gave you. You forget to be a person.

He reaches for the detective-novel trope: great detectives internalize criminals and are a little bit criminal themselves. Really good programmers think like the computer because that is the job. Internalize it too much and you become the computer. You are not mean, exactly. You have no patience for a lack of strictness. You are unforgiving, terse, “wrong, next.” Someone asks how to fix it and the reflex is still wrong, next question — normal for a computer, bewildering for a human sitting across from you. He recalls the 1990s “move” IT-guy sketch as the public version of that occupational hazard.

What makes a good solo programmer, then? He does not think you should be one. Citing John Carmack in *Masters of Doom*, he notes that the people building Wolfenstein and Doom had no Stack Overflow, no Wikipedia, no Discourse. You had to be a genius to invent from first principles. You do not need to be a genius anymore, which means you must not work by yourself. You have to be good at researching online and at asking well-researched questions, the kind that imply three hours of work before you typed them. In the 1980s and early 1990s there was nowhere else to go. Atwood used to call the Microsoft helpline when he was learning Visual Basic. Steve Sinofsky posted that C++ version 7 came with something like 10,000 pages of written material, because where else were you going to figure it out?

The big insight of Atwood’s years as a public figure is one he knows sounds discouraging: to be effective as a programmer, you eventually have to stop writing code. He does not mean giving up on programming. He means coding in a higher-level language. First assembly, hard-coded to the architecture. Then C, abstracted across ARM or x86. Then Python and Ruby. Higher than a programming language is spoken and written language — inspiring people, giving guidance, asking what if we did this. You are writing in the highest-level language there is, which for him is English. Patrick McKenzie, patio11 on Hacker News, later at Stripe, has a well-known post that calling yourself a programmer is a career-limiting move once you get far enough. Atwood thinks he is right.

Look at the Coding Horror archives, he says, and a lot of it is the claim that programming is about people more than code, which does not really make sense until you live it. Can these people get along? Can they understand each other? Can you even explain what you are working on? Are you solving the right problem? He puts *Peopleware* next to *Code Complete*: software is people; people are the software first. Once you pass a certain skill threshold you can solve any reasonable engineering problem put in front of you. You are not writing algorithms from scratch. What you cannot solve with code is that your manager is a jerk. That will cripple you worse than a hated framework, Sam’s bad commits, or Dave off in the wilderness writing who knows what. The toxic coworker or boss who stresses everyone into paralysis is the actual bottleneck.

Fridman asks whether rising into natural language means losing the lower level of building. Atwood is not very worried. When Discourse started in Ruby, a language he did not really know, he still had for-loops, recursion, and stack traces. He was not a beginner beginner; he needed to apply concepts he already had. Working only with Robin Ward, he realized that every time he bothered Robin with a stupid Ruby question, Robin was not building the first alpha. Bad use of both of their time. The answer was not to pull himself up by his bootstraps. It was to hire more competent programmers — Sam first, then Neil. At some point writing code becomes a liability to getting the project done.

What you optimize for, once you have a prototype, is speed of iteration: how quickly you can turn the crank. The first Discourse they demoed for seed funding was bad. He still has screenshots that embarrass him. There is a broad gap between how you think software will work on paper and how it feels once you live in it, so you ship the ugly version. He had a tweet people liked that he treats as fundamental. If you want to measure the core competency of any software company, time this: someone says this word in the product should change, because it will be clearer to the user — respondents versus reply, say — and then you measure from that idea to the change rolling out to users. That interval is your lifecycle, your health, your heartbeat. If the heartbeat is super slow, you are basically dead.

He is not being cute. If a single obviously better word takes two weeks or a month, or months, you cannot iterate, which means you cannot do anything. Fridman compares Tesla’s over-the-air updates in days with other automakers who take years. Atwood agrees the contrast shows up in how slowly those companies adapt, then adds a caveat: being a hummingbird is not the goal either. The heartbeat has to be healthy and reasonable, not frantic. Software is built by making a change, living with it, saying that was a terrible idea or that it would be better with Y, and turning the crank again. The more you do that, the farther ahead of competitors you get. Within a year you are miles away by the time they catch up.

He loves software that constantly changes and does not understand users who get angry that something moved. Change it all the time: that malleability is what makes software cool. Some changes suck, he has seen plenty, but fighting the essence of the thing you are building does not make sense. Embrace a healthy cycle. People do not change much, which is why investing in understanding people is like learning Unix in 1970: it will still be valid decades later, whereas the latest JavaScript framework is good for about two years. Discourse itself was billed as a five-year project and quickly revised to ten. Any software project, he says, takes three years to build what you actually wanted, and version one will be terrible, which theirs was. You ship it anyway. Version 1.1, 1.2, 1.3 is where you get good, if you can iterate fast enough. He wanted Discourse to be the WordPress of discussion: the default answer when a group of people needs to get together, open source, free, about five dollars a month on a VPS, built with bigger building blocks for the next ten years rather than shared hosting.

On the future of programming, Atwood is more impressed by raised baselines than by a new essence. He graduated in 1992 without learning source control; even in the late 1990s some people still were not taught it, which he finds unbelievable. GitHub, a Microsoft acquisition he calls incredibly smart, means anyone who wants reasonable source control is set. Programming has not become a different activity, but the floor of what counts as fundamental has gone up by orders of magnitude. Smartphones since about 2010 put a computer in everyone’s pocket, a huge social change whose good and bad we are still digesting. As a geek that was his dream world, and he adds the usual warning: be careful what you ask for. It is not the utopia. He has come around to the Unix view that command-line basics are what programming will be for a long time. He does not see magical visual programming on the horizon, and he cannot think of a smartphone gesture that maps onto programming. The cultural shift is large. The programming shift is not.

Artificial intelligence, in his 2018 telling, is oversold. A lot of it is the observation that people are predictable. Discourse flags a login from New York and, an hour later, from San Francisco, because two thousand miles in sixty minutes is suspicious. That is a heuristic, not AI, and a VPN can fool it. Good software anticipates needs the way Google predicts a commute from where the phone sits every day. He hesitates to call that full-blown AI. It is computers getting better because smartphones suddenly produced location and communication data you can feed into basic heuristics and some fancy algorithms, like a friend saying I see you are home, want dinner? In actual programming he thinks assistance is possible because there is so much repetition, with Clippy’s “looks like you’re writing a for loop” as the bad example. The better version is bigger Lego bricks: do not write your own HTTP library; use one that is already battle-tested. WordPress lets a non-programmer make almost anything through plugins. He expects more gluing and less “actual programming,” and he thinks that is good, because most of what you need is already out there. He used to think Unix was a waste of time. He has completely flipped: the Unix people were basically right, Microsoft and Windows were basically wrong on the server, and if you peel away one or two layers you still find Unix. Discourse itself is a big bowl of JavaScript delivered to the client, with sorting and basic work on the host processor — another bet on that shift.

Fridman suggests that advertising, at its best, connects people to what they would want anyway, which sounds like Discourse’s interest graph. Atwood has a contrarian streak: he is actually pro-ads if they show you things you would have liked, and he thinks it is rational to support the people doing the work. He still installed an ad blocker, reluctantly, because ads now drag in 30 or 40 megabytes. They feel like Experts Exchange did before Stack Overflow, and the ad-tech logo chart is an embarrassment of tiny companies. In practice, very few Discourse sites survive on ads. The model is too diluted, pays badly, and users hate it. Subscriptions, Patreon, and Amazon affiliate links do work. He once paid a site he used to participate on to switch to Discourse because the old software was so bad he would not come back, and he told the owner to drop hated ads and triple down on Patreon and affiliates. That worked, especially for a creator. Clean, fast, perfectly targeted ads would be awesome. We are far from that.

The last object in the conversation is the Code Keyboard, a mechanical board Atwood helped design. He admits it is a fetish. You can program on anything, even an on-screen keyboard, a thought he finds terrifying, or on old chiclet membranes with no feedback. What a mechanical keyboard says is that you care about the primary way you talk to the computer, the way a podcaster cares about a microphone. You feel the click. It indicates you are serious about fundamentals, and one of those fundamentals is typing fast enough to get ideas out of your head into the codebase. Practicing typing can make you a better programmer. He plays piano; the tactile part feeds the passion. Artisanal keyboards have exploded — he guesses 500 projects on Massdrop alone — and a former Tech Report writer he follows posts “keyboard porn” every week. Fridman has a pile of yo-yos. Technically you need one. These unnecessary religious artifacts, Atwood says, are part of what makes us human. They make life worth living. In the strictest sense nothing is necessary. That is the point.