 All right, good morning, everyone. We are here to the first webinar of the Agile India series, and it's an awesome pleasure to have Jeff with us for the first webinar. Jeff, obviously, people know him from being the creator of Stack Overflow and his blog, which, according to horror, is a very popular blog again. I think I'll not take too much time and just hand it over to Jeff to kick it off. I think to start with, Jeff, if you can quickly introduce yourself and also then kind of talk about the main topic that we had, which is how to ask great questions and how to be a good citizen on Stack Overflow, that would be great. Thank you, Jeff. Thanks, Nuresh. First of all, thanks for having me and thanks for inviting me to your conference. I've never been to India. I would love to make it there one day. But I have three small children, so it's hard for me to travel at the moment. So if you know me, I know this is double logo, I apologize, but I have my logo. I have this blog called Horror that I've written out for a long time, so if you know who I am, you might know that. And then, starting in 2008, we did this thing, Stack Overflow, with Joe Spulski. And I am no longer a part of day-to-day at Stack Overflow Stack Exchange. I left in the early 2012, but I have a very good relationship with them and I go to Stack Exchange all the time. It's my baby, so I love it there and that's what I'll be talking about is Stack Exchange stuff. And of course, if you haven't seen, Stack Overflow is the Q&A site for programmers, but we do have a whole network of sites for other topics that tend to be technical science and data-type topics, but fun for geeks, as I like to say. So Stack Exchange, that's the website to go to to see the index of the full set of Q&A sites we have. And my current project that I'm working on is called Discourse, which is much more of a forum type of solution, not Q&A, just general discussion. So another reason that it's exciting for me to talk to everyone here is that I looked and the last time I did statistics, when I was at Stack Overflow, of where people come from when they visit Stack Overflow, the number two country was India. Number one was the United States with about 30%, last time I looked, it's probably gone down because there's more people coming in internationally, but number two was India. It was almost at 9% of all the visits of people that come to Stack Overflow are actually coming from India. So it's great for me to actually reach out and talk to people in India because this is a huge audience for Stack Overflow. And the first thing I would say about Stack Overflow and Stack Exchange is you're really, it's a place where you're learning from other programmers. So it's a place of learning. You have to approach Stack Overflow as if you're headed to, I hate to say this, but school in the morning. But a fun school where you get to hang out with all your friends and work on interesting problems that you like to solve. So if Stack Overflow works at all, it's because other programmers are helping you and because you're helping other programmers. And when you come to Stack Overflow and you have a problem, the first thing you wanna think about is what have I done to solve my own problem? What have I looked for? What have I researched? What have I tried? That's often the best way to get an answer is to start by asking yourself and make sure you've really asked yourself. There's this technique called rubber ducking where when you have a problem, you pretend like you're talking to something. I will use this random item from my desk, this Arizona hot sauce. So you would pretend that you're talking to this and say, hey, Arizona hot sauce, I have a programming problem. And you try to just explain it like you're talking to someone next to you, not in your own head. But you're actually walking through the problem, explaining it, trying to understand it and talk through it in a way that's understandable to another programmer. And a lot of people find that when they're forced to really sit down and talk through the problem that they're having as if they're talking to another person, they often find the solution by themselves because they were just walking through the problem in a very structured way as if there was another person in the room. So that's really, really helpful. So I would say that is step one is what I call rubber ducking. You can look up on the internet search for rubber ducking. It's kind of a fun thing to search for. And I have a blog entry about it and there's lots of other people talking about it. So that's step one is to do the rubber ducking is talk through the problem as if you're talking to another person. And then the other one, and I know this seems kind of obvious, is research has become kind of a scary word on Stack Overflow as in show your research. But let me give you an example. In high school, I had a calculus teacher and he was a very, very strict calculus teacher. And I was very bad at math. I know there's this illusion that programmers are always good at math, but I am terrible at math and have always been very, very bad at math. So this was a difficult class for me. And this teacher had a really interesting way of presenting the work to us. What he said was the way I'm gonna grade your homework is on noble efforts. I don't care if you got the right answer. What I wanna see is that you made a noble effort to achieve the answer. In other words, you put in the work, you didn't just give up on the problem, go I don't know how to do this. You actually tried stuff, right? You sat down and you looked at the math problem and said let me try this, let me try this. And you're showing your work so that the teacher can see that you made what he called a noble effort and then you would get credit for the homework. But if you didn't make noble efforts, you did not get credit for the homework. So it's kind of a sense of show us, I don't wanna say show us your work because that seems very strict, but show us the noble effort that you believe in your problem. That you believe your problem is so important that you worked hard to try to solve it. And that inspires other people because when they see wow, this person, this man or woman, really wants to know how to do this or why this is happening and look at all the things that they have done to try to figure this out, that is inspiring to other people and they want to help you. But when you walk in and you say, and I'm not saying you've done this, but when you see people do this, they walk into a room and go, I don't know how to do this, here it is, figure it out for me. That is not inspiring. Nobody wants to help you when you walk in and say, here's my problem, give me the answer. Effort begets effort. So I think that's another way to look at this is showing us that you have made an effort to solve this and that you really believe in the problem. I mean, it's a belief system issue of if your problem is so important, why don't you care enough to try to solve it? Like, why is it our problem now to solve your problem? You know, like you got to convince us, like this is the most important problem a man or woman has faced in the world. This programming problem, the fate of the universe, hinges on the answer to this question. And that's exciting and that's inspiring. It really, really is. Even if it's some tiny, tiny thing, it can be cool because programmers love tiny little fractal problems. They love tiny problems that are very, very minuscule in the big scheme of things, but they're fun to programmers when you break things down into little tiny little pieces. So rubber ducking, and then what I call noble efforts, convince us that you really believe this problem is important by showing the work that you've put into solving the problem. The next step is really, can you explain the problem in a way that's understandable to other people? And one bad way to explain the problem is to say, here is all the code in my editor. I'm just gonna copy all the code in my editor and I'm gonna paste it into Stack Overflow. First of all, you have this TL-DR problem. I don't know if you know the acronym TL-DR means too long, did not read. So everyone in Stack Overflow is a volunteer. So when they're looking at your question, they're thinking, how much time is this gonna take? Because I'm busy, I have things to do. How much do I have to read to even understand what your problem is? If you're writing volumes and volumes of text and you're putting volumes and volumes of source code in your question, it's really difficult for people to just get to the bottom of your question. So it's important when you structure your problem to give really the minimum, or at least pair it down to as little, the kernel of the problem as you can. The smallest piece that will actually reproduce it. And then some basic questions like, not just code, because code is great, we love code. I've always said for a long time on Stack Overflow, questions without code are a little bit weird. They don't have to have code, but they should probably have code if they're on Stack Overflow. So you want code, but you also want words, like in English words, because that's what we use on Stack Overflow, for the most part, saying like, well, what is this? Before I even get into the code, give me a Twitter length description of what it is you're trying to do. What are you trying to accomplish? Not, here's the code that's trying to do X, but what are you actually trying to accomplish with this code, right? What's your goal? Forget the actual implementation, because a lot of times when people answer questions, they'll tell you, look, I'm gonna give you a totally different way to do what you wanna do, because I don't think the way you're doing it is really the right way. And you have to be okay with that, because you have to explain what the goal is. There's gotta be multiple ways to reach the goal. As they say, I think in Pearl, there's always more than one way to do it. So explaining just what you're trying to accomplish helps people give you more answers than if you said, I must do it using these language primitives, and that's the only way. Unless you have some artificial constraints where you have to do that, you wanna explain just sort of what the goal is. And then some basics, like what results do you want? What are you actually seeing when you run your code? Like do I have to run your code to find out that there's an error? And then of course summarizing the other research that you did. So it's really just telling a story. This is a timeless, timeless human activity. We don't really want a programming problem, we want a story. So you need to tell a story with your question. And one thing that goes with that, and I'll give you a really good pro tip for asking, and a lot of the advice I'm gonna give you is not really specific to Stack Overflow. This is just general asking questions of life advice. It's not really any different, except it's a little bit technical with code and so forth. Don't write the title until you get to the end, because titles are really hard. It's hard to write a good concise short title of what it is you're trying to do. And a lot of times, for example, when I write blog entries, I don't write the title until I've finished writing the entire article. And only then do I really know what the title should be. So if you start by saying, oh no, I have to have a really good title, you're gonna be really stymied. It's gonna be very difficult for you, because titles are hard. And as you write the question, you will figure stuff out. Sometimes you'll figure stuff out to the point that you'll say, hey, I actually know the answer to my problem, which is great, this is rubber ducking. You explain the problem so well that you explained it to yourself and now you can actually answer it. So save the title for the end. That's my one pro tip in terms of actually writing the question up. Now, once you've actually written the question, you've summarized it, you've given a basic description, you have the minimal amount of code, all the things I just talked about, you wanna really review your question. And this is another thing that goes back to one of the inspirations for Stack Overflow. There's a couple inspirations for Stack Overflow. One is Wikipedia, of course, the editability of Wikipedia so it doesn't really go out of date. Of course, the achievement system, which we got from Xbox 360 and video game platforms. And the other one really is blogging. And that's why when I talk about Stack Overflow, sometimes I mention my experiences when blogging, because when you're writing a really good question, it feels a little bit like writing a blog entry. And one thing I do when I write blog entries is I read them really obsessively. Like I'll write a blog entry and then I'll read it like 10 times over and over. I'll just read, read, read. And another good pro tip for writing in general is when you read your writing, speak it out loud in your mind as if you're talking to someone. Because you want the way you write to sound like the way you talk. You do not wanna write in a way that's artificial stilted in the way you're supposed to write. Write like you talk. And the way you can achieve this is as you're writing, like when you get to the end of the writing, just talk through it. In your mind, say like I'm speaking to someone and I'm reading this thing that I wrote. Does it sound like I would talk? Does it sound weird? Does it sound stilted? Are there words missing? And this also gives you an opportunity to proofread your question. Make sure you actually have good grammar, good spelling to the best of your ability. Everybody's, you know, nobody's perfect and we don't expect that on Stack Overflow. But reviewing your writing is so important. You don't wanna just get to the end, figure out a good title and then click submit. You wanna get to the end and then really read through everything you've written and make sure it's correct. Like another thing that I do all the time obsessively, even when I post to Twitter is if I'm about to post a link, I make really, really sure that that is a valid link before I post it on Twitter. I open a new browser window, I paste the URL in and say, before I send this tweet out to 100,000 people, I want it to actually work, you know, because I have respect for my audience. I'm not gonna send them a link that doesn't work. I use Chrome Incognito, right? So it's I'm not logged in or whatever and I test the link. And this is really, really simple, really basic stuff but all the time I'm seeing stuff on Twitter that comes through my little Twitter feed that's links that are broken. Where people didn't test the links for whatever reason, I don't know, they're busy or what have you, but it's a bummer, right? It's a bummer for me as a person reading Twitter when I click on a link and it doesn't work. It's a little, I hate to say disrespectful but it's not cool. So I try to be really respectful of the people's time and make sure that all my links work. That's another thing you could do when you're reading through your Stack Overflow questions. Make sure if you provided any links to a JS Fiddle or, you know, things like that, any other resources that they're actually correct link and functioning links in an incognito browser window. So once you've done that, so you've actually rubber ducked it, you talked through it yourself, you did research, you've done it, you got a great question, right? You read through the question, you made sure all the links work, it sounds like you would talk and you click submit, now you have a question on Stack Overflow, congratulations. That's step zero of solving your problem is actually getting it in a nice written form that's concise and clear and has a good title and is grammatically correct, has all the right words in it, you know, basic stuff, right? That's good, that's fantastic, that's a great place to be. Now, you need to prove to us that you care about your question more than anyone else in the whole world. And that means participating in the search for a solution. I am not above, in fact, every time I post a question on Stack Exchange, if I don't get an answer, I will find the answer, like whatever it takes, unless it's just fundamentally unsolvable, like no human being can solve this question, I want an answer so badly that I will go in and answer my own question, you know, eventually as I figure stuff out. I was like, well, nobody answered my question, but I don't care because I love my question, it's like one of my children, like I need an answer to this question. So I will go in and answer it myself if that's what it takes. Now, you don't have to go that far. What I would say is most important is after you post the question to do what I call gardening around the question. Like if you see problems with the question, like people post comments, oh, hmm, you're asking this question, but I don't understand this thing that you said. That's a comment, right? Somebody left on your question. You should then see that really soon, like you should be watching your question, like regularly, like almost like real time, sometimes depending on Stack Overflow, get so much traffic now, you can get almost real time answers, which is amazing, right? That's amazing, that's incredible. But you need to be there. You need to be there seeing that. So you need to be either on the page or every few hours checking in on your question and gardening. And if somebody posts a comment on your question, you wanna go in and then edit your question to improve it and clarify that, this piece of information that was unclear, I have now revised my question. And people will say, hmm, interesting. Here's a person who asked a good question and is actually interacting with us and participating and helping us find a solution to this problem. That means a lot to people because it shows that you're serious. You know, you're doing something. You're not just posting a question and walking away for days and days and just magically answers appear. You can do that. But it's even better if you're there and as answers come in, you comment on the answers and say, oh, this is a good answer, but I need a slightly different thing or this doesn't work for me for the following reasons. I need a clarification on your answer. The participating in the search for a solution is so important and you do that by responding to people, basically. And ideally clicking that edit button. The most important button on Stack Overflow is not the ask question button, it is the edit button. Okay? And this applies to old questions too. Like if you see old questions, old answers, this is another way you demonstrate that you care about the communities. You go in and you edit, you improve existing answers. You improve existing questions. You're gardening with us, creating this great natural resource for all the programmers in the world to really benefit from. And the edit button is so central to that goal and that mission for us. Because everything is Creative Commons. It belongs to you, it belongs to me, it belongs to all programmers. So I would say that's the basic summary of sort of what I recommend as good practice coming into Stack Overflow. And one thing I want to talk about now is if you've been on Stack Overflow for any length of time, you've probably seen this guy, John Skeet. And John Skeet is kind of the, what's the right word? Super star of Stack Overflow. He has a huge reputation score. He's there all the time. And John works at Google and he's the nicest man you will ever, ever meet. I've actually met him, he's in London. Super, super, super nice guy. And the interesting thing about John is he has a history of helping people on the internet. John did not see Stack Overflow and just one day decide that Stack Overflow is so good that I'm gonna start helping other people. John is the type of person that loves to help other programmers. And I think that's the mentality you wanna have of when you come into Stack Overflow, you have to have a genuine interest in learning with fellow programmers. And that means contributing a little bit of your time. It's not so much I come in, ask questions and you give me the answer. It's I come into the community, you give me something, I give you something, right? And this is the interchange that we have. And people see this, people pay attention to this. We have histories, we have reputations. We go to great lengths on Stack Overflow to show the history of your behavior as a participant on Stack Overflow. Are you the type of participant that comes in, asks one question and we never see you ever, ever again? Or are you the type of participant who asks questions but also answers questions? Does edits helps us create our garden, vets questions as they come in? All these things that you can do to make the garden better. And that's the thing about John Skeet that's most interesting to me is that he has a long, long history, way before Stack Overflow, of coming in and really going on the internet and helping other programmers. And that's more important than Stack Overflow. There's no magical formula on Stack Overflow that makes that happen. We try, the software is created in such a way that we try to encourage good behaviors. In fact, if you do software design at all, it's interesting to look at Stack Overflow and the way that we designed it and think, how do I encourage positive behaviors through software? And so many of the decisions about the way things are in Stack Overflow, that was the golden rule that we looked at. Does this design, does this feature, does the way this works, actually encourage positive community behavior? And if we thought the answer was yes, then we included it. And there's also features designed to discourage what we view as negative community behaviors. So you can also look at things where Stack Overflow makes it hard to do things. Like commenting, for example. There's a lot of people that complain, I wanna go to Stack Overflow and immediately post comments on the answers and questions there. And why can't I do that? Why would you limit me from posting a comment on a question, I could make it better. But I can't, I have no right. I sign up as a new user, I can't leave any comments at all. And I'm not actually gonna tell you the answer, I want you to think about that as a user. Like why would we limit users from leaving comments on questions and answers? And it's a really interesting design question and it has a very, very pointed answer that we feel very strongly about. But I think it's fun to think about it from a design perspective. So let's go back to John Skeet. So John Skeet also has something he calls writing the perfect question. If you do a web search for John Skeet and writing the perfect question, you will get John's description of how he approaches asking questions. And one thing I want you guys to think about is the programmers you think of as amazing, really, really good programmers, really smart, whatever that actually means, how often do they ask questions? And if you look at John Skeet as an example, there's a lot of other programmers like this. They don't actually ask that many questions. And I don't think this is because they have the answers to everything. I think that's far from the truth. I think it's the opposite of that. What I think happens is when you're a really good programmer, you become very good at finding answers. And I would say that's one of the hallmarks of a great, great programmer. It's not that they never ask questions, it's that they become experts at answering their own questions. The rubber ducking, right? Doing the research. I know research is kind of a weird word for us on Stack Overflow now, but I'm gonna say it anyway. Doing the research, doing the searching, finding out what everybody else knows about this before they even begin asking. So by the time someone like John Skeet is asking a question, it is very, very hard question because it's been really, really thoroughly researched and rubber ducked. And John doesn't talk about that in this article, but I want you to keep that in the back of your mind because I believe it is very, very deeply true. By the time a really, what do you think is a very talented programmer is asking a question, it's probably going to be pretty hard because they've walked through all those steps. Now, the first piece of advice John Skeet gives is imagine you're trying to answer your own question. So think about it in terms of explaining the question to yourself, which is again going back to rubber ducking. And he also emphasizes the importance of the title. Now, again, I want you to bear in mind my pro tip of don't stress too much about the title initially. In fact, I think it's kind of a mistake. I know this is a design issue we can never reconcile, but on the ask question form, the first field at the top is title and then there's the question and then there's tags down here, right? Well, I apologize for putting the title at the top. I think you kind of have to do that because that's how email does it, but it's almost like I want the body up here, then the title, then the tag. So don't stress out about title. Write your body first and then finish the title next and you will almost invariably have a better title. Context, I know John Skeet is always talking about this of context and when you come into asking a question, try to think about it in terms of explaining to not, say you're a Java programmer, for example, try to imagine you're explaining this question to someone who's a Ruby programmer, okay? Like don't assume the person reading this question knows everything there is to know about Java. In fact, I think you should assume the opposite. Assume you're talking to someone who has very minimal knowledge of Java and explain in link anything that you think someone who is new to Java would need to know. Unless you're asking like a super expert question that's just super rare, most questions on Stack Overflow, you should provide all the context necessary and in fact, it's really interesting that when I talk to programmers, a lot of programmers learn languages, at least I've talked to a few that have done this, they learn new languages by answering questions on Stack Overflow in that language, even though they don't actually know the language, which sounds crazy, right? Like how are people answering your question if they don't, your Java question if they don't actually know Java? And I think there's a couple answers to that. One is programming languages do have a lot of things in common and we wanna attract on Stack Overflow, programmers that know more than one language. Joel Spolsky and I felt that one of the hallmarks of a great programmer was that they really weren't limited to one language, they knew multiple languages, programming languages and they understood and respected the differences between these languages and the ways in which they're similar and it just gives you an appreciation for all programmers are trying to solve really similar problems, right? Like even though they're in a different language, it doesn't mean they're the enemy, it doesn't mean that they're doing it wrong. It doesn't mean that you shouldn't care. Some of these languages have really interesting ways of solving problems that you're already attacking. So it's almost like you're teaching the language a little bit, like this connection between teaching and learning on Stack Overflow when you're asking a question, you're teaching people, right? You're making the sleep of I'm teaching you how to understand my problem. Maybe if you were just a, you have to know programming. You can't not know programming, but assuming you're a newbie programmer, you could attack this like a homework problem and say, interesting, I wonder as a puzzle, this is a fun puzzle for me to solve and I can learn more about Java by looking at this question, following the links and understanding what this person was trying to do in the question. So this is all about context and the process of teaching and learning on Stack Overflows. Don't be afraid to throw in a whole bunch of context. It never, never hurts. Like if you put in links to the Java documentation or oh, I see, I'm trying to do it this way and I link to Java doc here. The people who know Java aren't gonna be hurt by that. They just won't click on those links. It doesn't bother them. But for the people that are still learning or trying to figure out your problem, it can be very helpful to provide context in terms of links and so forth of documentation, things that you found. Anything that's really related to the problem and would be helpful, like feel free to include all those things, it's very easy to scan past links and brief summaries of what's going on. When it comes to tagging, like I've, so there's really three, we're talking about the ask question box and we talked about body, we talked about title. And now we're talking about tags. So tagging the question, the most obvious tag is of course the language and you do wanna get that right. If you're talking about Python, make sure it goes in the Python tag. And if you're talking about Ruby, make sure it goes in the Ruby tag, Haskell, so forth. These are very, very easy tags to get right and you should definitely get those right. Where it gets a little weirder is tags number two, three, four and five. The first piece of advice I would give people is don't feel like you have to use the maximum number of tags for a question. Worry a lot more about having a good interesting story in your question than every tag being precisely just so. Get the language right. But worry a lot more about the body of your question. Is this interesting? Like, do I care? Why should I care about your question? That's your problem. It's not that it's in the wrong tag, it's that nobody cares about your problem because you didn't make it interesting, you didn't tell a story, you didn't make it simple for me to understand what your problem was. It's not, oh, I used the wrong tag, therefore I don't get good results. It's almost never, never, ever the case there. I would be very, very cautious about tagging. Only include tags if you feel strongly that that tag is appropriate for your question. Do not use the, I'm gonna spray a bunch of tags on and see what sticks approach. We limit you to five for a reason. And in fact, it's interesting in the early days of Stack Overflow, we allowed an unlimited number of tags for questions. And that almost immediately was a disaster because everybody would put every tag they could possibly think of on a question. And then it just became noise. It was like, there's 20 tags on this question and I can't process that. Like that doesn't help me as a person trying to answer this question. Two tags, three tags, you know, great. But don't feel compelled to use the maximum number of tags or have a bunch of tags that are really, really good. Focus on your question, get the language right, you know, and then move on. So moving on with John's document, which again is called Writing the Perfect Question. Feel free to read this, it's very, very good. The problem statement I kinda covered already. One thing that John does mention is you're kinda working at two levels in the question. There's the micro level of I get this error, right? So you could create a whole stack over question that says I get this error. What do I do? But what you've forgotten to include is the big picture of well, what are you trying to do? I know you got that error, that's helpful. Thank you for including the error message. That's wonderful. But why, what path took you down the road to getting this error? Because sometimes the error, like if you're going down the road, you're like, oh, I got an error right here. Well, the answer was to turn here. The answer was not fix the error. The answer is turn earlier in the road and go around the error, right? So make sure when you're working in the question you're thinking in terms of the detail level of here's the code, the minimum code sample necessary to do this, and also the macro level of what is this? What are we trying to do here? Why are we in the room? You know, like what goal did we have when we set out to do this? One thing John also mentions is in addition to sample code, sample data is sometimes very, very helpful. So if you're relying on code that has a certain output but only fails under certain conditions with certain data, provide sample data as well. I sometimes forget this also, is code plus data, right? Like there's this inseparable connection between the two. So, you know, focus on that and make sure that you can actually bring data in as necessary to give examples of where the problem occurs and where it happens. Cause I mean, who hasn't fought with nulls in their lifetime? I mean, nulls are like a scourge on this planet, right? So if it takes a null to create this problem, you should mention that. Cause I know, you know, or off by one or, you know, these common programming errors. So do mention data. If you have a data-oriented question, make sure that you provide some source of data as a companion for the code. Now, John also has a section on spelling, grammar and formatting. I don't, you know, I think what matters here is again, going back to noble efforts. I don't, nobody expects everyone to have a perfect command of English. In fact, one of the things you can rely on on Stack Overflow is, hey, this is a place where we speak code. We do want words, right? We don't want just code. I covered that earlier. But it's okay if you have trouble with the words. Make sure the code is really good, right? You can compensate. If you're not good at the words, first practice to get better at the words. The only way you're gonna get better is by practicing and learning from, you know, your mistakes. So you gotta practice the words too. And the words are so important. Like I can't, like my entire career, I write a lot of blog entries on, you know, coding horror historically about if you wanna be a really talented programmer, you need to be as good at the words as you do at the code. And I like to think we teach that at Stack Overflow. Like questions that are interesting where people are telling me a story in a way that I can understand, do better than ones that are just like, I get this error, I'm trying to do X, here's the code. You know? So you're practicing two things. You're practicing minimum reproducible set of the problem, explaining the problem. And then the words that tell the story of what this code is trying to do. It's kind of like when you're writing code and people say, you know, when should I put a comment in my code? I always explain it that the code tells me how it works, you know? This is how the computer does what it's supposed to do. And the comments that you put next to the code tell you why. Why are we doing this? Right, like what? Why are we even here? You know, why would anyone even try to do what this is doing? And sometimes you don't have to. Sometimes you don't need any comments. I would never propose that all code has one line of comment next to it. That's insane, that's bad advice. But anytime you feel like, hey, you know, the code can't tell the complete story here. I need to tell people why we're doing this or why we have this really involved approach that's complicated. When we could have done something really simple, it's because we were trying to accomplish something and you have to tell the story of what that is. That's the same kind of thing we're teaching on Stack Overflow. You put the code in and you tell the story and you've got to use words to do that, right? And English is what we use on Stack Overflow. So practice both of those things. Feel free to rely on the code, make the code awesome. That's fantastic. Make it very succinct, very clear. But also, you know, practice your words. Make sure that your English is good as it can be. And one of the greatest compliments I've gotten working on Stack Overflow was emails where people said, look, I feel like Stack Overflow has made me a better communicator. I've gotten really good at explaining things. And my god, that's the entire story. If you can get good at explaining things, you're set in your career for life. You have nothing to worry about at that point. You can do so many things now. It's the people that can explain what they want and can explain in a way that people can understand that are going to have more difficulty. So it's a huge competitive advantage to be able to explain yourself in a way that's really clear that people can understand. So that's the background that I would give to John's advice, which is really, really excellent. He focuses on spelling grammar and formatting. But this is the bigger picture that we don't say this on Stack Overflow. But that is kind of the goal is to teach people to get good at the code and good at the communication part that goes with the code. Because without those two things, you're not going to get a good answer to your question. And if you put them together, it's amazing, the kind of answers that you can get. Some other interesting advice John offers under making good impression is, and some of this is subtle, but I like it, actually setting a name for your account, like giving yourself a name that maybe is memorable, like I have a name, Coding Horror. This is a memorable name, right? There is a method to this. Like first of all, I felt like this spoke to me, because programming is like I am my own worst enemy all the time. I feel like I'm looking at this guy in the mirror all the time, because I make so many mistakes. This is the guy that is in the mirror, and he's teaching me how to learn from my mistakes. So if you see Coding Horror, you're going to probably remember that. If you see user 12345, you're not going to remember that. So I'm actually proposing internet handles, like interesting names, beyond the one that your mother and father gave you. Pick a cool, interesting name. I think that's fun, and I think that makes sense. And we don't want, we don't require real names or any that Google Plus stuff. Sorry, Google Plus. I know we're on Google Plus right now. But we don't require real names or anything like that. So feel free to give yourself a really interesting, cool name. As far as answering your own question, John has good advice here, which is make sure it's fine to answer your own question. I talked about that earlier. I will sometimes answer my own questions, just because that's the only way to get a definitive answer that I like. And that's OK. If you feel like only you have the right answer to your question, totally valid. There might be three other answers, and you know what? I don't like this answer. I don't like this answer. But explain why you don't like them in a nice way. And then put your own answer there and say, look, here's my solution. Here's why I believe it works best for my problem. And that's totally fine. It is fine to answer your own question, but it must really be an answer to the question. All answers have one purpose in life, and that is to answer the question right up there. So you're looking up. Here's the question, and here's the answers. Make sure you answer the question. This is a rock solid rule we have on Stack Overflow. No conversation, it's really an answer. But as long as your answer is legitimately an answer, don't be shy about answering your own questions. It's totally, totally cool, because we see people that are afraid to do this, like, oh, I don't know. Will people be offended if I answer my own question? I would say no, because as long as you do it in good faith and you're explaining why you're doing it, I think that's totally, totally fine. Greetings, I should mention greetings. We are somewhat strict about this on Stack Overflow, and I apologize because it can seem weird to people used to very conversational things like forums, that we don't like greetings like, hello, everyone. We're kind of busy, so if you could just start with your problem, that would be great. So no greetings, no salutations at the bottom. It's OK to say thank you. I don't object to someone saying thanks for looking at my problem. It's not the end of the world. I don't think it's wrong to do that per se. But again, remember, you want to be concise. The goal is to be helpful. And this isn't the real world. This isn't like me talking to you. We're sitting next to each other. This is an interaction on a computer in a very structured Q&A format. So feel free to be concise. I think that helps make the point that you're using other people's time in a respectful way. It's subtle, but I think it helps, and it's worth mentioning. I'm glad John mentioned it. Politeness. Now, although we're down on greetings, don't say hello, fellow coders, comma, here's my problem. It's not because we're rude. In fact, civility is hugely important on Stack Overflow. We enforce that with an iron fist. You cannot be a jerk to other people. First of all, because it doesn't work. If I walked up to you in the street and say, hey, jerkface, tell me how to get to the bank, why would you want to help me? Being nice to other people is a strategy for actually getting answers to your questions. And we enforce it, like it's just dumb to be rude to people that are trying to help you. It doesn't make any sense. So if at any point you find yourself getting angry or seeing other people getting angry, please flag it because we don't encourage or tolerate that kind of behavior. It doesn't make sense in a Q&A format. And one trigger thing for people sometimes is when you get answers that aren't what you wanted, meaning people have a, I don't know if you met other human beings, but they have a way of giving you answers that are not at all what you wanted, right? Like it wasn't thinking of that. Why would you even say that? That's not right. What are you doing, right? So it's frustrating because like, and usually what it means is I didn't specify my problem clearly enough because they gave me an answer that is so far off the map. Like, you know what you should do? Turn off your computer. Now you don't have a problem, right? Like, well, I guess that solves my problem. I turned off my computer and now I don't have any problems. Great, you know, awesome. That's an extreme example, but you know what I'm talking about. And so I think it's just good to say, look, you know, this solution doesn't really work for me. And just move on. Like, don't take anything, any of that personally and realize that they are trying to help you. Like they contributed and answered your question. It wasn't exactly what you had in mind, but hey, maybe this is an opportunity. Anytime I feel like people aren't understanding me, I feel like I have failed because I didn't explain myself well enough. So you should look at that as an opportunity to go in and again, what's the most important button on Stack Overflow? It's the edit button. Go in and edit your question, say, oh, I'm sorry, I apologize, I was not clear. And I will try again to be more clear. So I think that helps. So anytime you find, you know, you're getting a little heated debate if you will about stuff, just clarify your question, right? Like, don't get angry, just click the edit button instead. Accepting answers, this is another etiquette thing, but we have a convention on Stack Overflow where if you find a really helpful answer, you can vote it up, and you should always vote things up and down. And by the way, down, don't forget the down vote. We actually like, I mean, I won't say like down votes, but this is about data, science, and facts. When I downvote something, it doesn't mean that I don't like you as a person. It just means that I did not think your solution worked for me to the point that I felt like it should be downvoted, right? That's all it means. It doesn't mean anything more than that. And hopefully it's based on data, facts, and science. It's not based on opinions. Your example didn't compile for me. Therefore I'm gonna vote it down because it doesn't compile, right? And maybe I screwed up, but that's the reason. It's not you're ugly, I'm gonna downvote you. It's this doesn't compile. It's a data, fact, and science-based system. Now, obviously we wanna focus more on the positive, which is the upvote, right, upvote. You wanna upvote all the things that are really helpful. And I would also encourage people, when you come into existing Stack Overflow questions that work for you, please upvote them. In fact, we have a reminder that pops up at the top, says, if you hold a cookie on Stack Overflow and you're actually logged in, we'll say, hey, cool. You arrived here through Google. Did this help? If this is awesome, please upvote it. Like, don't forget to upvote stuff that was really helpful because that helps us get the signal up high and the noise down low. That's how the system works. It requires active democratic participation on really every level, right? Like, you can actually become a Stack Overflow moderator. If you really want that, you can do that. We have periodic elections. I really mean it when I say democratic. The people contributing answers aren't me. It's other programmers just like you. The people voting on it are other programmers just like you. And as you get more reputation in Stack Overflow, you can do more things. We give you more power in the system. You can vote that certain questions should be closed, right? And you can also run in elections to be a Stack Overflow moderator. And we need great moderators. If this appeals to you and you think, wow, I love Stack Overflow and I wanna be a big part. I wanna be a leader, a real leader within the community. I'm not the leader. Like, I don't even work at Stack Exchange anymore. You could be. You could eventually be elected a moderator on Stack Overflow. So again, getting back to voting. So voting things up. And then beyond that, there's this thing called the accepted answer. Now, this is really a convention. It doesn't mean that the accepted answer is the only answer. Because if you know anything about programming, you know that there's always more than one way to do it. Any good question on Stack Overflow should probably have at least this many answers, okay? There should be at least that many ways to do it. In fact, I get suspicious. When I see questions that have this many answers, one, I sort of wonder if the question is broken. Because programming is cool because it's like a chessboard. There's, you know, two to the 64th or however many trillions and trillions of moves, right? That's what's fun about it. It's so complicated. And there's so many ways to solve the problems. That's what makes it fun. But make sure for the solutions that are really working for people, you really are voting for them. And if you're the question owner, if it's your question, and you think one answer is just so good that it's clearly head and shoulders above the other, make sure you tick the accepted answer box next to it. That's like a special gesture of thanks. Beyond saying thank you, beyond upvotes. It's saying, wow, this is so good. I think this is the best answer to my question. And the other misconception there is accepted answer represents only the question asker's opinion. The community can disagree with you and that is okay. It is possible to have an accepted answer that is lower voted than another answer. This is okay, because all it means is that the person who asked the question felt that that was the best answer for them, okay? The community felt a little differently. There's nothing wrong with that. It's perfectly okay. Don't feel like you have to take the highest voted answer and accept it. No, you don't. If you own the question, one of the special privileges you get as the question owner is say, you know what? I am the author of this question. It's my question. And I think your answer was really, really good. Like, I loved it. It worked awesomely for me. And you're saying thank you, right? That is as direct a thank you gesture as we have on Stack Overflow is accepted answer. So please, if you own questions, I would even go back in time. Like if you have questions you've asked on Stack Overflow, go back. And look and see if there's any answers that were so good, you feel they deserve this. Don't feel like you have to, but I really encourage you to think about it. Remember the volunteers that are giving their time to you and the type of answers that you're getting. If you feel they're superlative, then make sure you indicate as such. It really helps, you know, on a social level. It's a very direct, the most direct thank you we have is the accepted answer. And it's also signal. It tells us that that was indeed a very good answer at least by the, in the opinion of the person who asked the question, and that's the right that they have. So I think that's about all I have to say on just general advice on how to ask questions. Like how to ask a great question because the goal is always to get an answer of course. But getting an answer sometimes requires you to put in the time to answer, to ask a really, really great question. And it's a skill that will carry you really, really far in your career. And, you know, I'm just really proud to be associated with the community at Stack Overflow because I think it will teach you these things if you let it. And Nourash, I think that's all I have. And if you want, I can open it up to questions. Only really good questions though. All right, that was really good, Jeff. I think, I'll just take a minute to quickly summarize what you just described here because I think you had some real great gems in there and they can really, really help the community. So I think you started with Robert Ducking. I would 100% agree Robert Ducking is awesome. You know, the Nobel effort was good. You know, do your own research. Describe like a tweet-sized goal. Like what are you trying to do? Why are you trying to do this? You know, and have a minimum reproducible court so it becomes easy for someone to kind of take this and answer your question. And, you know, the other advice you had was don't write the title until you finish asking your questions. Generally, you would get much better title once you're done asking your question, once you start describing everything. And review your question, walk through it, talk through it, talk it out loud. Again, this will really help you answer the question and maybe the Robert Ducking thing would kick in and you would probably answer your own question. You know, that's also great. The other very important thing you highlighted was, you know, garden your question. You know, participate in the research to find the answer. You know, it's like a quest to find the answer. And, you know, the edit button is the most important button. Go in there and edit and improve your question and refine it and, you know, make it better and better so that the community can benefit. And don't just ask your question and disappear, of course. You know, help the community, join the community, answer other people's questions. You know, the voting and the accepted answer thing that you highlighted, all great. And so I actually, I had not read this blog that you highlighted from John. So I'm going to actually go read John's Keeps blog writing the perfect question. So these were kind of my quick summary of what you just highlighted. Good summary. I guess I was clear. Cool. So I think there are a few questions that are there up on the Q&A section. I'm just going to quickly go through that. Feel free to shoot them down if you think they're inappropriate. And, you know, let's try and cover as many questions. I think we have about nine minutes left. So we'll do our best to get as many questions answered. So the first question I see up on the Q&A section is, you know, from Arun. And Arun is asking that you always have been a crowd puller even before Stack Overflow. Your blog was very popular. And when you started Stack Overflow, the reputation you already had kind of really helped you. What would be your advice for someone who does not already have a reputation, but wants to start a community and wants to help the community? I think what you want to do is leave what I call a bread crumb trail of your awesomeness on the internet. And that can include Stack Overflow. And that's an argument for using your real name or a consistent handle like I use coding horror. But you could use your name. You could use whatever you want. But leave a bread crumb trail whenever you participate and say, look, you know, I've done these cool little things all over the internet. And they're all connected to me. And over time, that's how you build a reputation. Just make sure that you're using a consistent handle, consistent avatar, so people recognize you. And searches will link to you. And that can include things like blogging. That can include, obviously, Stack Overflow. That can include Twitter. I mean, really, anywhere you have an online presence that's public, just endeavor to be helpful and useful to other people. And people, over time, see that. And they will recognize that in you. And you can point to that as your track record. OK, I think that's a very good advice. The next question we have is from Lakshmi Kanth. He's asking, how do you handle repeat questions? Especially, let's say, I found something on Stack Overflow, but that seems to be outdated. And there's been no more activity. Should we start a new question, or should we try and revive the existing question that's up on the Stack Overflow? That's a difficult problem. I would say it depends how close the question is to what you're asking. If you feel like the question is, let's say, I don't know, 80% to 90% what you're asking, I think you should try to get that question answered. Like, you should try to answer the question. Like, move the ball forward. You're playing a sports game. It doesn't matter what sports game. Let's say cricket, because I'm talking to people in India. You want to move the ball forward, right? So moving the ball forward means trying to answer the question. Say, look, I really tried. I have a similar question. Here's my attempt to answer this question. Here's how far I got. Here's how far I was able to move the ball. And it may not be far enough. But again, what can you do when you move the ball forward? Again, you can click the most important button in Stack Overflow, edit. You can go in and edit the answer. And that will bump the question, right? And it provides information that is so critical. Like, move the ball forward. Now, if you feel like the question is only 50% your question, I think it's OK to ask it a question. It's just a judgment call at that point. But I would say, don't be shy if you feel like, wow, this is really my question. This is so close to my question. Post an answer that moves the ball forward and just will take it from there. That'll bounce the question. And it'll give information to other people. And going back to the first question that I was asked, that information will have your name next to it. So people will look at that name and think, hmm, here's a person who tries to help and provides information, right? That's the kind of person I want to work with, honestly. So yeah. Cool, all right, thanks. The next question I had is from myself. At what point did you guys decide to add some gamification elements into Stack Overflow? I think really when I've been trying to do similar things and some of the things that I've been trying to do. For example, for the submission system that we had where speakers can go in and submit the proposals, I tried to add some of the gamification elements, voting and having leaderboards and giving reputation points and things like that. So the really good proposal has kind of come on the top, selected by the community. And I've really used Stack Overflow as one of the role model or reference model for how to get gamification right. So my question to you is, at what point did you guys decide to include this? And what was your biggest aha moment when you did that? I would say really it was from the very beginning. When we set out to do Stack Overflow, I realized that I wanted certain behaviors. And I thought, how can I achieve these behaviors? And I realized that video games, like the way video games motivate people is really effective. And it's fun. And I thought it should be fun to do the right thing. It should be entertaining to do the right thing. So really from the very, very beginning, we were looking at voting, achievements, all that stuff was in 1.0, the private beta even, of Stack Overflow. And as far as the biggest aha moment, I would say it's that Stack Overflow became very strict. People often complain that Stack Overflow is very strict. Stack Overflow closed my question. Now we call it on hold now. So you put your question on hold. So there's a certain strictness. And there was some strictness there from the beginning. But as the reputation numbers went up, other programmers realized that I don't want other programmers getting reputation scores higher than mine for posting a cartoon, for posting something that isn't good programming. That is offensive to me and my reputation score. So they became very strict. That was not predicted. Now I don't necessarily object to it. I will say that Stack Overflow is a little bit stricter than I wanted it to be. And Joel, when Joel and I sat down to design, we did not anticipate it being this strict about what it would allow. I do think that as communities get very large, you have to be stricter. Because you have big city problems. When you have big city problems, you have to be strict about how you approach them. It's not like a small town where you have one person that does the wrong thing, but you love them because they live in your town. But if you have a city full of people like that, it becomes a disaster. So we have big city problems on Stack Overflow. And it did become very strict. That's the number one unanticipated thing from the reputation system, the strictness. Cool. All right, thank you. I think we've pretty much exhausted the questions we had. We have just like two minutes left. And I thought we can quickly ask one last question to you, Jeff, about what is your plans right now with this course? I know you've been working on this course. So what's your current plan on this course? Well, remember how I mentioned that Stack Overflow was very strict? Well, discourse is a system where we are not strict. And you can talk about anything you want to talk about. Discourse is essentially word press for forums. So when someone says to you, hey, I want to start a blog. Well, first of all, that's awesome. You should definitely start a blog. People have blogs. And then the next word you're probably going to say is word press. Because when you think blog, word press has such a good ecosystem. It's free. It's open source. Anyone can use it. It's really easy to get started. And they even do hosting, right? Word press. So when people say to you, hey, I want to start a community. Or I want feedback on my project. Or I have a Kickstarter. And I want my community to have a place to go. Then hopefully, eventually, I want people to say, hey, you should use discourse because it's free. It's open source. And it works really well at hosting communities that want to be social and talk about things. Where Stack Overflow and Stack Exchange were really schools. Discourse is more like a restaurant or a club that you hang out at. It's not necessarily about learning, which Stack Overflow and Stack Exchange are so much about learning. Discourse is more about, hey, I want to be social. I want to hang out. I might learn something. That's cool. I'm not opposed to that. But I'm really there because I want to have a good time with my friends and people that could be my friends. That is what discourse is about. So anytime you would have a forum type situation, hopefully, eventually, you would think of this glorious, glorious logo here. Discourse.org. All right. Thanks a lot, Jeff. I think we've just finished one hour. Pramod, did you have any questions? I'm pretty much done. And I would like to wrap it up unless you have something to chime in. No, I had no questions. But I wanted to thank Jeff for the awesome advice and the help that he has provided to the community over the years and the years in the future that he will provide to the community. So thank you, Jeff. Well, thank you. And thank everyone. Because really, if Stack Overflow works, it's because our fellow programmers make it work. So I think all of us are part of the solution. And I'm happy to have built Stack Overflow, but it keeps working because we click the edit button. Thanks again, everybody. And I hope this was really useful. And please do look up the entries I talked about. The John Skeet had asked questions is really great. All right. Thanks a lot, Jeff. I think your time was really valued. And this is our first broadcast. And I'm really happy it went off really well, whereas trying to do this very first time. We have a few more in the future. We have quite a few, five more lined up at this point. We are doing one every week. And then that basically lines up to the upcoming 2014 Agile India conference, which is really our annual conference. And this is our 10th year of doing the conference. So this is kind of a special edition thing we are doing for the 10th year of the conference. And thank you for being part of it, Jeff. That was my honor. Thanks for inviting me. Bye, everyone. Bye. Have a good night. Bye-bye.