The StackOverflow Podcast

Spolsky: Hey Jeff.

Turkey: gobble gobble gobble.

Spolsky: I got, guess what that is.

Atwood: It sounds like a chicken.

Spolsky: Close.  I'll play it again.

Turkey: gobble gobble gobble.

(pause)

Atwood: I have no idea.

Spolsky: Oh man, you really are off of the whole like work, calendar, schedule with everybody else.

Atwood: Oh, turkey, OK.  Alright.

Spolsky: It's a turkey.

(laughter)

Spolsky: I'm going to play that a few times during the episode.

Atwood: That's great.

Spolsky: The special thanksgiving edition of StackOverflow, StackOverflow episode 31.  Can you hear me OK?

Atwood: I can hear you OK.  Why, did you change something?

Spolsky: Yeah, I had to change everything, you know why?

Atwood: Why?

Spolsky: Well, I've got 2, I needed to upgrade my hard drive and I've got two of these audio pre-amp thingamajiggys plugged into USB ports and so I unplugged all of my USB cables, upgraded the hard drive, and plugged them all back in, but I guess I plugged them into different plugs than they were plugged into before.

Atwood: Oh, yeah, I love that "feature" of USB.  Maybe that's a Windows implementation.  I don't know.  I don't know if the Mac does that or not, but if you plug something into a different USB port, it has to discover it again.  It's like "Ooo, new device."  You're like, "Nooo, not really a new device." (chuckles)

Spolsky: No. I'm pretty sure it's a part of the USB spec that every port is...or maybe if it can't identify every device uniquely for some reason it just hopes that, you know if you have two of the same thing?

Atwood: Yeah.

Spolsky: A serial number you can get over the USB?  

Atwood: Oh, I see. It can't tell.

Spolsky: It just goes by the position. So anyways, so they were all wrongly configured and I had to tear everything apart in this whole gigantic configuration with all these mixers and stuff like that.

Atwood: Right.

Spolsky: And I looked it up and for some reason you know how usually when you take apart an engine and you put it back together there's a kind of critical-looking bolt (laughs) that you're left with? [Is Joel a Tim Allen fan?]

Atwood: (chuckles) I've never actually taken anything of that complexity apart but I know the feeling.

Spolsky: (laughing) Well I have the opposite problem. I had to use an extra preamp to get it to work.

Atwood: You had to add parts.

Spolsky: With four premixer preamp thingamajiggies.

Atwood: Yes.

Spolsky: And to get it to work again I now have five.

Atwood: Wow.

Spolsky: And the recording is different. It records you on a different track than it records me which is the way it was intended to work.

Atwood: Yes.

Spolsky: Then I can either cut you out or I can take everything you say and move it like a half a second forward in time.

Atwood: You can move it up an octave though, it'd be funny.

Spolsky: (laughs)

Atwood: So you're talking to Mickey Mouse. That'd be great.

Spolsky: (excited) I'm gonna...I have a button here to do that! I just don't know how to use it. What if I could do that right now?

Atwood: I think the Mickey Mouse tone would be appropriate. People were very unhappy with last week's discussion of NP-Complete. And I blame me, mostly.

Spolsky: Oh, it's my fault too.

Atwood: Well, you're not totally blameless but I think that I am very unsophisticated, so I think I owe people an apology for that. But I want to clarify too because some comments came up in the podcast notes that were actually A) funny and B) correct, and one that I particularly enjoyed was, "Learning about NP-Completeness from Jeff is like learning about Irony from Alanis Morissette".

And I saw that you responded to that with a video which I then watched, about some Irish comedian doing a whole bit about Alanis Morissette and irony.

Spolsky: Yah.

Atwood: In whatever year that was. God that was a long time ago now.

Spolsky: Who is that? Who is that guy?

Atwood: Ah, I don't know. I'll have to look it up. But it was a funny bit. I'll link it in the show notes for sure.

There's some truth to that.

And somebody else had a comment of, "It's like wow, Jeff doesn't really know math," and that really is true. And I've been very open about that. Because I don't know if you remember this meme that went around, I'm sure you didn't do it but a lot of people did, it was like Five Things You Didn't Know About Me. Do you remember that?

Spolsky: [Still thinking about the Alanis Morissette comedy critique...] It's Ed Byrne! 

I do remember Five Things You Didn't Know About Me. That was like years ago, it was one of those early...back when they actually had bloggers.

Atwood: (laughs) It wasn't that long ago. It's like maybe two years ago. But eventually I got roped into it and one of the things I put in the Five Things You Didn't Know About Me was that I'm really bad at math. Like, historically. And this shows up on standardized testing.

There was a time I was thinking about going to graduate school. So I took the GRE and this was the first time I'd taken a standardized test. It's one of those things you show scores and people decide if they want you to come to their school or not. And it's like, "Oh, I'd better study for this thing," right? I want to look good, I want to do as good as I can. So it's one of the very few tests I studied for not because I'm trying to show off but because normally I'm very lazy and I don't even bother really studying. (laughs)

Spolsky: So can they take a hundred points off your standardized scores if you don't study at all?

Atwood: Yeah, I don't think I studied for like the SAT or...I don't know. But I really studied for this one. I got the little practice book and everything. And so, even with studying, the weird thing about my score was that verbally, it was like off the charts. I mean, I'm not trying to exaggerate, but like I think I missed like three on the entire test. So it was like 99.999, it was like ridiculous. But on the math side it was like 77th percentile, which I think is kind of mediocre. (laughs)

Spolsky: I don't think I've ever met anybody that doesn't have an 800 on their math SATs.

Atwood: Really? Well, now you have.

Spolsky: (laughs)

Atwood: Yeah

Spolsky: I guess I must have.

Atwood: Yeah, yeah. So that's like a weakness that I have. I truly like -- I don't -- math doesn't really come easy to me. Like I don't look at problems and... I remember like in high school -- I had a really good high school calculus teacher actually, who I enjoyed tremendously, he's very entertaining. But, like, I could only really solve problems that I had seen before, like I didn't really get the process of which by which logic -- logic and induction, you take one set of mathematical principles and figure out all these other problems. Which is kind of what NP-completeness is about, right? You have some core mathematical concepts--

Spolsky (in a loud voice): Don't.. don't...! (laughs)

Atwood: Sorry, sorry, that's not what it's about at all. Please go to www.wikipedia.com and look up... (laughs) But in a very broad sense, in a very broad sense. And to be fair to me, like, you didn't back me up either. Like you had a blog post, you had a paragraph about what everybody -- about NP-completeness. I'll tell you, for a business partner, I felt like you stabbed me in the back a little. You didn't really have my back on that one. (laughs)

Spolsky: Yeah but you're the one with all the blog posts about how bug tracking doesn't exist, there's no such thing as a bug and (laughs)

Atwood: (laughs) I see, so was it-

Spolsky: I feel like we were equal even there, on that one.

Atwood: Yes, it's a little bit like a revenge thing. That's fine. To be fair, I don't like -- I'm going to do a little bit of follow-up, not necessarily about NP-complete, but related topics, and I felt like the definition of NP-complete wasn't really the point of that post. The point was that the workarounds for NP-complete problems are really interesting. And that's what the focus of the post was about.

Spolsky: And that would have been really interesting, if anyone had talked about that. But computer programmers are, geez, so literal-minded.

Atwood: Whoa, no no no. And I think that's fair. I mean, what I said was kind of incorrect.

Spolsky: ... they're literal minded. But it is true that there are classes of problems that seem like they should be hard, but they really aren't. So, for example, you know, we talked -- I don't know if we talked about this this time -- the Halting Problem. You know, the way the Halting Problem is defined is, you know, I can construct a program, magically, such that your program that determines if a program will halt can not work. And it's sort of a clever little program. But that doesn't mean that there aren't programs you could analyze and discover that they do halt. That they don't halt.

Atwood: Ooh. I got a good one for you, on the Halting Problem.

Spolsky: It's sort of like Gödel's proof. Oh boy. I'm going to torture you with math. The thing about Gödel's proof is that -- Gödel's incompleteness theorem... oh, never mind.

Atwood: Yeah, we probably don't want to go too far down this, cos I think we're going to piss people off. And rightfully so. But one thing that was funny, very funny, somebody posted the Halting Problem on GetACoder.com...

Spolsky: (laughs) Yeah (garbled) a lot today.

Atwood: Did you see that? That was awesome.

Spolsky: Zoomed to the top of all the sites.

Atwood: Yes, it was put up by "AlanT", e.g. Alan Turing, and you have all these companies bidding on solving the Halting Problem. "Oh, we can totally do this." Our team can totally knock this one out in, like, two weeks. So, you know, if nothing else good came out of it, at least humor. Humor was delivered. But I did want to apologize a little bit on my lack of math skills, which are tr- it is true, I mean, that criticism-

Spolsky: That's kind of weird. I don't know a lot of programmers that -- I mean, usually there's a pretty high correlation between wanting to be a programmer, or being good at programming kind of stuff, even computers in general.

Atwood: I saw it as a -- you know, that's probably true. But I always thought it was more logic than math. And it always frustrated me, places where... so, I guess-

Spolsky: Maybe you just don't like the kind of math they teach in American high schools. I mean, maybe you would like discrete math or set theory or that kind of stuff. The stuff that's like really interesting math.

Atwood: I think historically the problem has been that I just didn't really have -- couldn't really grok it at some fundamental level, like I could do it, like you could just show me a problem and I could solve that problem. But I couldn't really extrapolate that to anywhere interesting. At all.

Spolsky: The real problem that happens with math is that the stuff that you learn in the standard American curriculum, geometry, trigonometry, calculus, algebra -- and you know, it's like pre-algebra, really, it's not "algebra algebra" -- is all kind of stupid and irritating, and the stuff that you learn once you get past calculus in graduate school or with an undergraduate degree in mathematics is actually easier, more interesting -- and just kind of, more interesting and more useful sometimes, more applicable. And there's stuff like, let's say elementary statistics and probability that's a part of math -- or set theory, that kind of stuff, discrete math, linear algebra -- that is never really taught to kids. And I think if that was, they would find it easier, than say -- like, linear algebra is easier than calculus. And it actually solves classes of problems, like optimization problems, that are kind of cool. So why don't they teach that to high school kids? Why do they teach them calculus?

Atwood: I have no idea. We had some calculus in high school, but then of course you went to college, and it's a whole different ball game there. We had this field trip in high school, where we were going to visit a local company and see, you know, what sort of things they were actually doing. And our guide was this really cool guy who had gone to MIT, right, and you know, you were a college-bound high school student, so you were really interested in the whole concept of going to college and then getting out of college and using what you learned on the job. And at one point I asked him, I said that "OK, so of all the stuff you learned at MIT, what do you use in your job?" And he -- and this is a thoughtful guy, right, this isn't a doofus or anything -- and he stopped for a minute and thought, and he said, "You know, I don't think I've really used anything, directly, that I learned at MIT, on my job." And that really sort of opened my eyes about the purpose of education. I don't know, you learn a lot of stuff that's not directly applicable to what you do, yet it's valuable for background. It's kind of like the whole "learning C" thing you talk about all the time. You know what I mean?

Spolsky: Yeah.

Atwood: That's the analog. But I wonder if, on the topic of math, like with my self-admitted weakness at math, it's like when does that really come up in practical programming? I mean, I use logic all the time. But pure math? I mean, unless... I don't know. Can you think of examples of places where you have used it?

Spolsky: That I've used it or that it's been used in the history of... (laughs)

Atwood: Well, you were so-

Spolsky: The Google PageRank algorithm is definitely -- the actual way that they compute PageRank is something that, you know, mathematicians would recognize.

Atwood: Yeah, but it's not like this super-complicated formula, right? It's not even calculus?

Spolsky: I don't know what that is. Gee, linear algebra? It's something you would learn in a class on linear algebra.

Atwood: Yeah, I mean I did the hotness calculation on StackOverflow, but that's a really simple formula.

Spolsky: Well it's just a formula, yeah, but see the thing about PageRank is they have to be able to tell you, they have to be able to assign a PageRank to every web site in the absence of knowing any PageRanks to begin with. You have to be able to like look at this whole mass. Because, remember, you get your PageRank from the PageRank of the sites that point to you.

Atwood: Mm-hm.

Spolsky: And so that leaves PageRank undefined, right. And so it's this big ol' circular thing.

Atwood: I see.

Spolsky: Could you actually solve a billion equations simultaneously? I believe-

Atwood: The original Google paper on PageRank is really cool. Like, even today it's still very relevant and predicts a lot of things.

Spolsky: There's really a couple of things about Google with PageRank. One is their way of calculating that, which is the kind of thing that, it's sort of trivial to anybody who has taken a couple of courses. I mean, you probably have to take linear algebra to get a CS degree in most good schools these days. Or maybe not. But a lot of good schools will require you to take linear algebra to get a Computer Science degree. So it's just a part of the standard tool set, and it was combined with the whole idea of using citations to determine how authoritative something is. Which actually comes from, is often used in academia, where they publish these, you know, they sort of rank the professors' authoritativeness based on how often they are used in footnotes. Like, there are thees books you can buy that will show you, you know, a list of a thousand professors of neurophysiology and tell you which ones are referenced in footnotes the most often, and that will mean their ideas are presumably the most influential, and anybody that has ever seen one of these citation indexes would say, "Oh, this is kind of interesting. I wonder if we could use this." This is almost certainly where the Google guys got their idea. So they definitely took two academic ideas. And then MapReduce, of course, is something from -- I mean, it's from LISP and parallelization, but it's the kind of thing that just about everybody in Computer Science would be aware of, and not that many working programmers necessarily were aware of. So they really did pull together sort of academic ideas that weren't being used yet. But that's kind of rare, actually. That's kind of rare.

Atwood: Yeah, I'm just trying to think of any, what I consider difficult math I've used in programming. It's super, super rare for me. But I can tell you the Google PageRank paper is great. I mean, it has a timeless quality. Maybe that's what makes it all mathematical. But I really enjoyed reading through it, and I was surprised, because it's kind of old now. It's been out, gosh, I don't know, six, seven, eight years. And it predicts a lot of interesting things that have kind of come true. Because we live in a Google world, I guess. But I do recommend, anyone that's interested in PageRank, definitely read that paper. I think you'd be surprised by some of the stuff that's in it. Do we have any questions this week?

Spolsky: Oh, we got heaps of questions.

Atwood: Do you want to just jump in to one of those?

Spolsky: Sure.

Turkey:  gobble gobble gobble.

Spolsky: Hang on, that's the turkey.

Atwood: Oh, it's the turkey.

Spolsky: What kind of questions do you want to take? I got like eight. What, any kind of category...?

Atwood: No, you pick, you usually have a pretty good ear for what's a good question, I think.

Spolsky: Umm... do you want...

Atwood: Go with your heart, Joel.

Spolsky's computer: (windows error sound)

Spolsky: Oh.

Atwood: Oh.

Spolsky: "Only one copy of Audacity may be running at a time."

Atwood: I wasn't sure if that was, like, another joke. (laughs)

Spolsky's computer: (windows error sound again)

Atwood: I can never be sure with you!

Spolsky: Why, why, why can only one copy of Audacity be running at a time?

Mike Akers: Hi, Jeff and Joel. I wanted to ask you a question about how much time you think programmers should be spending in Photoshop?

Spolsky: I don't really know why... thats Mike, uh, Ackers.

Mike Akers: There have been a couple of times in my career where I've done some small things, I've been working on something and I just needed small piece of artwork to go, you know, in a particular spot, like a gradient to fill the background of a button or something like that. And when I showed it to my boss, my boss would freak out at me...

Spolsky: Is this that guy, Donny?

Mike Akers: ...because I'm not supposed to be doing graphics, this is the job of some graphic designer elsewhere on the team, who I may not even know. And, you know, my explanation is, it's better if I just did it myself because I know exactly what I wanted and it took me, you know, 5-10 minutes to do. But for some reason it kind of messes with my manager's idea of separation of responsibility or something like that. So I want to get your thoughts on what, how much of this kind of stuff do you think a programmer should be doing. Should they be doing a lot, should they be doing a little, is it a case-by-case thing? And also, what was my manager thinking, to make him react this way.

Spolsky: Yeah yeah, ok - um - you know how that sounded like? Have you ever seen that video on YouTube - "You suck at Photoshop"? 

Atwood: I have.

Spolsky: That guy Donny. Somehow that really sounded like him.

Atwood: I don't know his voice.

Spolsky: I don't know.

Atwood: But, to answer the question, I actually have written a blog post about this, and I don't think you have to be a graphic designer per se, but what I think is important is that you have to be -- you don't want to take on too many external dependencies, you know, if you're at some point in the code where you just need some filler graphic, it doesn't have to be awesome, right? It just has to be good enough. So the people will look at it and go, "OK, that's what you're trying to do." Versus looking at it going "That makes no sense at all, I have no idea what's going on on your screen, I got to go." So in order to move forward with your work, you have to have what I consider a minimum level of competency with a graphical editor, like Photoshop or Gimp or Paint Shop or whatever it is you use. I'm not saying you need to be a graphic designer, and the other thing that I would say about that is, you need to be relatively good at copying things, right, like, you know, there's that famous (something), you know, good programmers write, great programmers steal? Well, I think that applies triply to design.

Spolsky: (laughs)

Atwood: No, seriously, it does. If you're trying to design something, just go copy the crap out of something that you like, that's good, right? I mean, don't sell it commercially and be a jerk who steals other peoples' stuff, but if you're just working to do something internally and just trying to mock something up, just copy.

Spolsky: OK, I'm glad you added that caveat.

Atwood: Yeah, just copy the crap out of something. To start with. And then add your own tweaks over time, obviously, so there's sort of more of an end game here. That would be my recommendation. I'm a big believer in the multi-talented programmer. Like I don't kind of really like working with those programmers who, once they reach the edge of a discipline, like, "Oh, that's as far as I go." They just stand over the abyss and look, "Yep, I can't possibly create a gradient. Because that's designer work, and I'm not a designer." Or "That's database work, and I'm not a database guy so I can't do that." I just get very frustrated with people like that.

Spolsky: I'm totally with you. And especially, you know, when you're just starting a little company, you kind of have to wear many hats. You may have to do the first design iterations of your website. But I was sort of reading behind the lines here, between the lines here. Is this guy really asking -- what he said was "Why did my manager make me -- yell at me for doing my own work in Photoshop?" And there's sort of like two interesting questions, there's like the surface level which is, uh, well, I don't know, maybe the graphic designer is better than you are, designing things graphically. Or maybe the graphic designer is paid less than you are, and their time is cheap. But the second level is like, "Why are you asking us what your manager was thinking?" (laughs) I mean, we don't know. What kind of a dysfunctional place are you working where your manager yells at you for making images in Photoshop and then you go find some guys on the Internet and ask them to read your manager's mind and say "What could my manager have meant by that?" I don't know.

Atwood: You're taking it awfully literally. I mean, I think he's just asking about, you know, what sort of disciplines a programmer should know. Is it reasonable to take a programmer and say, "All you do is programming. You're in this little cubicle, your veal-fattening pen, your code-fattening pen, and output is code. Anything other than code comes out of there, you get a beating."

Spolsky: I think sometimes, you know, people are not necessarily aware that the designs they're doing in Photoshop are ugly. They may not get why what the graphic designer does is so much nicer than what they do. Or not. It may be the opposite.

Atwood: Well, that's fair. And I wouldn't expect that a programmer necessarily have good taste. And God knows that my taste isn't necessarily the best. But I don't know. I thing you should be good at stealing stuff. I think stealing stuff is a really important skill as a programmer. So as somebody who can't figure out what a good design is to steal, I'm already thinking, "Hmm, if they can't figure out good what a good design is to steal, can they really figure out good code to steal?" It's just such a basic, fundamental skill as a programmer. You know, never write what you can steal. And if you can't sort of figure that out on a design basis then, I don't know, it's really suspicious to me. But maybe there's no transference. I don't know. It's just a gut feeling.

Spolsky: Here's another real short question.

David: "Hello, I'm David from the UK. I was wondering if you could talk about how you handle status reports at Fog Creek to stay up to date with what your development teams are doing. Thanks."

Spolsky: Um. Status. Stat-US reports.

Atwood: Yes, Yes.

Spolsky: We have a variety of stateful status, status reports. The main thing is a thing we call the weekly Kiwi, which is just a wiki page where on Friday, before everybody goes home, they write up a summary of what they did that week that they want everybody else to know about. And, there's no requirement that you do anything, and sometimes people just put a little a little funny cartoon there, and sometimes people actually talk about what they did that week and what they hope to do the next week and so on. And that's the main thing. The only requirement I have is that people that are in charge of a project have to tell me where that project stands and whether - when it's going to ship. I mean, I've never gotten anybody to do this exactly but what I really want to see is "Fogbugz 7 was scheduled to ship on such-and-such a date at the beginning of the week, and at the end of the week we think it's going to ship on such-and-such a date and therefore that is a slip of 5 days" which is pretty much what it always is every week. That's kind of what I want to see, but there's a little bit more detail in there.

Atwood: Joel, ask me for my report. Go ahead, just ask me.

Spolsky: When is StackOverflow's--

Atwood: Six to eight weeks. Six to eight weeks.

Spolsky: Six to eight weeks (laughs).

Atwood: Six to eight weeks, that's the rough... yeah.

Spolsky: No, because then I would come back every week and I'd be like "Five to seven?" "Four to six?"

(Atwood laughs)

Spolsky: "Three to five?"

Atwood: You'd realize that the number always stays the same. You don't get it.

Spolsky: No, I was shortening it. I was shortening it on you and at one point I was like "so it's zero to two weeks".  And you're like "No, six to eight. Six to eight."

Atwood: Let me... I'm joking, obviously, but let me ask you... I like the idea of -- one theme that I'm seeing here, that I like, that I hear about sometimes is, when you create status reports that are sort of not really meant to judge people, but meant as like, just a public wall, so that other people who may be interested in what you're doing or curious as to what the company as a whole is doing could look at this, right? Is that what I'm hearing?

Spolsky: Mostly, and it's also just a sort of, give me a feeling that there's motion going on even when... Because otherwise, every week or two, I'll go over there and I'll be like "What the frigging frick are you guys doing?!"

Atwood: Right. That's great, because I think what makes this work, and what makes it good, is that when you start using status reports as a bludgeon to beat people, like "Give me your status report, you better show progress, otherwise, you know, you're not going to get a bonus or whatever." That's when it gets weird. Because then people just start writing status reports to make themselves look good. They don't really write what's really happening or what they're thinking, they write what they think will get them a bonus at the end of the year or avoid a beating from the manager. (laughs) And I love the idea. And I've seen this expressed before on various, sort of, quality reference sites for programmers, it's like: "treat it like a status wall." Where everybody just, you know, they just judge it for whatever they judge it. It's not necessarily used for anything. But I think there's a competitive -- maybe competitiveness is not the right word, but -- you want to sort of show off to your peers and say "Wow, look at the cool stuff I'm working on," right? And that's sort of a positive place for this to come from. Versus "I want to avoid a) a beating and c) I want to get my bonus at the end of the year." I think that's really smart. And actually, when I worked on my previous job, one of the things they eventually instituted was, like, a weekly stand-up meeting where people would just talk about what they were doing. It was very informal, but... I'm not going to say that came from me, but I was one of the people that asked for that. Because I really didn't know what was going on at the company. Once you get to, like, 20-30 people... and how many people are at Fog Creek now, Joel?

Spolsky: 20-30... it's actually almost 30.

Atwood: Yeah, it's hard to even tell what's happening. It's hard to even know what people are really doing, or working on, and you're invested there, you work there and you're really curious about it, so just from a curiosity perspective if nothing else, from your coworkers, it's nice to hear that stuff.

Spolsky: There's another thing we did -- oh by the way, I should point out that the CoPilot team, which is just four guys, four... sorry, three guys and a gal. Four people on the CoPilot team. And they instituted daily stand-up status meetings. Amongst themselves. And that was sort of a reaction to -- there's a blog post about that you can find on the CoPilot blog, in the last few days one of them wrote up a little interesting blog post about -- but that was sort of a reaction to -- one of the developers kinda got off track, and spent six weeks in a Moby-Dick-like effort to solve a bug that, if you had thought about it for five seconds, was code that you didn't have to write. There was another way to do this. And he was, like really really deep, trying to... (laughs) The metaphor is like, you're trying to get a splinter out of your finger or something? And basically you just gouge and gouge and you know it's still in there, and you're just gouging away at the skin, and the muscle is starting... and your finger is all bloody...

Atwood: Oh, that's disgusting! All right, I get it!

Spolsky: Six weeks! And eventually you're like, "You know, I'm going to use -- I'm going to lose the use of my hand here! Better just live with the splinter!" It was sort of that kind of thing, and then, in perspective, he talked to some people. And we said, "Wait, why are you even doing -- why do you need to do it this way? Do it that way and then you won't have this bug because you'll be using completely different code." And he said, "Oh. Yeah, that works too." And it was kind of a -- in order to prevent that kind of obsessive compulsive, like going in one particular direction where any reasonable person, if you just talked to them for a little bit, would tell you "Wait, stop, there's an easier way." They instituted these quick, very very quick daily stand-up meetings for their team. So that's another kind of a status report, and the third thing we have is like a company chat room kind of twitter-thing. It's not twitter, it's something called...Laconica? Is that what it's called? It's like a...yeah, Laconica. It's like an open source version of twitter that you can download and install on your own internal server so it's all secret. And then we have people run something like twirl on their desktops and it's sort of like this company chat room where you can just sort of put some status in there, but bizarrely enough there was kind of a splitting... The original goal of that is it was a neat place to announce anything new that you didn't want to forget in your weekly kiwi. If there's something you wanted to tell the company you didn't have to send email to 30 people and interrupt them and give them a useless email just to say, you know, "there's some new soybeans in the fridge." It was also a way to say, "hey, I just got this thing working" that you might forget on your weekly kiwi status report on the weekly kiwi. But it sort of also turned into kind of a chat room where random people post sort of random links to humorous websites showing pictures of cats doing things--dreaming about cheeseburgers, and so on. That's a little bit less useful.

Atwood: Wait, there's pictures of cats somewhere?

Spolsky: On the internet? (laughs) Apparently.

Atwood: On the internet? 

Spolsky: Yeah there are cats. (laughs)

Atwood: It's like words...that make it funny?

Spolsky: Yeah, yeah, yeah...yeah, exactly.

Atwood: Oh, ok. I'm going to look into that.

Spolsky: Check out...uh...you gotta...you have to...*bah* you have to spell everything wrong, or you'll never find it.

Atwood: (laughs) Does every team do daily stand-up meetings?

Spolsky: No. That's just a Copilot thing.

Atwood: Ok. And then this Laconica, this internal twitter thing, that's interesting. That makes sense because you know normally I'm a fan of, you know, doing things in as public a way as possible. Obviously you are too; I mean, you're a master of it. But I agree that sometimes for internal stuff that doesn't really work. Like you can't really make some things public that (laughs) would just be a) too much detail and b) weird, right? So I can understand. And the other thing that might be interesting there is with twitter there's a little bit of a desire to perform. Like, because you're performing for a public audience, you feel like you have to actually perform a little bit--(laughs) maybe that's just me!--but you have to be careful what you put up there, whereas on an internal one, the bar is not quite as high. Like, you can just put up some mundane thing that happened and you wouldn't worry about it too much. You wouldn't say "oh, is this really interesting to everybody?" It doesn't have to be, it just has to be interesting within Fog Creek. So, I think that makes sense. Are you seeing lots of use of the Laconica?

Spolsky: I'll tell ya what's going on there...I mean, there's about 18 things in just the last 3 hours. Like, there's a bunch of people talking about that thing that you just mentioned, with the halting problem that somebody posted to the rentacoder's site. So there was a bunch of people pointing to that. Gillian is announcing that there will be no "Waffle Wednesday" tomorrow, which I'm really disappointed about.

Atwood: What? No waffles? That ain't right.

Spolsky: Yeah, we usually have waffle Wednesday as the last Wednesday of the month. Maybe it's some kind of a Thanksgiving issue. And then there's a...

Atwood: Wait! No, no, no...I blame the economy, Joel. Let's blame the economy. That's what we do here.

Spolsky: (laughs) We're cutting back!

Atwood: It's all about the economy.

Spolsky: Cutting back! Cutting back on waffles!

Atwood: The economy is so bad that you can't have waffles now. Oh my god!

Spolsky: Remind me to take a question about the economy next, that'll be a good segue. There's somebody asking for a mini-USB cable. There's somebody answering that person. There's somebody bragging about a new feature they just finished implementing. And that kind of stuff.

Atwood: well that's interesting, I've never really thought about the idea of running an internal Twitter. You know I'm a huge Twitter fan, I use it for all kinds of things, and it's been very useful. I think that it could scale down to a company, I think that makes sense, it's very clever and smart... cool.

Spolsky: in some ways it feels like a company chat room, except that you don't really reply that often. it's not like back and forth, and back and forth, and back and forth. It's sort of a way to ask a question you know it won't interrupt people, you know it won't sit in people's inboxes forever, demanding a reply.

Atwood: yes, that makes sense. and then the funny thing is that if you become internet famous, like if you're Guy Kawasaki, you can do stuff like post on Twitter: "I need a USB cable." And someone will come, wherever you are in the world, and give you the thing that you wanted, which is hilarious.

Spolsky: The thing is that people like Guy Kawasaki or I don't know who it is, that are promoting Twitter. And you, actually, that are saying "oh, Twitter's great" ...

Atwood: What? I like it..

Spolsky: ...I know, I know, let me finish the sentence - I think that you guys are using Twitter differently than 99.999% of Twitter users, because you're celebrities, and most people are not. I don't know how many people are following you on Twitter, but you're probably in the top 20...

Atwood: No, no, no. I'm not in the top 20.

Spolsky: top 25. Top 1%.

Atwood: You're right, that's true of a broad set of things that you do on the web. If you're on Facebook, for example, and you're Joel Spolsky, so your use of Facebook is going to be different than anonymous programmer guy, that uses Facebook too. So I think that's a normal progression. I think you're right, I have to be careful when I talk about why Twitter works for me. I can post a question and get an answer, but if nobody's following you and you're a new Twitter user, you can't ask these questions.

Spolsky: So all the Kevin Roses of the world and Leo Laportes all bragging about how Twitter is great - you're seeing it from a very, very different perspective than regular users.

Atwood: I do think there's spillover... For example, if someone asks me a question on Twitter as a direct response, it doesn't really matter if they're famous, if they ask a good question or they say something interesting, I will respond to it. A long time ago I brought up this analogy, and I think it still holds: It's like being at a dinner party.  You're at a  dinner with Guy Kawasaki, there's going to be a crowd of people around Guy Kawasaki. But that doesn't mean that you couldn't strike up a conversation with either Guy Kawasaki, or someone who's talking to Guy Kawasaki...

Spolsky: about Guy Kawasaki! You could be like: "Hey! So, enough about me, what do *you* think about Guy Kawasaki?"

Atwood: yeah... I think it does have advantages for anyone if you start becoming a part of the conversation, it's kind of cool. But you're right, I think both are correct.

Spolsky: Let's take another question. We sort of talked about the Waffle Wednesday scaling back here at Fog Creek. But all we really did was push it to the week after Thanksgiving. So I don't really know if that's such a big cutback. There will probably be two Waffle Wednesdays in December. (pause) Maybe not. I don't know what's going to happen. What day is Christmas?

Atwood: Uh... December 25th, right? I have no idea.

Spolsky: Let's take another question

Matthew Glidden: Hi, Joel and Jeff, this is Matthew Glidden from Cambridge, Massachusetts, and I have a question about management in lean economic times. Do you favor one way of going after people who are perhaps getting cut from other companies, the time when they need to downsize, when they need to trim costs where ever they can. Do you find it more effective to try to maintain your own people at the expense of any fringe benefits you might provide? It'd just be educational to find out from the perspective of smart people who get things done, and also from the perspective of thinking the people you might have to let go have this opportunity to go and start their own businesses during these down times. Thanks very much.

Spolsky: That was one of those questions in which we have to talk about the headlines and all the cutbacks and so on and so forth.

Atwood: Well, let's make it very specific. So I know we have talked about this, and you know, it's not cool to talk about actual numbers and stuff, but basically you guys are doing fine so far, I mean as far as the economic downturn, but let's play what-if. Like what if your revenue got cut in half.

Spolsky: Oh my god. Aargh! (laughs)

Atwood: ... what if (laughs) ... and it'd stay that way for a long period of time. What would you... how do you... I know it sucks, but...

Spolsky: OK, the Waffle Wednesdays would just be completely cut out!

Atwood: Yeah. So what's your strategy for dealing with that, like over the long term, like how would you -- it eventually comes down to personnel, right? What's the number one expense, it's paying people. Although you have awesome people to do awesome work, but if you don't have the money to pay them, what's the strategy there? What would be the worst case scenario?

Spolsky: Um... I don't know. Well, you know, we do sort of know. One thing which I'm  sure is going on out there, you're hearing a lot about layoffs, and I won't name names, but a lot of companies that are laying off 10% or 20%, especially in the startup community where their VCs have told them "you have to lay people off" and, you know... for example Valleywag was shut down. And honestly, I don't think that the economy has anything to do with that, although there is an economy issue right now. I think that it's a really convenient excuse to get rid of the 10% of the people that you have, that you wish you could fire, but you felt bad about it. I mean people really feel bad about firing and laying off people that are not working at 100% of their potential. Or 100% of the potential of somebody that could fill that job. And in good times those people just get to keep their jobs, even if they're not doing the best possible work. And that's fine. And, you know, that's OK. But when a recession comes along, or some kind of... there's a lot of news, I think an awful lot of businesspeople use that as an excuse to sort of "clear away the dead wood". They say "well, you know we're in very very hard economic times, I'm afraid we're going to have to cut 10% of you" and they always do it and for some reason the people that are cut... people are depressed but the company continues to earn about the same amount of money as they did before and suddenly you realize that those 10% were the 10% that weren't adding much value to the bottom line. So I'm not saying anything specific about Fog Creek, because we have excellent people here.

Atwood: Right, I don't think you guys have that kind of a buffer. I think that's an expensive buffer, right? That's like... if you have it, great, but I don't think you guys have that.

Spolsky: Well, there's all kinds of... any developer... I don't want to put this in terms of Fog Creek, because it's not true and it doesn't really apply to our situation, because we really are making so much more money than we are spending, that we're not even close to having a problem, but if a software company did have a problem, a typical software company like Fog Creek, which is, let's say you're breaking even, you have much developers and you have some tech support, you have some sales, you're paying for an office and that's about it. That's kind of what your life is like. And you know, maybe you do a little advertising, but none of that adds up to anything, it's really the office and the people. And if you're just breaking even, and your sales go down by 20%, then you're going to have to cut 20%. There's no two ways about it. So one way to do that is, you know you have developers who are working on a version of software that your customers don't have. And I hate to say this, but that's optional. It's important for the future, and that's an investment, but if you don't have the money to invest, then you can't vest... (laughs) you can't invest it. You know, I'd love to be able to take an extra million dollars right now and put it into some of these really really underpriced securities that are available on the market because of the crash, but you know, nobody has the extra million dollars lying around to do that, so similarly, if you're a software company and you're not breaking even, you don't have any extra source of cash, all that research and development you're doing is optional.

Atwood: Right. Would you classify the next version as research and development? That's just normal progression of your product line.

Spolsky: I know. But if we stopped developing that, it wouldn't affect our sales today. It would eventually, but in the short term it wouldn't.

Atwood: So you would just postpone it? It wouldn't be like a permanent "Oh, we're never going to have the next version of FogBugz, we're just going to push it back a year or something." Because you're right, I mean, looking...

Spolsky: We're so far from doing that that it's not even relevant, but honestly, if our sales went down 90%, then, you know, the only contract that I really have is to pay the rent here. And I could actually sublet a large part of our cool office space. Other than that, there's really... we have to have some support, and we have to have some... you know, there was a time in the early days of Fog Creek, we started out with four people. It was really... Michael and I founded it and we hired two people right away, and they were doing some consulting work, and when the consulting gigs went away, we just had to lay off two people, and then it was just me and Michael. And then everything slowed down dramatically. But we survived.

Atwood: So by the time it got so dire that you were letting people go, I mean, it would be, that would be the end, pretty much? That's what I'm hearing.

Spolsky: Yeah, our revenue had gone... It's sort of hard to tell, because it was just the first few months, which was kind of weird. We had like a few big consulting gigs that comfortably paid for several people, but then those just disappeared. A 100% of those disappeared and all we had left was the FogBugz 1.0 revenues, which were minuscule. Five thousand to ten thousand a month. So we really had to cut back to just the two of us. Back then.

Atwood: Well, it's your extravagant waffle budgets, I think that's the problem.

Spolsky: But those... I don't even know who pays for the waffles! You know, that stuff doesn't add up to hellabeans, all the... even the office space. Somebody sent me an email asking, you know, how do you justify all that beautiful office space at Fog Creek, and...

Atwood: Wait, wait! You're answering an email question?

Spolsky: ... no, this was a private email question.

Atwood: OK.

Spolsky: Although if somebody were to call in with audio, that would be awesome. To ask that question. But it's too late. How do you justify... the truth is, I don't have to justify anything to anybody. So, you know, F U. (laughs) It's kind of I don't have any investors, as long as me and Michael want to do something, we can do whatever we want.

Atwood: OK, having been to the Fog Creek office, and having worked at another very cool office, it's just worth it. I mean if you're not smart enough to understand why it's worth it, then you just don't get it. I mean, I'm sorry (laughs) but that's just kind of how it is.

Spolsky: Well, I have a glib answer that I give people. Or a slightly less glib answer. Number one, it's a recruiting tool. And if you can get those great "tenfer" programmers, the programmers that are ten times better than everybody else, because you have the nicer office than the guy down the hallway, it's worth it. That pays for itself with one great programmer.

Atwood: The other thing that's weird about the question is like, "well, why do you live in a nice house, why not just live in a total dump." It's just, I don't even get the logic there.

Spolsky: (laughs) Yeah, you could save so much money just living in a dump.

Atwood: Just move into a shipping container. Why even have walls. It's stupid. What a waste of money. It's like, you just kind of scratch your head and go, "I don't know, maybe you should do that."

Spolsky: Think about where this question is coming from. It's obviously somebody who has outside investors. And the outside investors are putting pressure on them to appear... or to be frugal. And office space feels like an extravagance. So the second thing I want to say -- the first one was "recruiting tool" -- second of all, there's the added productivity of having developers in private offices with doors that close. And that's a well-established fact. Merely because I say it is. (laughs) And number three is that it's not that much money. Most companies spend about 5% of their annual revenue on their office space. That's pretty close for a software company. 5% of your revenue for office space. It's a pretty reasonable number. And the difference between the spectacular office space and the cramming them into cubicles is a question of whether... it's 4% versus 6% of your revenue. And you better have margins that are bigger than that, as a software company. You're not Amazon.com. You're not a retailer with razor-thin margins. You're not, you know, Target or Wal-Mart trying to be frugal. You're not Southwest Airlines, where showing that every penny counts is really important. You're a software company, and you kinda have to have big margins, and every additional copy of software that you sell costs you zero extra. So it really shouldn't be that big a deal on your bottom line, to have nice office space.

Atwood: Yeah, I agree. Hey, speaking of which, when are you going to have... when do you think the photos of your space will go up?

Spolsky: I've been taking them slowly. I can put them up you know... soon.

Atwood: Oh, soon. OK, cool. Obviously you have a blog post about that, I was just curious about what's going on.

Spolsky: What am I waiting for... there was one picture... oh yeah, I'm trying to get pictures of like people having lunch and people at the coffee bar and people doing stuff and that's kind of hard to get.

Atwood: You need some Kodachrome moments.

Spolsky: Right. A lot of pictures I have are very architectural, like pictures of the architecture, and I think people want to see the people kind of...

Atwood: Human beings. Overrated. Don't need'em. Just the space.

Spolsky: (laughs)

Atwood: No, I get that. That's totally cool. So do we want to go to picking questions on StackOverflow? I have one.

Spolsky: OK, yeah, what's yours?

Atwood: Okay, so one that I put in my favorites recently is... and this comes
up every now and then, it's about parameterization of SQL and SQL injection.

Spolsky: Okay, oh, yeah.

Atwood: So, just a brief background for people who don't know, so, the naive
way to build SQL is to just plop it in a string and start concatenating strings
together, right, "SELECT * FROM WHERE NAME = 'Joe'".

Spolsky: Yeah.

Atwood:  And one problem with this, and it's fairly widely known now, I would say
by most competent programmers is like, you shouldn't really do that, because,
the problem with that is, that name field is probably coming from a user input
field, where users say, oh, I want to search for users named Joe, they type
'Joe' and they press ENTER.
  Well, the problem is when the user types, "'-- DROP TABLE Users", right? And
xkcd has that very famous cartoon with "Little Bobby Tables:" she named her
son, "'-- DROP TABLE..."
  Little Bobby Tables, yeah, so, it's fairly well understood, but one subtlety
that comes up is, so the answer to this is usually parameterization, which is
basically a layer that most database libraries have that lets you say, okay,
"WHERE name = <parameter>" and parameter's a string, and then the database
library level actually handles the escaping of that string for you to make sure
that nothing, you know, no command goes in where it should be just a string.

Spolsky: There's actually an... yeah, and sometimes actually, like in the
case of Microsoft SQL Server at least, you get some real benefits,
performance benefits from doing that, because instead of executing different
queries every time, the parameter, the presence of the parameter in the query
allows the optimizer to say, oh wait a minute, this is the same query, just
with different parameters.  And so it'll use a previously-made query
optimization plan.

Atwood: Right, and let me tell you this is really, really true.  I mean I
intuitively knew this, but I was kinda, I'm kind of a skeptic when it comes to
a lot of stuff.  It's like, oh how much difference can it make?  But on StackOverflow, because we have such a high volume of queries, it makes a huge, I was
really shocked actually how big the difference is.  So yeah, if you have a
high-volume site, you want to parameterize the crap-- Forget SQL injection, you
want to do it for performance reasons alone, because it makes the query cache
much more efficient when it doesn't have to put all these thousands of copies
of the same exact query.
  Now, I sometimes get in trouble with this, but I kind of feel like--that's
true--but I kind of feel like the database should be smarter about this.  Like,
if the only thing that's changing is that string, I don't know, I just feel
like the query cache should be able to figure that out, and say these thousand
queries that I'm getting over and over, the only thing that's different is the
string, so I'm just gonna internally, any time I see that, I'm just gonna treat
it as the same exact thing. 

Spolsky:  Well, it can't really do that without parsing, and that's what it's
trying to save time doing, lexing and parsing of the query, and then building a
query plan, because right now what it looks like is it just does a very fast
string compare on the entire query as-is, to see if it's in the cache, and
that's just comparing two strings, whereas, to compare two strings, but you
know, but you know if things are within a quote, would actually require lexing
and parsing, and that could be, that could take on the order of a hundred times
more time. So it would be prohibitive to check if something was in the cache
even, if you had to do that lexing and parsing every time.

Atwood:  That's true.  At the very least, it ends up being a performance
optimization, and on StackOverflow, again, we have such volume, that we really
need to do that stuff.  Every little bit helps.  Whereas if you have a site
that only ten people are ever going to, I don't think it would really matter
too much which way you went.  But yeah, I agree with that totally.

Spolsky:  What really used to frustrate the heck out of me was that almost any
beginning "programming for the web" book that you took off the shelf, you know,
like Beginning PHP, Beginning Whatever, every single example in that book
would just be concatenating up SQL strings like wild.  It would just be every
single example was a security bug.  And even the better books would just be
like, "don't actually do this, because this is a security bug, but I'm just
doing it to show you the 'clean' way to do it."  Really.

Atwood:  Right.  Yeah, I totally, there's tons of examples, you're absolutely
right.

Spolsky: ...millions programmers were taught the wrong way to program.

Atwood:  Yeah.  Another subtlety that comes up here, is even after you're fully
parameterized, I kept getting people that would tell me, y'know I felt like
once you've parameterized, you don't have to worry too much about injection.  I
mean, maybe there's some weird edge condition, but, people kept coming up on the
comments, because I've talked about this a couple of times historically
througout the years, and they would say, "you know what? parameterization's not
enough, there can still be injection on parameterization."
  And I really couldn't figure this out, I was like well, how could they really
do that?  How could you get injection on parameterized SQL?  And finally, I did
a bunch of research, and what I figured out is it's called "latent SQL
injection," and it's a little weird in that you end up writing what you
consider to be some "safe" fragment of SQL to the database somehow... again,
it's kind of an oddball condition, I think they may be one of those things you
talk about where programmers are super-anal and they're like "oh, well you can
still inject." I'm like well, really?
  But somehow it gets written to the database as-is, and then later the
application picks up that "safe" SQL string...

Spolsky:  Like it thinks it's"safe" because it's from the database.

Atwood:  Yeah--and it's not.

Spolsky:  And it's not safe because there's a bug somewhere where somebody else used some other way to...

Atwood:  Yeah.  Well, it was parameterized, but it got inserted as-is, y'know.  I
still am not totally 100% convinced this is a realistic scenario that could
actually happen.  But thats, when you read about it, it's latent SQL injection,
so when people say that, that's what they're saying.  But in general, once you
parameterize, you've conquered, I mean gosh, 95% of...

Spolsky:  What's kind of frustrating is just how hard it is to parameterize,
especially in some languages, like, y'know, go back to, I'll use an example
that I know, VB script, to create a SQL string, I guess you gotta create a new
command, and then to put in the parameters, what you do is put little question
marks in your SQL source code, you know in your SQL statement you put little
question marks.  And then you have to run this ghastly function which is like,
command.parameters.add(), command.parameters.new(), something.  Some
complicated way where you actually construct a parameter, and then add it to
the command, and it gets put in.  And you just get this really, really bulky
and messy code.
  And partially, that's a limitation the language which doesn't give you a nice
way to do that, like for example variable parameters would even solve that
problem.  Y'know variable length parameter lists to a function, and then you
could just call a function and give it a whole bunch of parameters and it would
stuff them all in.  Sorta like printf().  But like that's a limitation in the
language.
  For some reason, the class library designers never really kind of imagined,
never really think very, very hard about what the most common things are that
you're doing and try to really make them optimal.  It's like, it took me ten
minutes to come up with a couple of utility functions you could use in VB
script that would construct SQL statements and then stuff parameters into them
in a nice, clean, elegant, and simple way.  And it's just a, yeah.
  It's never, y'know what's weird?  Whatever programming language combination
slash database access library you're using, whether it's y'know C# with ADO.NET
or just plain old-fashioned VB script, or VB, or PHP with whatever it is they
use, or Ruby and ActiveRecord or whatever, there's always four things that
you're trying to do, right?  It's this classic CRUD things.  And you almost
wanna, you read these gigantic books explaining all the eight million things
you can do, and almost wanna make yourself a cheat sheet:  Okay, here's how I
do a SELECT where I just need one value, like a scalar SELECT, and I just need
one value back.  Here's how I do a SELECT where I need a single row back.
Here's how I do a SELECT where I need a bunch of rows.  Here's how I do an
INSERT, and here's how I do a DELETE.  That's it.  Here's how I do an update.
And if you just know how to do those four things with your class library,
that's pretty much all you're going to have to do 95% of the time.  And
sometimes it's kind of shocking how developers, sorry, the designers of these
frameworks give you this beautiful framework for accessing the database, and
those four things, the simplest way you can possible get to code, is still
verbose and ugly and requires a lot of typing.
  Rant over.

Atwood:  Right.  No, that's a completely valid point.
  The other thing that comes up, and I don't know why people do this, but they
write stored procs that actually execute SQL internally.  Like, basically, I'm
just not a proc fan, I haven't been historically, and really never will be.  To
me, it's database assembly language.  Like when you need it, you know when you
need it, and most of the time you don't.  But if you write a proc that takes a
parameter and just y'know, concatenates up a string, that's really no different
than doing it in code.

Spolsky:  There's a couple of little cases, and I'll give you some examples, where
you wanna parameterize something, and they just don't let you because of
limitations in SQL.  Like SQL Server 2005, you can't parameterize the number
after the TOP, so "SELECT TOP 100", "SELECT TOP 20", and you...

Atwood:  Oh, you can't parameterize that?

Spolsky:  I think you can in 2008, but not in 2005.

Atwood:  Also the IN clause.  There's a place in StackOverflow where we use the
IN clause, and I can't figure out a way to parameterize that at all.

Spolsky:  Oh, I'll show you how to do that.  You do it by making a string, and
then you parameterize based on is this found in this string.  You put little
bars around, you use little bars to separate each of the elements and make a
string, yeah.

Atwood:  Oh cool, send that to me, I would like to parameterize that one.

Spolsky:  Let's say you wanna parameterize the sort order, like different users,
you wanna sort by different columns based on the user's sort preference.
That's one of those things that's really, it's not really possible.  And
there's no reason that shouldn't be possible, why couldn't a parameter be a
column name?

Atwood:  Wait, wait, oh I see what you're saying, the field that you're sorting
by could be technically a parameter.

Spolsky:  Like I might wanna sort by date, now I wanna sort by relevance, and then
I wanna remember that and store that.  And then later when I do that query, I
wanna see if that user's sorting by date or by relevance and if they're sorting
up or down, and I wanna change the ORDER BY.
  You can parameterize a lot of the WHERE clauses, because you can always have
a WHERE clause that includes every possible thing you might ever filter on,
guarded, based on some other parameters.  So it is actually possible to
completely parameterize everything about the WHERE operation, if you know your
Boolean logic.

Atwood:  Right, yeah, there's definitely edge conditions where parameterization
becomes awkward and/or impossible.

Spolsky:  Right.

Atwood: Did you have any questions that you wanted to...

Spolsky: Yeah, let me... let's see. Let me click on my little favorites link here, let's see if I can come up with something interesting. Oh, here's one. How do you -- and this is... what are these sorted by? Favorites?

Atwood: The last date that somebody edited something in them. Anything with newer content floats to the top. On your favorites.

Spolsky: Here's a good one: How do you pull yourself out of a programming 'slump'?

Atwood: Define 'slump'.

Spolsky: Quote, and I'm reading from DaveK, "I'm having a hard time working up the level of passion I used to have for programming. Instead of wanting to stay up late figuring out a problem, I'd rather just go to bed."

Atwood: (laughs) That's kind of a broad characterization.

Spolsky: "I really do love programming, and would be seriously depressed if I've somehow lost my spark." I think this is an extremely common problem. Extremely. Because I mean, a lot of programmers just give up after eight years. (laughs) And go into some other field, or management or...

Atwood: Really? Eight years? There's like a seven-year itch or something?

Spolsky: I don't know what it is. I just made that number up. But yeah. (phone rings) This thing goes ringy-dingy in my pocket.

Atwood: Interesting. You know, I have not really found that to be true. I think that the people that are drawn to it, that are like totally into it, like, you can't make them stop doing it. They just... it's in their blood. They just love it. They seemingly will do it forever. I really haven't met anyone that has burned out or... I don't know. Maybe that's just that I haven't had enough experience.

Spolsky: Really?

Atwood: I don't want to sound dismissive, I just haven't...

Spolsky: You're saying that you've never had like a period when you come in and you have to write a bunch of code and you'd just like be reading the internet the whole day and then you go home and be feeling sad that you never wrote any code?

Atwood: Well, usually when that happens, it's because somebody's made you work on a project that sucks. I mean, certainly I've had that experience. But I don't think it's... it's not intrinsic. It's not like me that's the problem. You know, it's the project that I'm on. It's more of an external thing.

Spolsky: Let me ask you a question. How many fifty-three-year old programmers do you know? Versus twenty-three year old programmers?

Atwood: Not many. That's true, that's very true. I mean, I don't know may extreme -- no, I don't want to say extremely old -- programmers of age fifty or older, that's true. But eventually I -- I'm not a young chicken, I'm almost 40 so... I guess it happens so... do you know programmers that have like, burned out literally? Like they just can't stand it any more, and they used to totally love it?

Spolsky: Heaploads. Most of them.

Atwood: Really? Wow.

Spolsky: Yeah. By the time they're fifty... I think it's actually kind of rare to find programmers that have been working... that have been programming for twenty-five or  thirty years. Or fifteen.

Atwood: Well let me put a caveat in. I don't mean like hardcore... like I don't consider what I do, by any stretch of the imagination, probably never... anything I've ever written has been "hardcore programming". I mean, I've solved some interesting problems, but I don't know, over time I've done the blogging thing, and I've probably turned more to the writing about programming... that the volume of my writing about programming has massively dwarfed the volume of my actual code. So maybe that's my answer, is that I guess I just end up talking more about it. I still write code, but I don't write volumes of it.

Spolsky: Yeah. I think that there is something about -- there's something kind of weird, which is like -- I don't even know the answer to the question of -- this kind of phenomenon happens to people kind of at all ages. What was that article I wrote about? Was that in "Fire and Motion" that I wrote about that? Like some days you just can't get the motivation. I think there's an article called "Fire and Motion" on my website, about that.

Atwood: Oh, "Fire and Motion" is a great article. I don't know if it covers that particular topic, but it's a great one.

Spolsky: And... I think that's what it is. I don't know. There's...

Atwood: I'm a sucker for your war stories. I love them.

Spolsky: (laughs) Uh... the... that's a shame. That's going to be like... that's going to be... I'm trying not to be the person with the whole bunch of clever stories about how programming is a war (laughs) or it's just like the Israeli army at peace time.

Atwood: I kinda want you to go back to the Israeli army. I feel like there's been a decline since you left, and I want you to go back in now. To get more stories.

Spolsky: Um. Um. Wait, I had an answer. You know, a lot of people get into these temporary slumps that they eventually get out of. And I'm just talking about, like, there was a whole week where I just couldn't get started on coding, and I just spent all time reading on the internet and stuff like that. Sometimes that happens because of like burnout. You just got off of a, you know what, in Peopleware they sort of say that, Peopleware and The Mythical-- no, sorry, Death March. The Death March, by Ed Yourdon, both talk about this idea that, yeah, you can make programmers work 80 hour weeks, and they will get done twice as much as they made -- as they did in their 40 hour weeks, but you're incurring debt. And you're going to pay back that debt in triple. In terms of just burnout and that kind of stuff. You can definitely, if you want to, spend a week when there's really a deadline, you want to make everybody work for 80 hours and get that thing done, and that's fine. But the week after that, you're going to get nothing done.

Atwood: I definitely agree with that. There's this some sort of internal balance scale. It's like, when you're working 50, 60, 70 hours a week, the time definitely comes -- you get it back. It's weird how good people are at that. At least I am.

Spolsky: They'll take it back out on you somehow. They'll get it back from you. The other thing that's true is that, you know... think about when you're really productive in programming, you're in the zone. You're in flow. You're in time... you are not aware of time passing. It's the best way to describe it. You're just cranking away, and great stuff is getting done, and it doesn't seem like any time is passing, and lo and behold, suddenly you have just completed a huge amount of work. And I think most of the good programmers that I know, or many good programmers I know will tell you that this is something that happens to them twice a week, for a few hours, and in those few hours, that's when they get all their work done for the week. There are different personalities of programmers, there are programmers that just crank away, happily, endlessly, and there are programmers that get things done in very, very productive spurts, and then they have this time when they're just kind of recovering, when their brain is in recovery mode. So the one thing about flow is -- and this is entirely attributed to Peopleware, the great book by Lister and DeMarco -- is that we don't really know how to get people into flow. It's not clear how you take somebody who's not in flow and get them in that mode of concentration and writing a lot of code. But we certainly know how to knock them out of it. There's lots and lots of ways you can interrupt flow, and get somebody out of flow.

Atwood: Whoa, wait, wait, let me interrupt just briefly, because we talked about flow last week, that was the question you picked last week. So can you draw a distinction...

Spolsky: Oh.

Atwood: ... well, that's OK. We can talk about it either way. But I'm just curious like, where does the line end. I agree with what you're saying, but I guess what I'm getting at is, how do you deal with this burnout factor. Like what's the solution? Is it all about the history, like "don't get into a position where you get burned out", like "don't work 50 hour weeks willingly for some crazy person"?

Spolsky: Yeah, you're right.

Atwood: ... how do you fix it after the fact?

Spolsky: How do you fix it after the fact. There's a couple of ways to do it. One is, a lot of times, there's this Merlin Mann who says you're like envisioning the thing being done. What you really need to do is envision the working on the thing.

Atwood: I see.

Spolsky: That doesn't make any sense. I should ... (continues to mumble in the background)

Atwood: No no no, I get it, I had a blog post like that, it's called "moving the block". It's like, you're building a pyramid. Don't think "I'm building a pyramid." Think "I'm going to move this block ten feet."

Spolsky: Yes! OK, why don't you elaborate on that. Because that's what I wanted to say.

Atwood: Well, that's really the whole concept. It's like, think about the one block that you're moving. Don't think about anything else. It's like "Oh my god, giant pyramid! Oh my god, where am I going to get all these blocks from, how am I going to do this?!" Just think "how am I going to get this block from this point to this point, today. Like ten feet. Not even like a mile. Just ten feet. Ten feet closer to the pyramid. You just keep doing that day after day after day, right? And that's how you build a pyramid. You don't have this grandiose plan, you just move blocks a tiny amount every day.

Spolsky: Exactly. If you can take some little feature that sounds like a lot of fun, you know you're going to need it -- like "Oh, I'm going to have... I'm doing this whole movement... moving files left, right, uploading, downloading, converting, blablabla feature. But I'm just going to get that file upload component to work."

Atwood: Right.

Spolsky: I know I'm going to need it, it sounds fun, and then I'm going to feel like, "hey, let me just see if I can get the file upload to work."

Atwood: You know, I still don't... I'm not entirely sure... maybe it's just the question's not... lacks sufficient detail, but I feel like, if you're like truly burned out, would you like have to do an entirely different language, would you do it like with singing and dancing, I mean, like... I don't know. I think there's some truth there. Because, let's say you're a C++ programmer. And you're doing everything in C++. And maybe your world view is just constrained by what's possible in C++, right? The whole... people always talk about when they use Ruby or Python or these other dynamic languages, it's like "oh, it totally changed the way I look at programming!" Because you see further than you could see before. In terms of... because it gives you different, better tools that give you different, better solutions. Like, at a certain point in a language you've kind of done all the mainstream stuff you're going to do with it, right? I mean, you've used all the basic data constructs, all the basic keywords, I mean there's always new stuff, but like... I don't know. It's like learning a different language. And different, you know. Spoken language. You just maybe think a little bit differently based on that. So I don't know, maybe that's another approach, like, just learn a different language.

Spolsky: ... or find something altogether different to work on. There may be other reasons... it may be that the pyramid you're looking at... it may be just a lack of a spec or a lack of design, so you feel like it's overwhelming because you haven't broken it down and figured out what you're going to do.

Atwood: I would really urge people like not to blame themselves. I know that sounds self-serving, but I really think it's true. I think most people, particularly programmers, are very intrinsically motivated, right? Like we're highly driven to do the things that we do, so when you wake up in the morning "I've got to... I don't even want to go to work any more. I don't want to work on this any more." Seriously, it's probably not you. Really look at the external things in your job, in your life first before blaming yourself, right?

Spolsky: ... when in doubt ...

Atwood: ... maybe you suck. I don't know. It's always possible. You can't rule it out. But yeah, look at external...

Spolsky: ... when in doubt, try more coffee.

Atwood: Yes. Caffeine is always a good thing. We should probably close it up here.

Turkey: gobble gobble gobble.

Spolsky: Let's close it up with the turkey, for Turkey Day coming up on Thursday. This is the Turkey Day edition of StackOverflow, episode 31. I'm your host. And so is Jeff. We're your hosts. What do we say at the end of the show? Why don't you do the end of the show? I'm sick of it. I've forgotten all the things to say.

Atwood: So we have a telephone number that people can call...

Spolsky: I'll start looking that up while you close everything else up.

Atwood: Look that up. If you want to ask us a question, we're trying to get better at answering user questions, we do appreciate user questions so please send them in, particularly those thoughtful ones that are going to make me argue with Joel, and make one of us look bad. Because people seem to enjoy that.

Spolsky: Yes. Something where one of us looks like an idiot, and... preferably Jeff. And the phone number is 646-826-3879 or you can record like an mp3 file or an Ogg Vorbis file -- and those actually work the best, because they sound great -- you record those and you send them to podcast@stackoverflow.com

Atwood: And then don't forget to mention your name. When you do the recording. So I can cite you properly.

Spolsky: Oh yeah, say your name, and spell it if it's weird, because otherwise we'll just spell it wrong when we write it down. If you're just like "My name is (incomprehensible)" we're not going to get it down right.

Atwood: Have really simple names. If you could have a simple name like "A" or "B", that would be ideal. "Hi, I'm A B from Calgary and I have this question." That would be awesome.

Spolsky: "A" from Calgary would be "E H", right?

Atwood: We suck at doing this trailout. This is way too long. So, we also have a wiki for people who are hearing impaired, or otherwise don't want to listen to our ramblings...

Turkey: gobble gobble gobble.

Spolsky: And we have a turkey.

Atwood: ... and we have turkey sounds. So that's... the wiki is hosted at FogBugz, and that's linked in the show notes. So if you want to help out your fellow non-listeners, please go to the wiki and help us.

Spolsky: You can just go... the show notes are always at blog.stackoverflow.com and you can see the latest week's show notes, at the bottom there will be a link to the wiki page where you can edit, provide transcripts and... that's very helpful to those people that don't have time to sit and listen to an hour of rambling, but want to hear all the details.

Atwood: That's right.

Spolsky: All right. See you next week.

Atwood: See ya!