37signals Podcast transcript

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

Episode #21: Programming roundtable (Part 2 of 3)

Matthew Linderman: Hello and welcome to the 37signals podcast. I'm Matt Linderman. We're continuing in our programmers' roundtable discussion here from our Chicago office. Who are you guys?
Jeffrey Hardy: I'm Jeff Hardy.
Jamis Buck: I'm Jamis Buck.
Jeremy Kemper: And I'm Jeremy Kemper.
Matthew: You guys are more animated this time. It's going to be exciting. So we're answering questions from readers at Signal vs. Noise. Let's get back into it. Michael asks how many of you believe anyone can learn to program as well as you do?
Jeffrey: I think anyone can learn how to program. I taught myself how to program. I've always had this sense that whenever I saw somebody else doing something, if they could do it I could do it, and that I just needed to practice. So I think that if you enjoy it that's all you really need. If you like programming and you do it every day you'll get good at it.
Jamis: Yeah. It's a matter of practice. Are you willing to practice and do what it takes? Some people take to things more readily than others but there's no reason ... [overlapping talks]
Jeremy: Just keep working at it. It reminds me of when I was looking forward to learning how to drive. Just seeing other people do it and having that internal sense of well, everybody can do these kinds of things. It's just going to work out. You've just got to stick to it.
Jeffrey: I think I learned it from skateboarding. You could watch videos and you watch other people do stuff that seemed impossible but given enough time and practice you can also do it. Then it becomes very natural. It just taught me early on that if I just tried the stuff long enough I could do it.
Jeremy: Yeah. Practice makes a huge difference in getting into programming and really enjoying it, makes it easier. If you want to get into programming as a field because you want a career change or something, but if your heart isn't in it, it's going to be hard to put in those hours of just enjoyably pursuing it as a hobby to get to the point where you feel capable as a professional programmer.
Jamis: A big reason that Jeremy and Jeff and I work at 37signals and do what we do is because we've spent time in our free time writing software. It's something we enjoy doing even as a hobby on the side. You put in the hours. As corny as it sounds I've had so many people who say I could never be a programmer. I could never do that. When you tell yourself stuff like that it's a self-fulfilling prophecy.
Jeremy: Yeah. I see that with, it reminds me of math. People say that they're as bad at math and that's usually code for I'm anxious about math. I don't feel comfortable with doing an algebra problem on the spot. But anybody can learn it. Anybody can learn how to do algebra. Totally don't shoot yourself in the foot with that kind of psychological dagger and you can definitely do it.
Matthew: What are some of the software project you guys have worked on on the side?
Jamis: Rails.
Jeffrey: And usually just stuff to solve annoyances with your own computer. I always had this idea that I own the computer, I should be able to make it do stuff. So I write a lot of stuff that I just run on my local machine to make things less annoying.
Matthew: Any examples?
Jeffrey: Yeah, like going through my iTunes library and consolidating things like iterating over files, cleaning them up. Just tools for automating like configuration that you would have to do. Pretty much any time I have to do something twice I'll just write a script for it.
Jamis: And I wrote Net::SSH and the SQLite-Ruby stuff just in my spare time. I wrote an eBook reader for the windows mobile thing 10 years ago. I've done some Palm development just on the side. If something interested me I'd dig into it and start tinkering and be more experienced that way. I learned what I liked and what I didn't like.
Matthew: Alright. And you guys might have already answered this but there were a lot of questions along these lines. Mike Graf asks could you make some comments advice for noobs in the programming world. A lot of people were asking things like what advice you have for somebody who wants to get started in programming. How would you respond to that?
Jamis: It's pretty much what we were saying.
Jeremy: Just do it.
Jamis: Just do it. If you over think it or if you think you have to read a million books before you can jump in you're never going to get started.
Jeremy: Pay attention to that need of really doing something that interests you and solving a problem and using the programming language as a tool to solve that problem. Something that I've seen among new programmers is dancing around that central piece of problem solving with the tool and worrying more about the libraries you choose or the tools that you ought to be using. It's like going out to do carpentry and spending most of your time worrying about the tool belt you pick and the kind of screwdriver. Those are kind of irrelevant. If you're into problem solving, solve the problem and just practice doing that.
Matthew: Michael Till asks I would like to know if you use some agile software development methods frameworks especially like scrum, etcetera, and what do you think about them and the whole agile methods revolution in general?
Jeremy: I think that's built in to the way that most people just naturally work. We don't have methods so much. I'm not really familiar with scrum.
Jeffrey: I don't even know what it is. I've heard the word but I wouldn't be able to describe it.
Jeremy: I think working in an agile way is pretty cool. I think that's just the way people work. The agile revolution was more about changing companies that are full of process and cobwebs and clearing all that out and letting people work in a natural kind of way. That's where a language like Ruby is really awesome because it's human centered. It's the way that people want to program. It's the way a hobbyist would be working on a weekend rather than a corporate a corporate cubicle person working on a Wednesday.
Matthew: Chris asks are you going to use any advanced artificial intelligence things like machine learning, information retrieval, natural language processing in your products in the future? Why or why not?
Jamis: We've done some of it with Sortfolio, for instance. We plugged into Amazon's Mechanical Turk to help filter the portfolio images that people upload. Although that's not necessarily artificial intelligence there is intelligence involved there.
Jeremy: I think there's human time in Backpack and it's a little bit of natural language processing. We had mixed results with it. It was really neat and it's a cool shorthand but when it falls down it's really confounding. You don't know what to do.
Jeffrey: It's easy to get to the 80 percent on a lot of this, but the problem is that last 20 percent is so annoying when it doesn't work right that you almost have to do 100 percent or nothing to hit the sweet spot.
Matthew: Ashton Brown asks, "As a web designer coming from a graphic design background I like to hire programmers for any development. What are some key questions I should be asking them to shed insight on their capabilities and abilities to do a good job?"
Jeffrey: I don't know. How opinionated are they? When people have strong opinions about things, when they can talk at length about something it's a good indication that they're passionate about it. Probably the actual tech doesn't matter. What they're using, if they're using Ruby, if they're using Python. You can get a sense of just how much somebody knows about something by how adamant they are about it or passionate they are about it.
Jeremy: I would suggest looking at open source contributions. It's a little bit more difficult if you're a graphic designer, trying to look through somebody else's code. You're not going to know what you're looking at, but the mere presence of code is a good indicator, too. The fact that somebody is contributing at all means they're using the tool. It means they're scratching an itch, like they ran into something that they thought should be improved, or ran into a bug and they fixed it themselves. That level of participation is a good discriminator.
Jamis: And I've heard some arguments against, this goes back to if you want to be a programmer make sure you enjoy it. Not necessarily do it in your free time but a lot of people I've heard argue back against that saying how am I supposed to do it in my free time? I've got all this other stuff. You're saying you won't hire me unless I code in my free time. It's not so much that coding in your free time is the important thing so much as it is that you're showing that you're passionate about it and that you have opinions like Jeff said. You feel strongly about things and you're not just lukewarm.
Jeffrey: If you're passionate about it, it's likely that it will be using up your free time. That's the thing you think about. That's the thing you want to make time to do. You would rather be doing that than cutting the lawn. [laughing]
Jeffrey: You can't wait to get the lawn cut so you can actually go hack on something.
Jamis: And mow the lawn on weekends because it's so fun.
Jeffrey: Yeah.
Jamis: And do it on weekdays too.
Jeremy: There's one other thing with looking for programmers. It can be kind of difficult to get a handle on but just the way that they work. I don't know a question you would ask but the ability to ship software is critical. I'm not sure that you could ask any one question because everybody would want to feel like they can ship software. That's the whole point. Perhaps something about software that slipped, software that's been on time and why, how they manage the very task oriented part of you actually need to get something done and finished by a certain time. So just asking about how they manage their work, manage the project probably helps.
Jamis: And probably something about, we've talked about in other areas, maybe working on a smaller project first with someone before committing to hiring someone full time. Definitely, try someone out, may be the best way to really know how you work together ... [overlapping talks]
Jeffrey: Right, which is what we tend to do. We try and run people.
Matthew: Try before you buy?
Jeremy: Mm hmm.
Matthew: What's the usual type of project or scope of something while you're trying to test someone out? What's a good target for that?
Jeffrey: Sortfolio is an example. It was interface first, design needed to be wired up. So the scope was pretty tight. You could look at the screens and see what it needed to do.
Jamis: Yeah that's actually a really good way of probably hiring a programmer, if you're a graphic designer, is making a design and seeing how the person would naturally reach out and interact with you to implement it. Having that to limit scope and saying I want to see something. Let's time box this to a week and see where we go. See how the person interacts with you. What questions they ask so it reveals their understanding of your design. The trial run is definitely better than asking three questions.
Matthew: What you just described is the way Jason and David first hooked up in the first place. As a designer looking to hire a programmer to help build an actual product? Alright. Let's keep going. Maksymilian Sleziak wonders what would you do if Ruby didn't exist? Which language would you use?
Jeffrey: I don't know. If Ruby didn't exist wouldn't there be another Ruby-like language . . [crosstalk]
Jamis: Something would be filling a sweet spot.
Jeffrey: Right. They're similar languages. I don't mind working in Python but if somebody made a better Python that was more Ruby-like I would want to use that. [laughing]
Jamis: I've always loved the C programming language. It's where I cut my teeth and I did a lot of work on it at BYU. If I wasn't doing Ruby I would probably still be doing a lot of C programming. I really enjoyed that.
Jeremy: I'd definitely be using Python. Other than Python, Ruby at the same time and work similar problems. Do something in Python because I'm feeling like it's edging out Ruby in my mental space, and then try the same thing in Ruby and feeling like Ruby just fits a little better. It's tailored to the way I think and the way I work. But Python could have been pretty comfortable, too.
Matthew: Al Vadis wants to know what do you think about BPM? Did you try to test or implement it in 37signals?
Jamis: Beats per minute? [crosstalk]
Jeffrey: I'm not really sure what that means so if we've implemented it. It was unintentional.
Jeremy: If it's an acronym it's... [laughing]
Matthew: Alright. Manuel says what do you think about action scripts/Flash versus HTML 5/CSS 3?
Jeffrey: Yeah, I think Apple put the nail in the coffin on Flash.
Jeremy: We ignored Flash anyway.
Jeffrey: Yeah.
Jeremy: Why use this tool when you can use these other, better tools?
Jamis: We've been using Flash a little bit. Like it's ... our advanced uploader in Basecamp is Flash-based. And the little ping noise and campfires of Flash ...
Jeremy: It's basically adding a couple of things that we can't do, or we couldn't do in HTML.
Jeffrey: Right. But as soon as, yeah. But if the browser could do this on its own, we wouldn't be using Flash to do it.
Jamis: And HTML5 sound like it's going to fill those gaps. That's pretty much where we're looking.
Jeremy: Yeah, we're definitely moving toward HTML5. We're taking advantage of some of it, especially doing optimizations, particularly for the iPhone and iPad. And being able to target WebKit means that HTML5 already works today. We can't rule it out in our main products because not everything is HTML5 compatible yet. But we're getting there.
Matthew: Ahmad Alhashemi asks "I'm sure that each one of you is competent enough to code every feature in Highrise. Would you say though, that any one of you could have got that to fruition as a solo developer?"
Jeremy: It was actually built by a solo developer, so yeah. David built it over the course of a couple of iterations and ... so I think it's technically possible, but it kind of erases the interaction that goes into building an application. And there's a lot of back and forth between multiple programmers and a designer and a programmer. But if you think of it as just like building a tower out of Legos and ...
Jeffrey: One brick at a time.
Jeremy: ... and you lose the picture of what you're building.
Jamis: And yet ... the question, too, is "Which Highrise is he talking about?" Is he talking about the Highrise that was launched in 2007? Or is he talking about Highrise as it exists today? Because the two products are actually pretty different now. And to have written today's Highrise from scratch would have been a much more daunting task. For a single programmer.
Matthew: Yaroslav Dmitiriev wonders "How do you share common functionality across your Rails projects?"
Jamis: Plug-ins.
Jamis: That's pretty much the only way we share the functionality. We do some things like with, what is it, Sortfolio? Where we're sharing functionality via web service. And to do avatars and things like that. We've kind of branched out a little bit that way. Also, with 37signals ID, that's mostly plugged in on a shared database. But ...
Jeremy: That's something that was new for us. We've really pushed back on doing shared models, shared databases. And 37signals ID is built into the way that each application is modeled, so it turned out to be a pragmatic choice. So, something where we changed our minds, tried something new. In most cases, we aren't sharing things like the domain model itself. We're sharing things like utility libraries, things that that core application would use. It's kind of at arm's length, and 37signals ID is the first case where we're actually sharing, like an internal organ amongst them all.
Matthew: Eric Hayes wants to know "How do you fight feature creep? How do you filter, all that's possible, down to what's essential?"
Jamis: Scope hammer, right?
Jeffrey: Yeah, the scope hammer.
Jeremy: That's pretty natural, too. And to me it's like asking whether we do agile development. All of us have this kind of built-in sensibility to shed features. It's feature-phobia, I guess.
Jamis: I actually disagree with that.
Jeremy: Yeah?
Jamis: I think a lot of people have a desire for more ... I know when I'm looking at code, I'm like "Yeah, we can do this. And we can do this." And I have to step back and take the ax to some of the ideas. So it might be natural to some, but I think people like me, we tend to, we want to pile more on.
Jeremy: I'm thinking in terms of designers, developers, talking together. Like when we're in a planning iteration and pushing back, or I'll push back on designers saying "We really need to be able to do this." And to be able to challenge the ... Well, it's going to take more time, it's going to take more work. And despite designers being ... They respect that. But at the same time you need a coherent design. But every part needs to be checked to have that kind of pushback of "Do we really need all that? Do we really need all that?"

When it comes to code internals, I'll get into aesthetic judgments. Or you looking at code and it just ... It's fun to be able to go in and beautify code and you start at step one and you go through multiple iterations, improving code. And then once you're at step ten, looking back it's easier to see the full history of intentions so you could rewrite it to make the current code match the whole history of where you had arrived, rather than being layers added one after another.

So you could make it prettier, but that's often wasted effort, because what you have works. What you have got you from, through step one through ten. And it's definitely not worth the time to make a very beautiful object, just for its own sake. But if I were programming over the weekend on my own library, that's exactly what I'd be doing. So it's a little bit at odds. Trying to hold back on making those choices during the week.

Jamis: Another way of looking at that question is to step back and say "What needs to happen to get this feature live?" Not necessarily "What's the minimum I need to do?" I mean that's part of it, but if something isn't necessary for the initial launch then you might as well not do it. At least immediately. We'll often say "That's Version 2." Or "What are we looking at for Version 1?" Just looking forward saying we can do these other things, but not right now. So that's one way to compromise with the feature creep, is to say "That's a good idea and we may do that. But let's prioritize that down a little bit and focus on the essentials."
Matthew: Alright. We got a few more questions, but why don't we wrap up this episode here. You can go to for other episodes. We post transcripts there, and also related links to each episode. So we'll be back with the programmers again. Bye.

More episodes of the 37signals Podcast.