The StackOverflow Podcast

Advertising, intro

[0:56]

Spolsky: OK, yeah, yeah I feel like you know what, I feel like that robot in WALL-E at the end where he gets reset and he just becomes a,[minor spoiler obfuscated, highlight to reveal] I don't want to spoil it.

Atwood: Yeah, you're gonna... Spoilers man, what are you doing?

Spolsky: Sorry, sorry. That was a great movie.  Go see it.

Atwood: Ok.  Well hey, we can disagree!  You said we agree too much.  I was actually disappointed with Wall-E, I really was.

Spolsky: What?!  Are you kidding?

Atwood: I really found it disappointing.  It was by no means bad.  Pixar is kind of like Blizzard, I don't really think they can do anything that's really bad.  But it was pretty low on my list of favorite Pixar movies.  It was probably barely in my top four...

Spolsky: I thought it was fantastic!

Atwood: Ehhh, it didn't really work for me on a couple levels.  It was by no means bad, I liked it, but uh.... there you go, we can disagree.

Spolsky: Yeah, because you're a moron.

Atwood: [Chuckles] It's a minority opinion, man.

Spolsky: You know what today is?

Atwood: Uh, what? Tuesday?

Spolsky: Today is all questions day.

Atwood: Oh that's right, it is all questions day. Ooh, I do have a tiny bit of business before we start though, I promise today is all questions day, I wanna be clear about that, which is good because we've been lackadaisical about getting to the questions. [laughs]

Spolsky: Just format your business as a question.

Atwood: Yes, so.. Question: when are we going to beta? [Spolsky laughs] So, so, minus editing, um, it's actually looking like we're gonna start letting people in... What I'm doing this week is ah, we finally have an authentication method in, which is awkward for us because normally everything is public, so we have to actually add authentication which is code that will never be in production.  We've added that, and I'm letting a few designery-type people in, to look at the site and sort of help us clean up our crufty... the fact that we're using tables instead of DIVs in a lot of places...

Spolsky: No, keep the tables, tables are great!

Atwood: (laughs) Well, where they make sense, I mean I just want people who are good at CSS to come... I'm OK at CSS... you know we've been writing a lot of code.  So that's really the short-term goal, it's to clean it up.  It's getting close to being ready for some kind of human consumption.  And we have I think over four hundred people on the beta list, so I think I'm gonna start trickling people in, probably before the end of the month now, so a little ahead of schedule.  Which is good.

Spolsky: A little bit ahead of the late schedule.

Atwood: Yeah, a little bit ahead of our late schedule.  Yes because an additional two weeks is gonna, you know, kill people.  The first software project in the history of time that's been even slightly late.  Then on logistics, just so we're clear, I don't know that people know how... what's the right word for this?  I don't wanna use the word "shoestring", but this is, we're on a very limited budget in terms of what we're doing, in terms of manpower and time and things like that.  Cause, we have one full time person which is me.  We have two people that I recruited that I used to work with, that are very much part time.  I pay them what you might call "slave wages."

Spolsky: So you give them some money to buy cigarettes?

Atwood: [Laughs] Yeah, they can buy liquor and cigarettes and things like that; you know things that programmers need.

Spolsky: Things that 15-year-olds can't get... on their allowance. Yup.

Atwood: And to their credit these guys are doing this largely out of - I don't want to say the goodness of their heart - but because they know me and they believe in the project so they are sort of contributing some sort of basic sweat equity to the project so it's not like we have this giant pool of venture capital.  I mean, this is basically self-funded to this point by: me [laughs].  Um, so, it's sort of a minimalistic endeavour, I mean what I think what we're going to end up with is going to be pretty cool.  And it's going to be kind of community effort too where I've been posting on the blog about what we're doing and trying to solicit input and things like that.  Eventually we might open source the code as well.  But it's not like we have this giant pool of venture capital money like some companies, it's very much a small endeavour that we're taking on.  But that said, people will start trickling into the beta before, before the end of the month now so that's where we are because people keep asking and I just wanted to address that.

Spolsky: I noticed one of the questions you asked on the blog was how should you handle maintenance recurring tasks in general?

Atwood: Yes.

Spolsky: Is that a fair characterization?  Every website has some tasks that you don't want to execute at the time a web page is loading, but you want to execute with some recurrence of some sort.

Atwood: Ya, background tasks sort of thing.

Spolsky: Ya, so what did you figure out?

Atwood: Well, I originally asked on Twitter, because I just wanted something light weight.  I really didn't want to like write a windows service.  I felt like that was out of band code. Plus the code that actually does the work is a web page in fact, because to me that is a logical unit of work on a website is a web page.  So, it really is like we are calling back into the web site, its just like another request in the website, so I viewed it as something that should stay inline, and the little approach that we came up that was recommended to me on Twitter was to essentially to add something to the application cache with a fixed expiration, then you have a call back so when that expires it calls a certain function which does the work then you add it back in to the cache with the same expiration.  So, it's a little bit, maybe "ghetto" is the right word.

Spolsky: Well it is kind of ghetto.

Atwood: But it works really well.

Spolsky: It not going to work if it's a long request.

Atwood: Well it will.  It's just the timing will be off.  Say it takes 60 seconds for this thing to run then the intervals are going to be screwy.

Spolsky: Doesn't that mean that some guy comes and hits our web page and some random one of his requests will take will suddenly take 60 seconds because it has to update this thing in the application cache which is going off and doing your maintenance tasks.

Atwood: You could, I mean it's security by obscurity right?

Spolsky:  No, I'm not talking about security here.  I am talking about some guy has one of his pages take longer than expected because that random page is required to do some work.

Atwood: I don't think so because one the big strengths of web apps is they are really parallelizable, because every web page is a unit of work and the only shared resource is what?  The database, the CPU?  So as long as you are not monopolizing one of those two things I would expect other incoming requests to be essentially unaffected, they are not going to block...

Spolsky: I'm not talking about the other request, I'm talking about that particular request. Some random person comes in and his request... Let me see if I can understand this mechanism here. So there's a whole bunch of people all over the world hitting our website and at some point 10 minutes have elapsed and some maintenance task has to execute. And so some random unlucky person, just hits a random unlucky web page, and the cache is now expired and that causes that random unlucky person to now have to wait, while we now do that maintenance task.

Atwood: No I think it'll happen in parallel.

Spolsky: How will it happen in parallel?

Atwood: The same way that when you and I go to FogBugz, we both retrieve a web page at the same time. I mean this is just a thread on the server internally.

Spolsky: I know but it's the thread that he was trying to use to see the homepage.

Atwood: I don't think it's the same thread, I think this is something that happens on a different thread. I could be wrong about that, but certainly I don't ever see...

Spolsky: [Garbled] me see this mechanism here.

Atwood: Yeah. Well, you know, if people are concerned, I mean, we certainly can move this out, I mean, part of what we're doing is getting things up for the beta so that, again, all the functionality is there so people can actually comment on the functionality and not what they imagine the functionality to be.

Spolsky: Well, well let me, in in the spirit of anecdotes, let me tell you how we do this in FogBugz.  Because FogBugz has a lot of tasks, and indeed we don't want to rely on anybody hitting the web page to cause these tasks to happen.  Or to trigger them to occur because, somebody might have a FogBugz account and just not log on all night.  And in the meantime FogBugz is for example receiving an incoming email and it needs to reply to it, and it needs to be doing all this stuff, even though nobody is hitting the web pages, and we also don't want that stuff to have to happen at the same time as a request.  I don't mean in a different thread, I mean actually in the thread with the person's request which it sounds what you're planning to do would have that effect - unless I'm misunderstanding something.  So here's how FogBugz does it, we wanted all that code to live in the same code with the rest of FogBugz because if you want all the same libraries to be available, like you said, it's gotta be a web page, it's gotta be in the same app-space.  Not some separate process that does separate things and needs it's own database connection or anything like that.  We just wanted it to be as if it were a web page, except it's doing background tasks.  So what we have is a special page that's called heartbeat.asp.  Heartbeat because FogBugz started out as ASP. 

I won't go into the story as to what it really is.

Atwood: [chuckles]

Spolsky: So we have this special page called heartbeat.asp.  And that page, whenever you hit it, and anybody can hit it at anytime: doesn't hurt.  But when that page runs it checks a queue of waiting tasks to see if there's anything that needs to be done.  And if there's anything that needs to be done, it does one thing and then looks in that queue again and if there's anything else to be done it returns a plus, and the entire web page that it returns is just a single character with a plus in it.  And if there's nothing else to be done, the queue is now empty, it returns a minus.  So, anybody can call this and hit it as many times, you can load up heartbeat.asp in your web browser you hit Ctrl-R Ctrl-R Ctrl-R Ctrl-R until you start getting minuses instead of pluses.  And when you've done that FogBugz will have completed all of its maintenance work that it needs to do.  So that's the first part, and the second part is a very, very simple Windows service which runs, and it's whole job is to call heartbeat.asp and if it gets a plus, call it again soon, and if it gets a minus call it again, but not for a while.  So basically there's this Windows service that's always running, that has a very, very, very simple task of just hitting a URL, and looking to see if it gets a plus or a minus and, and then scheduling when it runs again based on whether it got a plus or a minus.  And obviously you can do any kind of variation you want on this theme, like for example, uh you could actually, instead of returning just a plus or minus you could say "Okay call me back in 60 seconds" or "Call me back right away I have more work to be done."  And that's how it works... so that maintenance service it just runs, you know, it's like, you know, a half page of code that runs that maintenance service, and it never has to change, and it doesn't have any of the logic in there, it just contains the tickling that causes these web pages to get called with a certain guaranteed frequency.  And inside that web page at heartbeat.asp there's code that maintains a queue of tasks that need to be done and looks at how much time has elapsed and does, you know, late-night maintenance and every seven days delete all the older messages that have been marked as spam and all kinds of just maintenance background tasks.  And uh, that's how that does that.

Atwood: Right.  No, I don't think that the approach we are using actually intersects with the regular loading of pages.  I think it happens in the app domain.  So, there's basically some pool of threads that the server has, that the .NET core process that's running the site has.  But that said, if people are certainly concerned, we can certainly move it out too.

Spolsky: Its very confusing.  You see because its a cached application thing... but when the cache expires, it's not going to recalculate that thing, until somebody reads it.

[12:37]

Atwood: No, it will.  It will do it if nobody will... I can watch it happening on my own box.  I can just set a breakpoint on a line and it just happens even if I am not hitting the website.

Spolsky: Oh, I didn't get that.  I was missing that whole part.

Atwood: If the app domain is not spun up, I do think that it will not run. In other words, say nobody was hitting the site at all.  I do believe that to be true, that it actually will never spin up this thread which is actually okay.  But, to me this is fine because eventually we may move it out of band to a scheduled task or something or a cron job or something like that.  But, having the unit be the web page is the core concept and I think you did the same thing on FogBugz and I would agree that that's the right way to do it.  Because then we have the flexibility if want to move it out and schedule it externally, it's really trivial to do that.  You just do a HTTP request from some URL retrieval executable.  So that's fine.

Spolsky: Now, it's still a little bit ghetto in the sense that: you better not time out anything because if you time out anything then IIS will be like 'this page is taking too long' and it will shut you down.

Atwood: Yeah, no. There is a bunch of caveats around it.  But, it's good enough for beta.  Again, hoping... I want people to see the site as it's supposed to work and comment on that functionality and not the imaginary functionality that we are promising.

Spolsky: So, this is the "all questions" day.

Atwood: Where we spent fifteen minutes talking about our own stuff again.

Spolsky: [laughs] So, how have you been? [laughs]

Atwood: [laughs]

Spolsky: I have a whole bunch of questions queued up.  I am just going to do them in random order.  Here is a question from Gordon Milne.

[14:11]

Gordon Milne: Hi guys.  My name is Gordon Milne.  I'm a software developer--team leader these days--working in New Zealand.  Question I have for you is: I've got this opportunity to possibly pursue a more managerial role than the one I currently pursue.  I obviously have a few worries about that.  The main ones being simple trivial stuff like, you know, giving up on development.  How do you--in particular Joel--how do you feel about making that transition, where you're less hands on day to day and you're responsible for the feeding and well being of a team of anywhere from three to 12 developers.

Spolsky: Uh, yeah it sounds like a terrible idea [laughs].  Well, I'll answer since he addressed me, but I'll just give you my rough impression.  There are way too many companies that promote a developer to be a manager because they were a really good developer or they were the best developer or something, and that's usually a pretty bad idea.  In fact, team lead or management skills more often than not do not correlate with development skills.  They're just different things.  It's just like, you know, making pizzas and taking out appendices. They're just completely different skills. And being really good at one skill or being really good as a developer is often not really a sign you're going to be good as a manager.  Although, that's not really what Gordon asked. For all I know, Gordon is a moderate or poor developer and will be a very good manager because he's really good at the interpersonal skills or personnel management or just sorta the human relations side of things.

Atwood: So what you're saying is that you want to pick your worst developers and make them mangers?  Is that what I'm hearing?

Spolsky: Sometimes. [laughs]  Sometimes.  Although sometimes not.  I mean, sometimes they're just bad at both.  In economic terms, somebody's going to have competitive advantages as being a manager.  It's going to be the person who is most relatively best at motivational issues, understanding what people want and what motivates them and what they're going to think when tell them x, y, or z and so on.

Atwood: So, you have to move from being a compiler person or an interpreter person (I guess) to being a people person.  So, you are saying that the people transition is the most important. It's not how much technical but, you must have enough technical ability to know when people are lying to you.  That's the way I look at this. [laughs]

Spolsky: That's true.

Atwood: The developer says, "we are going to frim-fram the blim-blam" and the manager says, "Oh okay - go do that". [laughs] Right.  Are you really capable of doing your job at that point of time if people can just lie to you?

Spolsky: You need a couple of things in terms of technical chops.  One is you need to be able to throughly understand of what's going on and call people out on their bullshit.  Because, believe me: they will try.  Number two, you need to have their respect.  Which means technical respect.  Often to technical people, if they don't respect you from a technical level, it's going to be very hard to get things done.  Although, that shouldn't necessarily be true.  I mean, you could imagine somebody comes from a business background and maybe the developers understand that he is really good from a business background and understand that and are willing to give him or her that respect.  It doesn't really matter. Because, most of the time to pull it off you are going to need to have some serious technical chops I think. And it really is just sort of a different kind of a career and there is ways... and I mean I guess I could point to a couple of real no-nos which I think that people I know might have done, maybe including myself.  Number one is when you are a developer and you are not so clear on dealing with human resources or personnel issues or that particular aspect of management, there is a real tendency just to say, "you know I am not really starting out as a full-time lead. I am still going to wanna write code."  And, thats a valuable thing to say.  And you say maybe I am going to spend 50% or 80% of my time writing code and I will try to keep that human resources aspect of my job down to a day a week or a couple of hours a day.  And that's fine.  You can and you should do this.  Especially at the first level team leads should certainly still be writing code a lot of the time and even sort of the head of a very, very large team should still be able to find 5-10% of their time to write code.  But, the trouble is when you do a 100% of your time writing code and you sort of say, "I'm not so good at this human resources thing so I'm going to keep doing what I was good at which is writing code and I'm just kinda going to ignore those human resource problems and let them resolve themselves." And you tell yourself a very nice story that you are being a very hands-off manager and you are in the trenches with your team and you are working on the code with them everyday and you are not really a manager so much as just another member of the team. You can say that, but that's not going to be all that successful for you because there are things that somebody just has to do in management and if you don't do them because you are not so good at them bad things will happen and you will discover why it was that they needed a team lead in the first place.

Atwood: Right, so it's sort of a paradox. You can't really write code but you have to write a tiny bit of the code.  So, you probably will have to let go of the code more than the average developer I would say.  Because the whole reason people... it's like as you said why promote someone who is your best coder.  I think that's probably the pathology here.  Take your best coder and say that you should be a manager because you are so good at coding and not to look for people that are sort of good at both and maybe not the best coders but really better at the people thing and willing to devote the time to it.  And then of course we got to bring up our favourite book Peopleware.  This was one of my complaints with people that were managing me as a developer.  It's like they didn't really put any effort... how did they learn to do their job?  They just sort of came in and did whatever popped in their head.  I got really frustrated.  You know there are those books about what you are supposed to be doing and maybe you could read them. [laughs]  Figure that out because once you are a people person you get the idea that I can just talk to people to do my job, it's like well... a little bit more than that.  I mean there are some technical things to it.  So again I would just point to Peopleware and if you want to be a manager thats absolutely required reading at that point and even more than it was before.  You should like live it, love it, learn it, right? [chuckles] ... book.

Spolsky: Yeah.  And there are books about sort of becoming a manager.  Actually, you know, Rands, Michael Lopp, who uses the name Rands on the Internet, has a book called, I think it's called "Becoming A Manager".  Uh, is that right?

Atwood: "Managing Humans", or something like that.

Spolsky: "Managing Humans", thank you.  "Managing Humans"...  and a lot of it is on his website, Rands in Repose, on the subject and he's got kind of an interesting take on it that comes from working at a rather large company (at Apple) where I believe secretly, I don't know if I'm allowed to reveal this, I think he works on the server team for people that use it, y'know, Apple boxes as their servers if I'm not mistaken.  But anyway, he's got this very interesting kind of what it... how to be a middle manager in a larger organization perspective.

Atwood: [grunts encouragement]

Spolsky: Where there's a certain amount of managing upwards that you have to do as managing expectations.  Some people would call it playing politics but playing politics is just a nasty name for doing interpersonal things where you talk to people and you try to affect things that you want to affect.  We actually screwed it up for a while at Fog Creek and we didn't have any kind of middle management at all and we thought we would get away without middle management for a long time, and it didn't work out so well and the full story of that, I won't tell it now, but the full story of what happened and how we realized we needed to have managers is going to be in my next column in Inc. Magazine.  I think it's the September, the upcoming Inc. magazine.  I'll link to that from my website when it finally comes out, but if you look for the Inc. 500 issue, I think that'll be in there.

Atwood: Oh, cool.  Well, that was a good question.  I enjoyed that one.  And definitely, the Rands book is very good, as is Peopleware.

Spolsky: Right.  Okay, Jason...

[22:37]

Jason Zimpelmann: Hey Jeff and Joel, this is Jason Zimpelmann from North Carolina.  Love the show, keep up the good work.  I was wondering what sorts of time management strategies you guys both use?  I know with you Joel running an entire business you are obviously busy.  Jeff you’re fairly prolific in your blog posting, plus working full time on StackOverflow, I am wondering what sorts of time management issues you guys run into?

Spolsky: There is another part of this question which I will play in a minute, but it’s completely unrelated, so let’s talk about time management.  First.

Atwood: I am the wrong person to ask...

Spolsky: [Laughs]

Atwood: for time management.  If you are asking me for time management, you’re in deep, deep trouble.  Really bad.  It’s not good.

Spolsky: [Laughs] So what you do …

Atwood: So I will let Joel take this question, let me just…

Spolsky: is if you have a lot of email, you want to go to your video game console. [Laughs]  And first you want to clear your head by playing some kind of a video game.

Atwood: I think it's more like shiny object problem that I have where I'll get distracted.  Here's a really dumb example: so I'm working on StackOverflow, which I do actually work on StackOverflow-

Spolsky: [laughs]

Atwood: and I'm looking up something and it'll remind me of a music video or I'll get a music video result in the search and go 'Oh I remember that music video' and just have to watch the video which relates to the term that I was working on.  It was actually 'Popular' this video by Nada Surf.  I was like 'Oh I remember that song' of course I had to go watch it, then I had to look up the band and see what they're doing.  Like I said, I'm the wrong person to ask.

I think what works in my favor is that when it comes to writing and some of the stuff I feel driven. I feel like I haven't produced anything until it's visible to the public.  So that ends up being the thing that drives me.  It's like I've seen the positive feedback loop you get of posting things publicly, not only in terms of personal satisfaction, but also in terms of your career, getting answers to your questions.  Living in public, I've started to really believe in, and I feel like if a day goes by, and I haven't dome something that was publicly visible to someone in the world, then I get really nervous. [Joel chuckles]  I feel like I haven't done anything that day. So that become the thing that drives me, having these public artifacts, but it's, you know, again...

Spolsky: That's like a Milan Kundera short story about some guy who doesn't want to live unless he's in the public.

Atwood: [Laughs] Well I don't mean it in the negative, I mean it works on so many levels.  It sounds selfish, maybe it is, but I like to feel like I'm producing things that somebody would find, and it would actually help them too.  You know, there's this great communal work going on that we're all doing and I like to participate in it and on some level I kind of get off on it obviously so that's the way I do it - but I don't run a company.  Joel, you should totally take this because you have so many more demands on your time than I do.

Spolsky: Right.  I don't have a great answer and my answer is going to start a little bit boring, which is to say that I'm a big fan of Getting Things Done not that I could read that book, in fact I was able to save a lot of time [both laugh] and manage my time very well....

Atwood: [Still Laughing] You saved time by not reading that book?? That's awesome!

Spolsky: ...by just skipping the actual reading of Getting Things Done.  Let me tell you a little about it, there's some philosophy there and there's some methods, and certainly for the geeks, Getting Things Done, that book is just an excellent method of organizing your life and getting things done and actually being productive with your time.  I'll give you a couple of insights.  One is an insight that I actually learned from the book before I realised that I was wasting time by reading it, and that was the insight that if you don't have a kind of to-do list system where you look at something and put it on a list of things to get done, if you don't have a system for that then you've got all these nagging little things that you have to do in the back of your head that are going to cause stress and make you unhappy.  The basic philosophy is just when something comes in whether through the inbox or you just decide you want to do something and I think the rule is that if you can do it in two or three minutes, you just do it immediately, it's like not even worth the time to put it on a list, you just do it.  You concentrate on getting it done and get rid of it.  Just knock out that e-mail and get rid of it and get it out of your inbox as fast as possible.  If it's going to take any longer than that, don't let it stay in your inbox or in your front queue whatever that may be, you gotta move it like on to a calendar or onto a long-term to-do list or on to some other list of things to look at when you have some spare time.  You just have to get it out of your brain where it's nagging you and causing stress and onto a piece of paper or a to-do list on your computer or a task list or a FogBugz database or someplace where it's going to remind you that you have to do it later and you don't have to have it permanently causing stress... [pause]

[27:33]

Atwood: Have you been to Merlin Mann's site, the 43 Folders?

Spolsky: Uhh no, but that seems like another excellent way to waste time instead of getting things done trying to learn about how to get things done. [chuckles]

Atwood: Well it becomes pornography at some level [Joel laughs].  It's info about how to do things, you're not actually doing things but reading about how to do them if you were - in theory - to do them.  This is the most optimal way to do it.  I think a certain amount of that is good.  Certainly, there's some great tips on handling email.  I think you touched on one of them which was if you have small things come in, and I've actually started to do this too if I get small emails, I love small emails.  If you're going to email me, make it like a twitter message. Make it really short, something I can answer immediately - no research - and you will get a really fast response.  If it's like a 3-page business proposal, it's gonna sit in my inbox for weeks [Joel mutters something about requiring a decision] because, I mean, the amount of thinking I have to do is just way disproportionate to the email.  I think there's some good basic lessons you can get out of sites like that I think are helpful.  I think Merlin Mann, who runs that site, is a very funny guy.  You listen to his podcast right?

Spolsky: [grunts acknowledgement]

Atwood: Has some really good insights on this problem and he's a great person to listen to. I'm also going to... there's this little conference called the Start Conference in August for startups - which I am now: a startup - and Merlin Mann is gonna be there so I'm looking forward to

Spolsky: Cool.

Atwood: meeting him and saying hello to him and seeing what he has to say about that. But yeah that's another site to turn to and I think he started with Getting Things Done as well, I think that was sort of the gem of his idea and he just basically built a website around that - that's my understanding.

Spolsky: Now following with that I want to point out another thing, you mentioned the hypothetical email that sits in your inbox for a long time because there's some complicated decision to be made and fortunately we've hired a person here at Fog Creek, Rich, who is kind of a Getting Things Done expert and aficionado and really has some good understanding about all this stuff and how to be productive and also sane and keep calm in the face of lots and lots of demands coming in from different directions.  And one thing he pointed out is 'don't cherry pick' and what he meant is don't go into your inbox and cherry pick the things that you can do now.  If you have an inbox, you gotta do it in order.  You can't pick out the things that are easy that you can just knock out of the way and cherry pick those and here's why, if I'm understanding it correctly: the theory is if you leave all the complicated stuff that requires a decision in your inbox, every time you go into the inbox to try to find something to work on, you're going to open up every one of those emails and you're going to be thinking about those things and trying to decide those.  You're going to be spinning up and basically you're going to be task switching into thinking about this email that you're not even going to deal with.  So if something stays in your inbox for 2 months while you try to figure out what the answer is going to be or whether you're going to hire this person who sent you a resume or whatever the case may be and that keeps coming back again and again, then every time you go to your inbox that distraction is going to be there and you're going to have to spend time and mental energy on something that you're not even going to solve.  That's why it's really important to just get it the heck out of there until you can work on it.  Just get it out of your inbox and put it on your calendar or put it on your to-do list with some kind of prioritization.  Whatever those things are in your inbox, your to-do list, or your calendar, you just do things in order.  You just pick one and work on it till it's done, you don't allow it to come back again later and consume more mental energy and create more stress at some later point in time.  So I've been doing that and that kind of helps a little bit.  I've been doing that lately.  There's a couple of other things I do.  Sometimes if I really need to get stuff done, I won't even look at my inbox until after lunch.  That kind of helps, I'll just pick some actual project to work on.

Okay, so enough about time management.  There's another question that Jason had.  This is the second part of his recording:

[31:29]

Jason Zimpelmann: Jeff, in response to your recent posting about the region blocks in .NET, I was wondering if the same attitude towards collapsing individual functions also applied, since that is hiding code. Or is it more or less hiding groups of functions that you have an issue with?  Again thanks for the time and keep up the good work!

[31:57]

Spolsky:  Yeah.

Atwood:  I guess I could talk a lot about that but I'll try to be concise.  It frustrates me a little that the region directive even exists.  Because I think, historically, if you look at why Microsoft had that - and people at Microsoft have sort of implied as much - that before Microsoft had partial classes, so you could have two classes that are really the same class, but in two different files. 

Spolsky:  [grunts acknowledgement]

Atwood:  Right, you could have sort of the autogenerated cruft in one file that you never have to look at and really why would you want to look at it.  It's autogenerated, you shouldn't change it.  If you change it that's a pathology.  You just never need to see it.   From your perspective it's just magic that happens.

Spolsky:  Right.

Atwood:  And you have another file, which is the partial class, which is like, "Oh here's the stuff that actually matters.  Here's my code, that does my things, that I care about."  But they didn't always have that.  Partial classes were new to I think .NET 2.0, so Visual Studio 2005 era. So they had to have some way of putting the stuff in the same file and I'm sure some product manager at Microsoft saw that auto-generated code and said, "Why does the developer even have to look at this code?"  He or she was right, but what they came up with was the Region directive so they could collapse all that auto-generated code and say, "Don't touch this code, it's auto-generated, warning, warning, here be dragons, etc, etc."  But now that we have partial classes, I would argue that Regions now are horribly abused.  It had a very specific meaning I think early on for Microsoft and now I've never met a developer that didn't love coming up with ten thousand different categorizations, like a huge forest of trees, and just carefully deciding were every little thing needs to go. If you look at the way, for example, a web page works.  Imagine the CNN homepage, if every article was collapsed.  Or, every time if you wanted to see something you had to click on it.

Spolsky: Oh, this would look like just Scripting News.

Atwood: This is not really the way things were meant to work, this is what search is about.  You scroll down to the thing you want.  I use Ctrl+I, which is incremental search.  I use that all the time and Ctrl+Shift+F, which is find in project.  Essentially, search is my metaphor of choice for finding things in code.  I don't spend a lot of time mousing around looking for code.  I think of some keyword that I know is going to be there.  The world is full of tokens, unique tokens that identify things.  Just like search keywords, unique search keywords that identify things.  I Ctrl+Shift+F and I hit F8 to navigate to the search that I want or Ctrl+I to get there pretty much instantly.

[34:26]

Spolsky: In Visual Studio 2008, does that expand if you search into something that's hidden in a Region?

Atwood: It does now.  In earlier versions they screwed that up.  You're right - that was a huge problem.

Spolsky: Yeah.

Atwood: was that you couldn't find things in Regions.  But they did fix that.  I don't know  which version of Visual Studio that got fixed in, but as of 2008 for sure it does work.  My attitude towards Regions is if you're hiding code you gotta really think, "Why I am I hiding the thing that I am supposed to be writing?"  That's a little disturbing to me.  They way we do it on StackOverflow is - I am not totally religious about it - my guidance to the team is please use as few Regions as you possibly can.  There are places where we have Regions to be fair, I'm not gonna quit the team if I see a Region or anything ridiculous like that.  Just think about why you're using it.  It's kind of like goto.  You should never really use goto without a good reason, but there are still good reasons to use goto occasionally.  You've just gotta have good reasons.

Spolsky: I think a lot of times is where people are using a Region because they don't wanna organize a bunch of their functions behind a page, that's probably a good use of my favorite thing, a user control. Maybe this is an abstraction that you just wanna pull out into its own class and have it sort of isolated and localized and stuff like that...

Atwood: Right, right, no I totally agree. I think anytime you use a Region it's like there is other ways like Partial classes as two separate files.  That's a much better solution then to have this silly little Region tag that doesn't really do anything.

Spolsky: Or even just actual classes.

Atwood: Plus it's an actual line of code!  This drives me bonkers: it's like a line of code for the editor.

Spolsky: Yeah.[giggle]

Atwood: I mean, what's wrong with this picture.  Even a comment is useful to the humans.  Regions, enough said on that.

Spolsky: Let see what else we got here. Let's go to Aviv Ben Yousef.

[36:20]

Aviv Ben-Yosef:
Hello Jeff and Joel.  This is Aviv from Israel and I wanted to ask you about code review and how you think it should be done.  In my workplace we have an argument whether it should be done alone - after someone checks in his code, I check out review it and place some comments or send him an email with my comments and then check it back in and he reviews it again.  Or (and this is a new approach) whether about once a day we come to the person.  He shows you what he has done lately, interactively.  Or are we missing it at all and you have a better way?  Thanks.  Keep doing this podcast.  It's really cool.  Bye.

Spolsky: So are you doing any kind of code reviews over there?

Atwood: We do actually do some form of code review, so I have an opinion about this.  I think code reviews is one of the most powerful things you can do on a project. Just having two pairs of eyes - say you have - it depends how you want to do it.  There's many ways to accomplish this.  But let's say for the sake of argument we have a rule that says every time you check something in, you can't check it in until you have another developer sit down with you and look at it.  Explain it to that developer, show it off, that sort of thing.  I actually first got into this at my previous employer.  At first I viewed it as a tax.  Oh great, now every time I check something in, I have to go justify what I've done.  But assuming you have a rational workplace - this is kind of a key thing - where your coworkers enjoy working with you and on some basic professional level.  It's actually fun to sit down with another developer and see their code and understand how they work and have them explain to you why they made the decisions they made.  And not in like a "I have to justify my decisions to you" way but a "let me show you this cool thing that I did" way.  I learned so many things, just little things like the way that developers use their IDE.  Tricks, coding tricks that they would do.  You will learn an astonishing number of things that have nothing to do with the code that is being checked in, just by interacting with your fellow developers on a regular basis.  And then two - the two eyes in terms of protecting you from weird code or architectural decisions that turn out to be bad, you sort of double your value in the code that goes in.  So I'm a big, big believer in this and I believe it has to be done interactively.  I do not believe that emailing someone after the fact or instant messaging them.  Because then it might seem like an interrogation, you know?  I think if you sit down with someone, you are not going to have that animosity of "Oh, why did you do it this way?"  It just prevents a lot of miscommunications and I think when it comes to code review that's really really important.  So I would strongly urge anyone listening to this to really consider: Don't do any kind of offline review - do it interactively.  We do it through Skype, like we're doing now and sometimes screen sharing, but we'll just talk about which line of code and stuff.  I love it and that's my recommendation.  Just make sure you do it face to face, or as close to face to face as you can.

Spolsky: Yeah I absolutely agree.  End of story.  It's weird Aviv where you mention you were having an argument about that.  That implies that there is someone there who actually thinks it is better to not do code reviews in person and just to send a little email.  I hate to extrapolate from no information whatsoever but it sure sounds like it's a person who doesn't really like the human communication part of the job so much for whatever reason or maybe they're not so good at it.  But there's nothing you can do.  You really learn too much from sitting down with a person and talking and when you stand up after an in-person code review, 90% of the things that you learned are not directly related to the formal part of the code review.  Like, we sat down to talk about whatever and it's just even, as Jeff mentioned, watching how you use keyboard shortcuts or your IDE or whatever it is.  That's the way that teams transmit knowledge of how things should be done.  That's your chance to see people doing things other than just the pure writing lines of code.  So it's pretty important.

 [40:32]

Atwood: Yeah. And I think programming really, to me, is a very social activity.  I mentioned on an earlier podcast that I was working on StackOverflow and my other team members (even though we have a distributed team) were just unavailable, they were on vacation or some other way.  It just felt very isolated.  It, to me, felt a very incomplete way to write code.  Again, getting back to my attitude that I have to product something public to feel like I've accomplished something in a given day.  If I write code that one of my fellow developers hasn't seen or I haven't explained it to them, did I really do it?  Did I really get all the benefit out of writing that code?  Maybe that's a minority position, but I feel like writing the code and then the explaining and sharing the code part is just as important if not more important, to me, as an activity.

[41:25]

Spolsky: Cool.  OK, so that was an unambiguous answer.  Here's David McGraw:

David McGraw: Hi guys.  My name is David McGraw and I'm from Manhattan, Kansas.  What advice would you give to college students who are about to start interviewing these days, and could you give any thoughts to common areas that they always seem to be weak in?  Thanks a lot guys, keep up the great work.

[pause]

Spolsky: Jeeeeeefffffff????

Atwood: Well, I've done a limited amount of interviewing at some various jobs that I've had, and I think my general advice over time evolved into "have a portfolio," right?

Spolsky: Oh!

Atwood: Yeah, "Show me what you've done", in some meaningful way, like either screenshots, or actually code samples, even, are fun to look at.  Taken to an extreme, I view it as "Give me a mini presentation."  Sell me on what you've done.  Explain it in a way where you give a presentation like you would to a group of random programmers, and make me: 

a) understand what it is you did;

b) understand why it was cool or good; and

c) what you actually learned from it. 

I actually had an old blog post on this and people kind of freaked out a little bit when I posted it. It was like, "Oh my God, you want me to stand up and give a presentation?"  For a lot of developers that's like the worst possible thing they could do that you could ask someone to do -- to give a presentation -- because it is kind of stressful.  But it doesn't have to be that way, I think at the very least just view it as "build a portfolio of your work that you can point to" and again, I think, the more public the better.  If you've worked on an open source project that's huge, because you can easily point to that, the more public artifacts you can generate from your work, I think ultimately the better position you will be later in your career.  So that's what I arrived at, so those are very general, broad things, and Joel you do a ton of interviewing, so I'm sure you have a lot to say on this.

[43:24]

Spolsky: Well I have a couple of things, the main thing I wanted to say is: you just have to be yourself.  If you're attempting to prove that you know something that you don't know or you're attempting to act like a hypothetical person that's not really you, it's going to show and you're going to be nervous and it's not going to work very well.  If you've never worn a suit in your life, I would have to say don't wear a suit to the interview [laughs] unless, I guess you have to wear a suit to certain interviews, but if you've never worn a suit in your life you probably don't want one of those jobs where you have to wear a suit, so seriously consider coming in dressed in business casual and if that freaks them out maybe that's not the job that you want.  Mostly it's about just being yourself so the interviewer has the best chance to judge you as a person but I think actually Jeff's advice is even better than mine.  Let me tell you why.  You know I've written these books about how to conduct interviews and everybody at FogCreek when they interview somebody comes into that interview with a direct agenda of what's going to be talked about and if you come and sit through some FogCreek interviews you're not going to have that much opportunity - at the end, we'll let you ask questions - but we're going to dictate pretty much what happens during the interview, we're going to tell you to write this code and write that code and show us you can do this and show us you can do that and that works really well for us, the employer, determining if your able to do your job.  If you're a programmer and you're applying for jobs I would bet that three out of four of the interviews that you go to are not really going to do this and those interviewers who are interviewing you are not really going to be prepared to ask you a whole hour's worth of questions or however long they have on on the calendar and they're not really going to know what to talk about and they're not going to ask the right questions and they're just gonna hope that... I don't know what they're thinking.  I'm not really sure what they're thinking.  They won't have a plan for their interview.

Atwood: Shocking! You're saying that people don't have a plan out there in the world? There's someone who doesn't have a plan?

Spolsky: Yes. They go in there and they're like, "What should I talk about?"  And you know what, you can tell because they're going to start going over your resume in chronological order, and they'll just... big waste of time.  What you need to do to prepare yourself against this contingency is say, "alright, if I have an hour with a person and the person just sits there and nods, what is the information I want to get across about why they should hire me?  What are the things that I want that person to understand by the end of this interview and I don't want to leave the room without the person knowing that I've done these things, that I can do these things, that I'm good at those things, and maybe I'm not so good at those other things, maybe."  You should have a plan of what you want to illustrate and why you're pretty good at it and maybe an explicit plan if there's something on your resume, if your grades are kinda low, but maybe not major, or if your grades were low freshman year but they got better after that and you want to explain that stuff, make sure that you know that when you go into that interview, "I need to get across to the interviewer in this hour these facts: this is why I got bad grades in freshman year;" or "I really love programming but I'm not so good at interpersonal skills;" or "I would really love a job where I could just hack all night long;" or "I've worked on this project and that project, or I built this thing."  Make a list of those things that you want to make sure you get across.  Practice with some friends and family.  Call up your grandmother (I know she'd love to hear from you) and say, "Grandma, pretend you are a really bad interviewer. Just say, [high voice] 'So tell me about yourself,' [/high voice] and I'll do the rest."  Just practice talking about yourself for an hour in a way which portrays yourself in a positive light and which highlights the accomplishments that you think will be relevant to that employer.

[46:30]

Atwood: You know, you bring up a really good distinction there. Which is there's maybe two different kinds of interviewers.  One's where the person being interviewed gets to drive and the other being the kind where the interviewer is driving.

Spolsky: Yeah.

Atwood: I've read, of course, Steve Yegge and we can't go a podcast without talking about Steve Yegge.  He wrote a really good interview post, that was one of the key bits that I got out of it that was fascinating.  Don't let the person you are interviewing drive the interview.  It is your job.  That's true.  If you are doing your job as an interviewer, you're going to come in with an agenda.  You're going to jump through hoops, for lack of a better term.  You're going to do these things; I'm going to ask these questions; I'm going to totally drive.

Spolsky: We will at Fog Creek because we have read my book.  That's not true at all places, of course.

[47:48]

Atwood: For those kind of interviews, I do think it's a different kind of preparation.  I think you want to do this anyway.  Say I was interviewing with Fog Creek.  I would go to the Fog Creek website.  I would read your blog.  I would do all this research about what Fog Creek is, what kind of interview I can expect to get there.  Basically, prepare for the interview.  Both in the sense of studying for a test, and I find this unfortunate because I don't enjoy the pure testy whiteboard interviews, but you do have to study.  Writing code on a whiteboard is really difficult.  I write with all these crutches of Visual Studio and still I kinda suck at it. [chuckles]  Writing on a whiteboard: wow!  You would have to practice that.  If people are going to ask you puzzle questions, which I hate, hate, hate, hate puzzle questions.  I was looking up Michael, your partner, and has a whole website of puzzle questions.

Spolsky: techinterview.org. It's also a column in Inc. Magazine.

Atwood: They're fun to a certain type of person.  I am the type of person that those are totally nails on a chalkboard to me.  When I get puzzle questions, I want to gouge the interviewer's eyes out. [laughs]  I wouldn't really do that.  I have a hard time rationalizing how puzzle questions really help me as a developer.  I know opinions vary.  The point being, you have to study.  If you're going into an interview where you know they love to ask puzzle questions or they love to have you write code on a whiteboard, you have to prepare for that. 

[49:17]

Spolsky: On the other hand, I mean you can't...you're not going to be able to practice every single piece of writing code.  And if you show up at FogCreek and we say "Write strcpy" and you just whisk it out on the board instantly because you practiced and you knew how to do that, then we'll say "Okay: not a data point" because you just have this memorized or you prepared this.  So we need to find something that you haven't prepared.

So specifically if I were telling people how do you prepare for a FogCreek interview, I wouldn't say you have to study for a FogCreek interview, I would say: just chill out, don't worry about it, study our company a little bit, spend some time at our website, and at JoelOnSoftware, figure out what our products are.  See what you can... Just come with a few interesting questions so that you look like you actually care about us a little bit.  That'll stroke our egos, that's all we need, and we'll drive the actual technical part.  I feel like we're pretty good at that, at driving the technical part, here.

But the only other kind of preparation you need, like we both mentioned earlier, is make sure that you know what you're going to do if you've got a dud interviewer, that is just not, whatever he or she is doing in the interview, is not revealing what you want to reveal about why you're a great candidate and a great person and you should have this job.  And if they're just not accomplishing that in their questions you can often steer the conversation, and a lot of times they'll be really relieved, if you say, if there's a little pause while they're trying to figure out what to say, or you see them sort of looking at your resume and kind of stroking their chin.  You might want to say "Would you like me to tell you about the contribution I made to the OpenBSD file system last week? That's pretty interesting code that I just wrote."  And they'll probably say "Sure" and then you'll be prepared to bang it out and explain it and talk about it on the whiteboard.  And that's the hour that you want to prepare so that you'll have something to do if they're not good at finding on their own whether or not you're a good programmer.

[51:14]

Atwood: Right.  But I do think you really need to know sort of roughly what kind of stuff they're gonna ask of you, 'cause... Let me give you another example.  I think this is a good interview practice -- actually, I like it much more than, say, the random puzzle questions.

At my previous employer, you'd actually sit down and write a mini app, so you're using Visual Studio, you're using SQL Server, you're using all the things that you're gonna use there anyway; for the most part.  It's not like some imaginary, arbitrary compiler you're writing code for: it's the actual tools.  Say you got the job -- you would need to use them anyway.

And it's a very simple app, it's not hard to write or anything, but it's shocking how many people sit down and like really can't produce anything. [laughs]

Spolsky: Yeah.

Atwood: So I do believe in that, because that's just, you know, where's the stick shift, you know, where's the gas pedal, can you drive the truck - right?  And then you can have a conversation about architecture.  Oh, for this little app, why would you decide to do this? And... it's a great interview practice.  It is stressful like all interviews cause you're being asked to perform.  But they're really cool about it in that they say, you know, look, this isn't a production level app, we just want something simple, it doesn't have to be super complicated.  But it's a great interview practice, and I much prefer that to say, lots of puzzles, and writing code on the whiteboard, and things like that.  But again, it's a situation where you'd want to prepare.  When I went in for that interview, I brushed up on my SQL Server because, although I've used SQL Server, I didn't want to sit down with the tool, and then have it, you know, have to refresh my memory, do a bunch of Google searches on really basic things.  So it is nice to be able to prepare a little bit for what you're going to see in the interview, I will say that.

Spolsky: Right. One way to prepare if you know you're going to a place like Microsoft/Google, that relies heavily on puzzle questions: there's a book called "How Would You Move Mount Fuji?", all about puzzle questions. William Poundstone.

Atwood: Yep. That's a great question.

[53:00]

Spolsky: And, let's see... shall we take another question, or shall we talk more about interviews?

Atwood: No no no, absolutely more questions.  This is what this show is about.

Spolsky: Alright, here's a question from Adam:

Adam Haile: Hi Jeff and Joel my name is Adam Haile, I'm a long time C, C++ and .NET developer and I have a pure programming question for the two of you regarding a C++ technique that I never quite found a corollary to in .NET.  I often in lieu of having to create some large complex switch statement that I'll have to maintain to call differing functions depending upon the function that I desire, I will simply create multiple functions with the same prototype and then create and array of pointers to those functions which I can then simply index later cutting code down for you know hundreds of lines of switch statement to a simple for loop or something of the like, but as .NET does not have pointers I've not been able to find a way to do basically the same thing in .NET.  I'm sure there is a way to do it but I just haven't found it.  If you guys know that'd be great.

Spolsky: Ah, this is such an easy question.  This is like 59 seconds asking, the answer is going to take one second.  Do you want to ?

Atwood: No you go ahead.

Spolsky: Delegates.  It's called delegates.  That's it.  The end.  They're function pointers.  The end.  Next question. [giggle]  A really easy one.

Atwood: Well also... aren't... Isn't sort of kind of what lambdas are as well?  Kind of passing a function as an argument?

Spolsky: Uh... You could do it... Well okay, there is a thing called delegates that's really the first class native .NET way of doing it.  A delegate is just a pointer to a method member function in a class.  There was a cheesy way which was more common in object oriented programming, especially in Java, I don't know if Java has delegates 'cause I'm so out of it, but there is this concept called a functor, where what you do is create a class that only has one method called "Do"... "It"... or whatever, and all you got to do is instantiate this class object and you put those in array, and now you gotten the same effect as function pointers except what you actually have is an object and the only thing this object has of any interest whatsoever is a single method that always has the same name that you can then call, and if all the functor classes that you create all inherit from the same abstract virtual base class, then you will be able to do that in any object oriented programming language.

Now, a lambda is kind of a way to inline a function, especially a very short function.  So instead of actually having like an array of functions where you define all the functions, and then you create an array and you refer them all by name, a lambda allows you to have those functions be anonymous, never have a name because you actually inlined the actual code for the function right where you're using it or putting it in an array, or whatever it is you're doing.  And lambdas, to be honest, are really more useful with very very very short, like one- two-liners and can be a big uh... Well, I mean, it certainly doesn't make your code clean or easy to follow if they were long.  So, if you gonna have, you know an array of a hundred things, and you're just gonna put those in lambdas, you might as well make a switch statement, 'cause the code is gonna have the exact same structure as a switch statement.

Atwood: Well, there's also anonymous functions in C#, I believe 3.0, so there's that as well.  I think there are several techniques, so maybe I will try to create links to both for Adam.

Spolsky: Yeah, delegates are really the traditional original way of doing this specific thing.  That would be the real classic old school... Boy; I remember when I never used to understand function pointers at all, until my friend Jason.  We had to make a DOS application, literally a DOS application and we wanted to have a menu, and I don't know if you remember menus in those days but they weren't pull down menus.  It was like the screen would come up and it would have 1, 2, 3, 4, 5, 6, 7, 8 things you could do, and you would press number 4 and it would do the fourth one.  And, I remember just setting up to make, what the heck did they call switch statements?  What where we using?  I'm guess it was Turbo Pascal.  And I remember - no it was Turbo C, it was actually Turbo C - and I remember getting ready to make the switch statement.  It's like "no, no that's not how you do it."  And he would just sort of declare the eight functions there and then made an array of eight function pointers to the eight things.  And then the menu executing code was just a simple matter of just indexing into that array and calling whatever function one found there.  And once you had this array you could hang other things on it besides the function pointer like the menu text or the help text that is associated with the menu text or whatever stuff you wanted.

Atwood: Right. To me it's about sometimes you want to pass in a function as a parameter.  You don't really know what you want to do.  So you want to pass in the actual function or method itself that you want to be able to do.  So, that to me is-

Spolsky: This is incidentally one of the things that strikes me as sort of strange about Ruby, and one reason I like Python a little bit better is that Ruby inherits from Smalltalk in that it has the idea of a block.  And a block is a function that you are passing in, to another function as if it were an argument.  You know it's a block of text - I'm sorry a block of code - that you are passing in as if it were an argument, in your call.  And then inside the function that you call passing in the block, anytime that code executes the "yield" statement, it calls the function that was passed in, which comes straight from Smalltalk.  And I always thought it was strange that it had this special method for making one argument be a lambda effectively, or an anonymous function or a block.  It just seemed, sort of a little bit, like a little bit of a wart on a language.  Why can't you have an arbitrary number of functions be lambdas?  Why is there only one?  Why are you limited to exactly one?  It's sort of one of those things that I never quite... sort of strange about Ruby.

Now, in practice very very rarely do you ever need more than one, in fact possibly never, [laughs] so it's not that big of a deal.

Atwood: I think that was a good question.  We could do maybe one other very very short question, if we have one that's easy and short.  I don't know if we do.

[59:24]

Matías A. Bellone:  Hello Joel and Jeff my name is Matías and I am from Cordoba, Argentina and I have a question for you.  I am a computer science student and as I cannot apply for Joel’s internships I have been working for a Voice Over IP company overseas.  Outsourcing is quite popular and common now-a-days and with its advantages and disadvantages has been putting food on my table for the past two years.  What is your opinion and experiences on the matter?  Thanks for your time and congratulations on StackOverflow.

Spolsky:  Ahh see that’s a short question right?  There's nothing to talk about here.

Atwood:  Yes.  Nice pick of a short question.  That’s great.

Spolsky:  [grunts acknowledgement]

Atwood: Ahh.. I’m sure you don’t do any outsourcing, right or... I mean you don’t outsource anything at… programming-wise I mean since that’s your core competency of your business you wouldn’t outsource your core competency would you?

Spolsky: We really try not to.

Atwood: Yeah.  So to me outsourcing is about recognizing that programming is not your core competency, software development isn’t.  So it’s going to be more cost effective for you to have professionals do it somewhere else…

Spolsky:  [grunts agreement]

Atwood: uhh... and I think my personal perspective is, and I’m sure it’s one you agree, is I wouldn’t want to work for a company that was doing that anyway because what I love to do is not really considered a part of their core business sort-of by definition at that point. Now maybe if you were working for a company that did this... in other words you were outsourcing and you’re the professional that small companies would turn to when they need, you know, programming work done, I think that’s fine.  But working for a company that’s doing that is just really kind of depressing 'cause it means what you love to do they don’t consider really that valuable anymore…

Spolsky:  Wait so let’s, wait, wait, I’m confused here about all these different companies.  So you’ve got the company - let’s give them names.  We’ve got some hypothetical company I’ll call it Disney…

Atwood:  No No: ACME.

Spolsky: No No. Okay.  ACME.  They make widgets.

Atwood: Yes.

Spolsky: Um… ahh.. and they have needs for IT Development of some sort.

Atwood: Right.

Spolsky: But if you’re going to be an IT developer at ACME you’re not treated very well; you’re a typist.  Nobody understands what it is that you do or why it is that you’re good and for various reasons they hire all kinds of idiots to work with you in the same department because they just have no idea what a good programmer is and you’re never going to work your way up to CEO and you’re never going to be at those all important executive retreats where the important decisions about whether to play golf in the morning or the afternoon are made and... because you’re just not important to their core business which is making widgets.  And dynamite, I think.

Atwood: Right. [chuckles]  Explosive widgets.

Spolsky: So, all else being equal it might even be better if ACME just outsources all their work to, let’s call it "Coders-R-Us" where there’s a gang of cool programmers and they’re real careful about hiring the great programmers ‘cause that’s what they do all day long.  And they just sort of move around from ACME to Zenith visiting different companies and solving their code problems and then moving on to the next one.

Atwood: Right.. and ideally you’d quit working at ACME and start working at Code-R-Us and become a small business person, right?  And probably make more money anyway. [laughs]

Spolsky:  Oh yeah.  The way these things often get started is that somebody is making whatever the maximum possible salary that can be paid to an individual is at a given company and that is less than the market rate for a good programmer.  So for example you know with a certain level of experience.  I remember at some point I was working at Viacom and for complicated reasons there was no possible way they could ever pay me more that the equivalent of about… let me see what I can remember... this was about ten years ago… it was about forty dollars an hour - and the market rate for programmers in my area was closer eighty dollars an hour - and so for them to pay me anything like the market rate, they pretty much had to hire me as a contractor instead of as an employee.  Which meant that I was Joel Spolsky incorporated, or whatever the case may be.  Joel Spolsky sole proprietor and I pretended to have a "consulting business" and I just sold my time to them at the higher rate and they were able to do that and it just sounds like a legal fiction but that’s the way these big companies are.  And these are actually how a lot of these companies get started and you know you sort of bring in a friend and you bring in another friend and you start taking a couple of extra gigs on, and if you’re lucky pretty soon you have a bunch of clients.

Atwood: Right.  I think my general advice here is life is really too short to do things that you don’t enjoy doing, I mean, you spend eight hours a day at work - why not do things that you love with people that appreciate the things that you do?  So that’s sort of the perspective from which I view the off-shoring and outsourcing thing.  I mean you can be on the receiving end of it and it could be a net-positive, or you could end up on the short end of the stick in which case it’s not so good.

Spolsky: Now but then... I do want to follow this to its logical extreme and so let’s say that you’re working as an individual consultant and then you bring on a couple other people and pretty soon you’ve got a team of your 20 guys. Guys and girls.  Your 20 professional, technical, developer type people and you’ve got some sales people and you’ve got a whole bunch of clients lined up and you’re doing all these gigs for these clients and then all of a sudden what you’re going to start to notice is that you’re charging by the hour and you're paying people by the hour and therefore the total maximum amount of profit that you can make in this business is just a function of how many people you can hire, in other words with 20 employees then you can imagine making two million dollars a year in profit (although that’s kind of pushing it, but that’s like based on sort of New York rates) and in order to have four million dollars you have to get up to forty employees and now all of a sudden it’s just a game to see how many employees you can get and at some point you start kind of reducing the quality of the employees a little bit and it just becomes this gigantic recruiting exercise where whoever can recruit the best makes the most profit and in fact I hate to say this but Fog Creek actually started out with this as our initial goal.  As the first thing we were going to do as a part of boot-strapping was to create this consulting firm and one of the reasons that we have such great conditions for programmers is that we thought that would allow us to win that recruiting war and be able to recruit the most people and treat them the best have them stay with us the longest and therefore be the most profitable in that kind of "body-shop" business or that consulting business where you’re basically just providing people with some where you’re providing your customers with a human being with brains for a fixed number of hours. 

But compare that momentarily now, to the software business.  Because in the software business, as soon as you've written some code, you can license it or sell it again and again and again and again and again, without writing it again and again and again.  Which is very different from a typical IT consulting kind of arrangement.  That means (among other things) that you can make a lot more profit, because the profit is no longer constrained by the number of employees you can hire, it's just based on how many sales you can make, which is a function of how good your code is.  So if you write good code, you probably want to start getting into basically the licensed or hosted software business, where there's some kind of scale, there's this scaling that you can do that doesn't require you to bring on more warm bodies.  And that's really the long-term goal. 

In the early days of Fog Creek when I was trying to evangelize this idea to people, I would always draw two charts.  One was showing a line going up linearly and saying "Your profits are a function of the number of people and that's the consulting business, but we also want to build a software business," and a software business you sort of superimpose a hockey stick on that line, so it takes a while to start up, but when it does, it goes up a lot faster than the number of people and pretty soon the core of the business is in selling software licenses or in hosting software that you provide for other people.  And it scales a lot better and you can make a lot more money, faster.

Atwood: Right.

[1:07:08]

Spolsky: And one thing, which really surprises me, and this is the only way I’m gonna touch on the offshoring question of people in Argentina and Eastern Europe and India, that are doing this kind of offshoring.  Is they are all looking at Hyderabad and Bangalore
as their model.  Which is they wanna be, they wanna do the drudge work for cheap for American companies that don’t wanna this stuff instead of looking at Israel as their model.  And the Israeli model is not offshoring, or outsourcing or taking the drudge work, or taking the programming work and just dumping it in some country where the wages are lower.  The Israeli model is: "we're gonna make some companies and these companies are gonna do highly innovative things and they gonna sell software, and they're gonna make big profits," instead of just providing kinda warm bodies that are neatly bundled for you to use in packs of ten with a program manager and two testers.  So one thing that’s always a little depressing to me about much of the offshoring world is that they're just not ambitious enough, you know they’re not ambitious enough to make real software companies and to make product companies.  They are still, they are still trying to do this kind of low wage programming kinda thing.  Which to me is, you know, a quick way to make a buck and to get started, but in the long run you really wanna be selling something where what you’re selling is intellectual property, because it can be sold again and again and again and eventually becomes much much more profitable.

Atwood: Right. And I think that falls under the umbrella of “just try to be good at your job”.  I mean everyone that I’ve ever worked with that’s really the only thing that I really ask of them, or I really ask of the company that I’m working for.  Just be really good at what you’re doing, or try to be really good.  And you’re right, if you set the bars like all what we’re gonna do – basic drudge work, it’s like… Again you probably wouldn’t wanna work for a company like that.  Would you, really?  So, you’re right, they are not aiming high enough, they should be trying to do…

Spolsky: Yeah.

Atwood: …you know, boutique development at very least, right?  If your model’s by the hour, then do really good development by the hour, that you’re really proud of.  And that’s the kind of company that I would, I think, attract developers that I would wanna work with personally.  So.

[1:09:11]

Spolsky: Right.

Atwood: So.  We should probably cut it off here, cause we are a little long.

Spolsky: Okay.  Well, I've got some deleting to do.  In the meantime, let's see.  Do we have any announcements for this week?  We had a great - by the way, we had an open house here at Fog Creek last week. 

Atwood: How did that go?

Spolsky: It was pretty good.  It was mostly your people that came.

Atwood: Are you serious?

Spolsky: Na, I'm just kidding.  I was surprised, actually, at how many people came and heard about it from the podcast, as opposed to the web site.  And, a lot them of actually in turn had never heard of me before they went to Coding Horror, and you started making this podcast-type thing with this other character.  And that's how they found... about...

Atwood: Well, I want to renegotiate our contract now.

Spolsky: Well, not everybody, also I had to tie down the Tumblr team.  The whole Tumblr team came out.  So, I had to calm them down.

Atwood: Did you wag your finger at them?  I want finger wagging.

Spolsky: [laughing] There was finger wagging.  And actually, that was a lot of fun: the Fog Creek open house.  We'll probably have another one as soon as we move into the new office.  I'm thinking 2014 right now.

Atwood: Is the schedule really off?

Spolsky: No, there's just no way to know.  I just can't tell.  And you know what, they know and they won't tell me. [laughter]

Atwood: You can't get them to use FogBugz.  It's just like me, they won't use FogBugz.  That's the problem, isn't it?

Spolsky: Yeah.  Well what it is, is that, you know, I can see that they're making progress every week, but it's really hard for me to tell what's not done here.  Sometimes, I'll go back two weeks in a row, and it doesn't look like anything's happened.  Sometimes, it'll look like a lot of stuff has happened.  There is a lot of activity going on there, and one thing, which I'm relieved about, is when you're doing construction there is all this stuff that can delay you which is usually caused by long lead time items, like you ordered a very special light fixture and it's going to take twelve weeks to get, but the nice thing about those long lead time items is once they arrive you just snap them in place, it takes no time at all to install them, and a lot of times this can be done after you've moved in.  The stuff that takes a lot of time is putting up all the walls, and the electrician doing all the wiring, and the ceiling grid, and ventilation and stuff, and that stuff has no lead time at all because it's just common building materials that are readily available so that never really slows you down, and the long lead time items never really slow you down because that stuff eventually arrives and they just throw it all in in one or two days.  So, I'm not entirely, completely, really worried about it - yet.  So anyway, there will be another Fog Creek open-house, you will be able check out our nice new office downtown.  In the meantime, as usual, there is an online wiki, where our listeners provide transcripts of this program, and you can find the links there from blog.stackoverflow.com, or you could just go to stackoverflow.fogbugz.com and look for the wikis.

Atwood: And, I had a thought.  People who have sent in questions about StackOverflow that we haven't gotten into, or haven't gotten to play: please e-mail me.  And, again, you know how to figure out my e-mail address.  I will add you to the beta.  E-mail me (Jeff) directly, and I will definitely add you to the beta as a way of compensating you for a question that we didn't get to.  And, I think honestly you will have better questions once you have actually seen the site anyway.  So, I view your question recording as your pass to get into the beta.  And, additionally people who edit, let's say two minutes on the wiki, e-mail me and I'll hook you up for the StackOverflow beta, as well.

Spolsky: Right, so that's the easiest way to get into the beta and see it before everybody else.  Also, if you want to... we do welcome your questions, we did a whole show of questions today, but we'll always try to play at least one to three questions, so do keep sending them in.  To send in a question you can record an mp3 or Ogg Vorbis sound file and e-mail it to podcast@stackoverflow.com.  If you don't have a way of recording it handily with your computer, go to cinch.blogtalkradio.com, there's a link on the website, and there's a phone number you can call which will record an mp3 for you, which you can then send us.  That's it, see you next week.

Atwood: Bye.

[1:13:48]

music, outro.