Welcome to Rework, a podcast by 37 Signals about the better way to work and run your business. I'm your host, Kimberly Rhodes. If you've listened to the Rework podcast at all, you've heard our co-founders, Jason Freed and David Heinemeier Hansen talking. about hiring great writers. We also say we should out-teach the competition. And these two things come together in many ways, and one of them is our developer's blog. To talk about it, I brought our principal programmer.
Jorge Manrubia, to talk all about it, how it got started, what we're doing on it now, and how it has helped us as a company. Jorge, welcome to the podcast. Hey, Kimberly. Thank you. Thank you so much for having me. Hey, before we jump in, tell us a little bit about you, what you do here at 37signals, how long you've been here, and then we'll dive into the developer's blog.
Sure. So I'm a principal programmer in the product team. So I work on 37 Signals product. And I've been working for 37 Signals for over five years now. Very nice. Okay, so... We've linked a couple times over the years in the podcast to the developer's blog, to particular blog articles that have been written. Kind of tell me the history of it. How did it get started? How did it come to be? Sure.
After I joined the company, I think there was already this desire in the team for technical folks to have a... place to write about technical content. So there are three technical teams in the company. We can say we have programmers, we have designers, and we have ops, which are system administrators.
And I think that it was a shared feeling that we all wanted to have a place to share our opinions because Citizen Signals is a company of builders. We like building things and we like tell the world about what we build. So back in the day, 37signals had this very popular blog for the company called Signals vs. Noise. Right. And I used to be a huge fan of it because it shared like technical posts, but also business.
posts, how to work posts, so all sorts of content. And well, I was among the many fans of that blog. So eventually the company stopped or closed the signal versus noise. So we didn't have a place to write. our thoughts. And well, a group of folks got together and decided to launch a new place. Of course, with David and Jason being very keen about having that in place. Right.
On this blog, tell me who contributes to it. I know you mentioned there's several different teams. Is everyone writing on it? I know I looked and you have several articles on it, but who kind of can contribute to that dev blog? Sure. Actually, believe it or not, the process we follow is very relaxed. Anyone in the company is able to write.
an article in the company blog. We don't really have like a very formal editorial process or any editorial process at all. It's like you have something to share, you want to write about something, go for it. It's always driven by the author. So there is... It's always about someone wanting to share something. It can be just describing how we are doing something, which patterns we are following, some piece of technology we have released, some problem.
or some crisis we went through. We touch on all sorts of subjects and really everyone is invited to write. I think it's very important that at least the article matters to the author.
right? Because you want to keep articles authentic and genuine. You don't really want to write these kind of stock articles. For example, seven ways of improving the speed of your Rails applications where you... drop seven valid points which are void of of content and of substance and just to you know to make search engines happy or whatever
I really, I personally hate that. And I know the company hates that. So I'd say that the only requirement we want to enforce is to write articles that are meaningful for the author that is writing them so that they tell something to the audience. Yeah. So it's not like a topic is assigned or it's an SEO driven purpose. It really is like someone has something that they feel like is valuable to share.
Yeah, absolutely. Also, we don't try to enforce any kind of cadence. Like we need to publish one article every week or every two weeks. It's not like that at all. And you could say, oh, but what about if we don't publish an article in, I don't know, two months? It's like, it's totally fine. I mean, publishing low quality stuff.
I'd say it's much worse, again, my personal opinion. So we don't set any kind of guidance or we don't assign articles or anything like that. Actually, how we organize the work is that we have a card table in Basecamp. So if you want to write something... You can create a card there. You start working on the article and you can ask for other folks for feedback if you feel like it, but it's not required or anything like that. I mean...
You can write an article and publish it on your own without asking anyone. That's totally fine. Okay. It's kind of our managers of one concept as well. Like if you have an idea, run with it. Absolutely. 100%. Okay, Jorge, tell me this. We say internally, 37 Signals, we are sharing what we do. We are communicating. This is our process. This is how we work. This is how we do it. We're very open about that, I think, compared to a lot of companies.
I think the dev blog is no exception. How has the blog been beneficial, not only to the company, but like to you personally? I've seen you writing a lot of things. Have you gotten feedback from the audience? Like, how has it been beneficial to you as a programmer? Oh, wow. Writing for the 37 Cygnus blog has been a blessing in many ways. I just start by saying that writing in general helps you to think. So sometimes I'm writing about complex, intricate...
problems or things that I have in my mind. And I start with a very great cloud of thoughts and things and writing them down helps me to structure it. And I clarify things a lot. for myself first. So it's not like, oh my God, I have this article. I'm going to just write it down. It's like... Yeah, as I'm writing it down, I'm learning, I'm clarifying my own thoughts, and it's incredibly valuable. I think writing, in general, is valuable for the author.
There is this quote that writing is thinking and it's totally like that. Also like. You know, regarding engaging with an audience, you know, I used to write before joining 37signals. I had my personal blog and I released open source, but essentially I didn't have any audience. So maybe I had some friends following. me on Twitter, I don't know, my brother and things like that. But I didn't really reach many people.
37 Signals has a huge audience that Jason and David and all the folks have built over the years. So by writing on their technical block, suddenly you are reaching a huge audience of, in my case, Rails programmers. other programmers. And for me, it has been incredibly fulfilling. I've written a bunch of posts about how we do Rails in the company, and the community was eager to know about these subjects.
I got to engage with a lot of folks through email, social media. People asked me questions. Everyone was very, very grateful for this article. So for me, it was very fulfilling. And also, I got to learn a lot. you know, interchanging thoughts with all the programmers. For me, it's very, you know, very fulfilling, I'd say. That's great.
Yeah. Okay. So Jorge, for someone who's listening, who might be a small business owner, might be in software, two questions. One, why should they start something like this? And two, what are things that they should keep in mind, either best practices or things to avoid? Sure. So I think, and this is not something particular to 37 signals, but in general, people are curious about...
how other places, how they do what they do. Right. You know, when you're using a product, you're really curious about what's behind the curtains of that product. I used to be like that before joining 37signal. So I have that feeling very... present. So I'd say that the first reason is that by writing a technical blog, you can get to connect with your audience better.
Because I'm sure there are technically minded people in your audience, or even if you don't want to have a technical blog, you want to write a general corporate blog. I think the same principle applies. You can connect with your article better. And I think that when you are dealing with a...
company's product for just like a black box where you don't see what's behind you just use the product but suddenly you get an article about oh this is how we organize our customer support team this is what we do These are our practices. We are using this tool for organizing how we address customer feedback.
All those things are incredibly interesting for the audience, in my experience. Something I've seen, like this is specific to programmers, but something that 37 Signals does, which is kind of unique, is that we share... real chunks of code in our technical articles. So if we're going to write about some Rails concept, we get to share code from our commercial product. And this is an idea that I know David has been...
pushing on for years, that if you're going to discuss technical subjects, you need to share it all. Because if you stay in a very, very abstract level, it's very easy to make any point you want to make. But when you share the code, then... Everything lands into the realm of the concrete. Jorge, let me ask you a question about that, because I feel like some people might be like, well, I'm not going to.
share my, like I don't want people to see that. Like they could then take it or steal it or recreate it. Tell me about that, about being so open about the code. Yeah, actually, it's pretty unique. And I kind of understand the point of view of a company that is running a commercial product and you are...
At first glance, you could be scared of sharing your code as if you were sharing your secret sauce. Right. But do you really think about that? Sharing a few snippets of code is not revealing your secret sauce at all, like at all. Rather, it's a way of making a difference, you know, because nobody is doing that. So when we're talking about commercial products, they are like these very mysterious things that run somewhere in the cloud or whatever.
You can look into them at all. So that transparency can only play in your favor, in my experience. This is not just my opinion. It's like I've seen that, you know, talking to the audience, like people love it, absolutely love it. And actually, I keep getting notifications from people that quote my articles. Oh, this is check this, check that, which is.
Because there is a genuine interest in how we do that. And also you can link that with what I said before of being authentic. Like people love authenticity. It doesn't have to be all about good things. I've written, I think one or two. posts. I'm remembering one about a crisis in Hay with some email problem in Hay. I don't remember the details, but I remember people loving it. It was like a Friday crisis with our email servers or something like that.
So in general, people love authentic content. I also really love that you get to see other people who work at the company. I mean, obviously, David and Jason are so prominent, but I love when it's like, oh, here's an article by Jorge or a write-up by Donal that you see kind of the people behind the front, the front lines. Yeah, absolutely.
In our blog, you can get to see there are fantastic articles from, for example, Jason Simders, our principal designer in the company. So if you're into product design, you know, you can get access to, you know, how a world-class... Product designer does his thing. I think from the audience perspective, it's incredibly valuable. Same with operations. We have an incredible ops team, which are, for example, responsible of moving our apps out of the cloud.
to on-prem servers, which was a big theme last year. So you can get to the blog and you see that this ops team is not like an abstract entity. You get to see like... These are real people. These are real people. And you can get to see what Faraz has to say. For example, Faraz is a senior Austin member. You can get to see how she went...
through some problems and the lessons she learned. And I don't know. It's like, I think from the audience perspective, in pragmatic terms, if a customer is reading these articles, it's going to... feel a closer connection with the company. And if you don't know about the company, it's a way to discover the company if the article is really good. So I think it's really beneficial for everyone involved.
And honestly, from a marketing perspective, it is living on forever. Like the blog is just always there. So it's evergreen. And then you guys personally are often. tweeting it or posting it on LinkedIn. So it's living multiple places, which is just great for reach. Right. Of course. Of course. Yeah. In terms of.
gaining audience and traction and spreading the brand. It's not my field, but I can see how it's obviously beneficial too. Okay, Jorge, what is your next write-up on the blog going to be? No pressure. Right now, we are working on a couple of new products. So it's a very exciting time for the company. And we are developing some pieces of technology for these products. And I'm sure...
that next article is going to be along those lines, like rebuilding something, sharing lessons, sharing technology we've built, probably something like that. You know, Kimberly, it's like sometimes suddenly something happens and you say, oh, I want to write about this.
And you can really schedule that and you can really anticipate that. Right. So maybe it's something like that. I don't know. Maybe the next article is going to be about, I don't know, some problem we had on call, for example. So I don't know. But in terms of big themes, there are new products in the oven, so I'm sure those are going to generate some good pieces for the plot.
Well, you can find the 37 Signals dev blog at dev.37signals.com. I will link to that in the show notes. Jorge, thank you for being here. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37signals.com. You can also text that number. Or send us an email to rework at 37signals.com.