37signals Podcast transcript

Subscribe to the podcast in iTunes or your favorite feed reader.

Listen to Episode #22: Programming roundtable (Part 3 of 3)

Matthew: Hallo, and welcome to the 37signals Podcast. I'm Matt Linderman, we're doing a Programmer's Roundtable here at our offices at 37signals. Why don't you guys introduce yourselves?
Jeremy: I'm Jeremy Kemper.
Jamis: I'm Jamis Buck.
Jeff: And I'm Jeff.
Matthew: Alright, let's get into the questions. These are questions from readers at Signals vs. Noise. And someone named Devang Kamdar asks, what's a typical workday like?
Jeff: I'll go. A typical workday? I wake up slow, I want to get up and have at least an hour, two hours before I get online. I think we all sort of are online by 10 in the morning, we're all in different time zones. I'm in the Eastern time zone, so I'm usually online at 10 but there's no hard start time that we're all in our Campfire. So, I wake up, I sit around, I join the Campfire and then I sort of find, wait until you have a free block of time to decide what I'm going to work on and work on it. I usually sort of cycle on and off in the day, I don't really get too focused on anything and I do most of my work at night, where you can get like a three or four hour uninterrupted block. And I find I can get more done in that time than I can in the whole day.
Jamis: I try and stick to the traditional 8-5 block, mostly because I have kids and I like to spend time with my family after, you know, in the evenings. And then in the late evenings I like to work on my own projects. So, I'll wake up in the morning, log in, check email, do that for about a half hour and then look at the list what needs to be done, what tasks are still open, what's on my plate and start working through it.
Jeremy: Usually I wake up pretty fast. I'm thinking about what's on my plate, what was left over from yesterday. I try to clear out distractions early, I read through email, triage it and mark things as read. And then joining Campfire is kind of like coming into the office, all three of us are remote. So, open Campfire, it's kind of the beginning of the workday, scroll back and see what other people have been up to. I'm in a shifted time zone, so I'm behind by two or three hours. So, see what's going on and just get to work. I usually try to knock off early but things will drag on also. But generally try to keep a normal workday.
Matthew: It seems like it's more common for you to commit stuff at night sometimes. Do you feel like you can get more done when you're just on your own?
Jeremy: I definitely can, I try to avoid too many late nights. I have the same thing where I, having a four hour block at night and nothing is happening, there's no claims on your time. It's just kind of like you have a little bit of a flow state there where ... And also, my mental processors are kind of settled down and not feeling distractible. One thing that I really notice during the day and day to day work, I'll work in about half hour bursts. I work at a standing desk, so you can just walk away. It's one thing I notice when, I don't really sit down much anymore, but when I was sitting, and the natural thing to do when your mind starts to wander and your attention is, you're losing your kind of attentional focus, is to just do random crap on your computer.

And so, check your email or something. And being able to leave the computer kind of just stops it right in its tracks. So, I'd go outside, make a cup of coffee, just get away and do some other task and refresh your brain and come back to the computer and you've had that time to let things simmer a little bit and you're ready to go again.

Matthew: Devang also asks "How do you protect intellectual property, especially proprietary code?"
Jeremy: From whom? [laughs]
Jeff: We keep all our code on, all our 37signals stuff is on an encrypted volume. The idea is that if our laptops ever got stolen they'd be useless to anybody who wouldn't be able to get at our stuff. We always store our repositories ourselves internally.
Jamis: We use NDAs where necessary, where we've got people coming in from the outside and we don't do that very often though.
Jeremy: Yeah. And most of it's really a lock down of our own personal stuff. It's kind of hitting the buttons and you have to mount an encrypted volume, you got to make sure that everything that could be sensitive is actually being stored on that volume. So, if you're using iChat and you have the transcripts on you knew you'd be going to the right place. Though there are little things that you need to check, if you're actually trying to be secure. It's very difficult.
Jamis: We have a checklist that we keep in our Backpack that's like "Make sure your chat's on the encrypted volume, your mail.
Jeff: Make sure you're using ...
Jamis: Use SSL with Gmail.
Jeff: And make sure your wireless network is secure, things like that.
Jeremy: And definitely have a password to get into your computer, lock the screensaver.
Matthew: Right.
Jeremy: Looking from the outside at some of these things, man. It's like we're working in this secure vault and it seems a little ridiculous to me sometimes but I don't know what the real threats are or what could actually happen. I mean, the whole idea is, what if the code to Basecamp got out in the wild and it becomes a thought experiment. I don't know what would happen but thankfully we have a reasonable checklist and being able to go down and make sure that your computer is secure.
Jeff: And once it's setup it's not too bad. It's kind of a, like Jeremy said, it's kind of a hassle to have to melt the volume but Knox, that program, makes it really straightforward.
Matthew: Mark Dodwell wants to, well, I'll read you his question. "Fixtures get bad press but Rails Tests use them by default. Do you use fixtures and if so, how well do they work for you?
Jamis: We do use them. We don't use any other fixture replacements ...
Jeff: Well, Sortfolio does.
Jamis: Oh, it does?
Jeff: Yeah, I can't remember what it's called. Factory girl, or...
Jeremy: Yeah, one of these object creation things and it's similar to fixtures except that it's not static. You're actually writing it in code.
Jeff: That's using the ...
Jeremy: We're generally trying to avoid adding Fixtures and one thing you may notice in our code is that we'll reuse fixtures as much as possible and often it will be using them as in kind of a foundation and either modifying them for a test or you can see in tests we create new stuff. And so, making a fixture in line rather than adding static global fixtures for everything. Or tightly scoping things a bit more but again, we're not using a specialized library for that, that's just plain Ruby code.
Jeff: And the fixtures that we have been in the code for years, like Basecamp's fixtures, their names are familiar to us. We know that you can load up, ask for this username and this guy's an admin and this guy's not. And so, it's just sort of natural to, you know, it's committed to memory. Probably if I was starting over, and we have a pretty big set of fixtures for something like Basecamp and they're all consistent and the relationships make sense. And if I was starting over ... yeah, maybe I wouldn't invest so much time in fixtures but they're there and they work.
Jamis: When they're consistent and when they already exist, they're a boon but, yeah, adding new ones is kind of painful and ... I mean, there's a reason they have a bad press but I don't know that there's anything out there that doesn't have drawbacks.
Jeff: One interesting thing that we do, we use fixtures to load up data that we can use locally. And one interesting thing that we do that I don't know how easily we'll be able to accomplish in other ways, that we share fixtures. So, 37ID, for example, in QueenBee, our billing system, we share the fixtures between plug-ins so that they're all consistent, so that when, you know, a user in Basecamp looks to its 37ID user, those are all shared across apps. And that makes it possible to load up all the fixtures and have a working user across all apps. And that would be kind of hard to coordinate without that.
Jeremy: Yeah, that really bleeds into our development environment where have this kind of domain knowledge for testing where these certain fixtures are always present. But they're also always present for development, when you boot up an app, you have an existing environment, everything works together.
Matthew: Right. Philippe Lang wants to know "Do all members of the team work with the same environment, like Textmate and Shell on a Mac? Or do some of you use other tools also, like Eclipse or Windows?
Jeff: Nobody uses windows!
Jamis: Nobody uses Eclipse!
Jeremy: Windows? Fired!
Jamis: [laughs] Yeah!
Jeremy: Everybody uses Macs and a variety of different tools. I think the only big variances are choice in text editors and ...
Jeff: Right. Textmate and Vim. I use Bash, Sam uses ZSH. Does anybody else use a different shell?
Jamis: Bash and ZSH.
Jeremy: I'm Bash also.
Jamis: I've used ZSH in the past but honestly, Bash is just so available that it's just easier to use Bash.
Matthew: Alright, Luis Molina wants to know "Do you use any code generation technique apart from the scaffolding in Ruby?"
Jeremy: Just typing!
Jeff: Yeah. I mean, we generate code where it's necessary to cut down the repetition, like I think about our server configs. You know, they'll ... rather than specify everything manually, we'll generate it. I mean, not really for bootstrapping code. We don't really ...I've used the generators in Rails, I usually will just make a new file.
Jamis: Yeah, I haven't used the generators in a long time. I don't know that we've used the scaffolding in Rails ever.
Jeremy: Ever, yeah. Scaffolding is great for getting started, if you're getting started as a Rails developer. It's a good way of spiking out a little app but generally you're going to change it so heavily immediately that after you've worked with it for a while, it's just as simple to start from scratch. You know where you're headed, you know what you want and especially with restful routes and controllers and Rails. You're starting from the routes file and saying "I'm going to add this resource" and you can just go down from there. For this resource I need this controller, I know what they're actions are going to be in that controller, I know that I want to expose an API for one. So, that whole model is already there. And Ruby is so concise that typing it out is quicker than taking a scaffold with everything in it and paring it back down.
Jeff: Right. I use the generator for migrations and generally migrations ...
Jeremy: Stick it with a timestamp.
Jeff: Because you get the timestamp and sometimes it will specify extra things on the ... you know, arguments to set my columns ...
Jeremy: You know, it's funny because I will make migrations and I'll just make up a timestamp. Well, I mean, you can just, you can copy an old file and you'll notice that the hours, minutes, seconds are the same as well but the date has changed. [laughs]
Jamis: [laughs]
Matthew: Leandro Lopez asks if you use any kind of master slave database replication schema with Rails. Could you tell us which plug-in/gem you're using for it?
Jeremy: I think he's asking about rewrite splitting. So, we do master slave but it's for backups and it's for hot standby. [clears throat] We did rewrite splitting for 37signals ID when we moved data centers. So, as our applications moved from one data center to another, about 80 milliseconds of pinging apart, we rely so heavily on talking to that database, that shared database, that it maintained performance. We split reads to a local slave in the new data center. And we just used Ruby code. We looked at some tools but it's almost too automated, we knew exactly where we wanted to use the master connection, where to do the writes. And so, rather than trying to, or having to cope with the uncertainty of whether the reads and writes are going to be split correctly, we just used a little bit of Ruby code to establish a connection to the correct database in those exact places where we wanted them.
Matthew: Alexandro wants to know "How do you decide when looking to add functionality? Whether to use an existing solution or roll your own? For example, before your redesigning, was there any consideration given to existing platforms, like Stack Exchange, or did you pretty much know you were going to do it from scratch?"
Jeff: Sometimes it's just so much easier to do it from scratch. I feel like you spend less time just building the parts that you need than worrying about something else, and probably there's a bunch of stuff that you don't need. So, we were able to do the answers board really quickly ...
Jamis: Well, the original forum was based on a little product and it was a hassle to maintain. Beast was great but we needed to customize it a lot and then once we customized it, it was so hard to bring it up to date with changes to Beast and it was just got to be kind of a pain to keep it all up to date.
Jeremy: One thing that helps us to keep in mind, is the actual effort that goes into building applications is fairly low. And starting a new application is easy and when you're thinking of the bigger conceptual picture, like "I need a forum", it's seems natural to go "I want to go to a big box store and grab it off the shelf." So, I'm looking at existing tools but then trying to customize that is just often too much work. Where something like Answers, we spiked out in a matter of weeks, it was a couple of weeks. And everybody's seen the Rails screencast. You can build a blog in 5-15 minutes. Everybody knows you can build Basecamp in two weeks. [laughs]
Jeff: Yeah! [laughs]
Jeremy: So, it shouldn't be daunting to dig in and just make something that's exactly what you need.
Matthew: Matt McCormick wants to know "How do you stay, or how do you keep up your interest in a project or product? Generally I get bored with projects after a few months."
Jamis: Our team structure, I think, really helps that because we aren't stuck on anything for more than about two months, with some exceptions, like sometimes it will be a long running project where someone might be needed to stick around for another two months to pass on the information about the project to whoever's coming on next. But generally we work on small things, quick iterations, two or three weeks maybe for a single feature and then you move on to another product even to add something there. There's not a lot of opportunity now for getting bored with what you're working on.
Jeff: Even before the team structure, you didn't find, we sort of naturally would do things in small chunks. I mean, if you're getting bored then you're not doing good work, you're not motivated and none of us want that. So, we sort of have this built in desire to keep things small and achievable so that we can move on to something more exciting. So, I don't really give myself much of a chance to get bored. If I'm bored or if I find myself starting to get bored, I just ... you know, it means that I've got to stop and like, what can I ship now and how can I go on to the next thing that feels new?
Jeremy: I think that that feeling of being bored, it's often ... and there's a little bit of self entitlement, like your job should be interesting you. If you're bored, you're boring. You need to think about what you're doing and find excitement in it. It takes motivation, it takes energy and you've got to pour it in. And if you're not feeling it, you're not feeling motivated, the answer probably isn't in the product you're working on or the code you're working on. It's about, it's in your approach to it and how you think about it, how you think about your life and there's probably other things going on.
Matthew: Well, Jeremy, you did a lot of work on 37ID, which was probably the biggest scope thing that 37signals has ever done as far as far as it took, what, nearly a year?
Jeremy: Yeah, I'll say a year of work.
Matthew: Was that an issue for you, as you were working on such a big project that's unusual for us? Was it ...
Jeremy: Being bored definitely was not an issue. Working on 37signals ID was really interesting and it touched all of our stuff. We tried some new things and it worked out great. We tried some new things and it didn't work out. So, having that process of building something, learning from it and doing something a little bit more ambitious than what we're accustomed to was definitely cool. Those really mean for us, for me as a programmer, for us as a company tackling something like that. There were struggles in there for me that were not boredom-related and having something go on for a year and it's a lot of pressure and you want to deliver something, especially in a company where we're used to having those little quick feedbacks.

And you get a quick win, get a quick win, get a quick win and you're building up to a big win and you're missing all those quick wins.

Those are kind of programmer food. And you want to give those little treats out and it's like a form of mental starvation where you're having to just kind of buckle down.

And that buckling down is something I've seen in other places I worked where there aren't as short iterations, where that is just more of a status quo.

We're accustomed to that's what it ought to feel like as a professional programmer, as that somehow you shouldn't expect there to be joy or energy in what you're doing. It's more about you've got this deadline and you need to work at it. And it just kind of drains the life from what you're doing.

Matthew: Vladimir Mitrovich wants to know if you were to start a new web business today like you did with Basecamp, with little or no money, what setup would you use in terms of servers, version control and deployment in order to get the business up and running quickly?
Jeremy: I would deploy it on Heroku.
Jeff: Yeah, I still use Git, GitHub. And it's pretty much the same stuff we're doing now. I would not start; I would not try to set up some advanced toasting environment. I'd go like, cheap and easy as possible.
Jeremy: It's free to start.
Jeff: Yeah you don't want to get bogged down in things that probably don't matter right away. It's better to have something up and running fast. But, yeah, it seems like you don't need to worry about any of that stuff anymore. It seems... it's really nice and easy now.
Jeff: It's definitely a red flag and I would be looking for... if you're starting a new business and your concerns are dominated by your development environment or by your deployment environment you're being distracted, you're not working on your product.
Jeremy: Worrying about the wrong thing.
Jamis: Yeah if you don't have a product you shouldn't be worrying about deployment.
Matthew: Alright last question from Shannon Coffee. What kind of day-to-day interaction do you have with David and Jason? Are you coming up with ideas for products and improvements just as much as they are?
Jamis: Coming up with the ideas I don't think I am personally. Jason and David are always thinking of noticing where the friction is in their processes and identifying we could do this or that. But when they do propose an idea, when they're like "hey, we should work on something like this, " that's when I think all the team comes together and starts brainstorming and saying "yeah, " and "can do this, " or "this might not quite be feasible but we could maybe do this instead, " and we start getting the ideas go in that way.
Jeff: Well, I don't feel like David and Jason like sort of bang a gavel and say "OK, gather around, this is the stuff that we want to do." It's still very much... they might bring it up first, but it's still like an open discussion, we all talk about stuff. And as many ideas, lots of ideas float around and not all of them get picked up, and there's not like sort of like a "why didn't we run with this idea, " it usually doesn't matter.
Jeremy: I feel like when we are deciding what to do, all of us start making small post corrections and making those little choices that add up to our main direction.
Jeremy: But Jason and David, especially, are often the ones to propose a bigger leap. Something riskier. Something that will take more than one person's time. Where we can decide to do with our own time, we're self-managing in that respect. But when we want to do something that takes a whole team's time or is going to take the whole company's time.
Jeff: Right.
Jeremy: Then, that's a kind of time investment that we're often unwilling to make. And they're more bold about saying, "Well, let's just do this."
Matthew: I think, also, given our structure, it's usually not a situation where it's like a blank slate and, like, "OK, what should we work on next?" It's usually like, "OK, there's 30 ideas all the time." That they're, you know, really good ideas and could be worked on, and it's more almost like an editing or curating process of eliminating things, as opposed to generating new ideas.
Jamis: Yeah, definitely.
Jeremy: As far as interaction goes, I've noticed something pretty interesting. I mean, 37 Signals is very design oriented. We start with design, and we make it work. And that's reflected in the way that we do our jobs. A lot of the day-to-day interaction with Jason is he's in rooms, in the Campfire rooms, where we're working. And he's giving feedback on what's happening so far. Like, a new design pops up and Jason Zimdars is looking for some feedback on where he's gone with the idea.

But with programming, it doesn't really work that way. We're not popping up code in the Campfire room and asking David to validate what we've done with our design. So, we kind of have a little bit more free reign.

Like, we're all collaboratively working on the same code. And so, that validation of what we've chosen to do is happening a little more implicitly because next time you come to some piece of code, and you need to make a change, you're going to leave it prettier than you found it.

And so, I mean, design is kind of the same way, but it's a longer process. Whereas, or programming is a longer process as it slowly evolves and improves. But we don't have that, like, kind of, I guess the equivalent would be a daily code review.

Jamis: Yeah, we don't do a lot of that. We do some voluntary ones like if I'm confused about something or I'm not sure a particular approach I've done is good I might ping Jeff or Jeremy or David, and just say, "Hey, here's what I've done. Can you check this and give me your opinions?"
Jeff: Yeah. Sanity check this.
Jamis: Yeah.
Jeff: And all our commits go into our Campfire rooms. So, if a commit message looks interesting, it's very easy to just click the link, and it shows up, you know, the dif shows up in a browser. And you can say, "Ah, Jeremy just fixed that bug that was my fault." [laughter]

You know, so there is, we are sort of reviewing each other's code. If somebody makes a commit, and you're like, "Hmm. I think that might have a bug in it." You know, we'll say, "Hmm. I think that has a bug in it."


So, but we're not paying that close attention to it. You know, I don't review every single commit, and there's no, things don't really need a formal review. Although, we do tend to make sure we ask for reviews of each other's migrations. Things that are going to touch the data. Things that seem like they could be potentially dangerous.

Jamis: Destructive.
Jeff: Right. You know, you just want to have a, just another set of eyes on it, just to make sure.
Jamis: It really comes down to we trust and are confident in each other's abilities. You know, we know that if someone commits something that they're doing their best work, and they're confident.
Jeremy: Yeah. That's something that's easy to forget sometimes working with the group that we have here, and everybody trusts each other. Like, everybody can do a production deploy anytime. Everybody can commit anything anytime. And it just naturally works. There's no need for policy surrounding it.
Jamis: Yeah.
Jeremy: I guess, another thing that affects that I was thinking about that there's a lot of scrutiny of our design. And I think we don't really need that as much with code because things like automated tests. We know that our code works. That is kind of our automated scrutiny writing those tests. Like, it does what we know, what we spec'd it out to do. [music]
Matthew: All right, guys. Thanks so much. I think this was really informative, and I appreciate it.
Jamis: Thanks, Matt.
Jeremy: Thanks, Matt.
Jeff: Thanks, Matt.
Matthew: So, you can go to We've got previous episodes there, related links, transcripts... And that's it. Bye.

More episodes of the 37signals Podcast.