Atwood: We thought the worst case scenario was that we would literally branch the code.
Atwood: So then we would have two things to migrate bugfixes to all the time. And one thing - I know you guys use Mercurial, right?
Spolsky: Yeah, and that would make it a little easier, but I mean it shouldn't really be necessary to branch the code
Atwood: No, it shouldn't be, but one thing we found was that we did do a branch when we did the big database migration because that was such a big change, we had to have bugfixes go on the main line while we were working on the database change because all the fields change and all the stuff and we did a bunch of refactoring on the database, and what we found was merging that in was excruciating - it was so painful. We actually updated to the latest version of Subversion, which is 1.6 I think? And it has "better" support for merging, and it was still just brutal - we missed so many things - there were at least, I want to say, five to ten things that we missed in the merge somehow.
Spolsky: So this is why everybody is abandoning those version control systems that are of the Subversion generation and they're moving to Mercurial and Git, and, to a lesser extent, the other distributed systems. There's something that took me a while to understand about Mercurial, but fundamentally Mercurial is - Mercurial thinks of the world as a list of changes, and Subversion thinks of the world as a list of different versions of all your files. And so for Subversion to figure out where you are on a branch to do the merge, all it can do really is do a diff and say "well, I don't know what happened, but the following things - we're different from you guys in the following ways", whereas Mercurial has this sort of added info of all the steps that were taken and all the transformations that were done, so it basically has more information to use in the merge and making the merge successful.
Atwood: Yeah. I think that's the key phrase, is that it feels like Subversion does so little to make your merge successful that the success of the merge relies entirely on you doing every stinking little thing correctly, and if you miss anything then you get a bad merge, and the thing that sucks is that you don't figure out until a week later that this bugfix that you put in is not in the codebase.
Spolsky: Yeah, because it might compile.
Atwood: It pissed me off - every time I ran into I just got very very angry because I felt like my tooling had failed me.
Spolsky: Well I would highly recommend just switching to Mercurial, also because you guys are all a distributed team, right? Like the three of you are all in different places, and we're going to want to have the hosted version that FogCreek is doing and it would be really good, even if we have to fork the code, for us both to be using Mercurial, because then we could still throw each other bugfixes, even if we forked, you know, years later we can be throwing each other bugfixes.
Atwood: Are you like announcing that now on the podcast?
Spolsky: I guess I might as well, what the heck, I've waited - we have no secrets. We haven't even hired somebody to develop this thing yet; Hey, if you are a StackOverflow listener and you're a really good developer, and you're pretty good, especially - we'll hire you even if you don't necessarily know ASP.NET, and ASP.NET MVC, but if you do that's a big help, and you want to work on Stack Overflow, then we've got an opening here at FogCreek, so email your resume to firstname.lastname@example.org.
Atwood: But you have to be local, right?
Spolsky: Nope, we'll hire - you just have to be, you just have to have permanent right to work in the United States, so that means that you already have permanent residency like a green card or US or Canadian citizen. A US or Canadian or Mexican citizen with a Bachelor's in Engineering. I don't know, it's complicated; basically, no H1B's, because you just can't get them anymore.
Atwood: Why don't you, OK, well that's cool, that's awesome that you're opening it up to the whole United States
Spolsky: We always do, about half the people we hire we wind up moving to New York, more and more actually, I can't even think of any local New Yorkers that we've hired.
Atwood: OK, cool, so there's a relocation sort of thing there
Spolsky: Yeah, you'd get the whole package: FogCreek stock, the relocation package, the free lunches, the uh, anyway
Atwood: Cool. Well that's exciting, because I'll tell you my mailbox I don't want to say overflowing, but every few days I get an email from somebody that wants, would like to use the Stack Overflow engine in some way, and I just don't really have a good answer for them, so this is exciting for me because now I have at least a reasonable answer for them, which is that we're working on a hosted version of it that's going to be run on the FogCreek infrastructure.
Spolsky: Some hypothetical person that we really want to hire hopefully will hear this podcast and send me a resume.
Atwood: The funny thing about that is that we're very excited about that and we feel that it fills a real need. It's a service that you guys already do very well - it's a good fit on every possible level, but the thing that makes us all pause on the team is that other people are going to look at our code and we're like "ooh, is our code really good enough for another developer to come in and not tear their hair out?" I mean, we're probably being oversensitive, but, I think that's the reaction I have with all my code - is it good enough for other people to work on? Maybe you should spend a month refactoring it first
Spolsky: Well, I think everybody feels that way, and that is actually true that there is - there's kind of two levels of code: there's the level where it runs and it's debugged and you're kinda happy with it and you can continue to work on it if you need to. Let's say there's three levels, that's the middle level. The bad level is you know it's bad and it's a pain to work on and any time you want to change something you know you're going to be pulling out your own hair, and then the top level is like you could publish this in a book because after you got it working you went over it and refactored it seventeen times and cleaned it up and did all kinds of extra work that didn't get you any extra functionality, but did make it code that anybody could dive into, so maybe you've renamed things, you've cleaned things up, you've reorganized things several times, you've gone through the code trying to make it like literary code where the comments just smoothly, seamlessly flow with the code so you can figure out what's going on.
Atwood: Our challenge, too, is that we...