Move fast when you can – REWORK

Making durable products is not just about making something that doesn't break, but it's about making something that's easy to repair. And a big part of that, I think, is is making sure the code is readable and easy to deal with and and not too convoluted or complex. When we release applications like Fizzy or Campfire and people get a chance to look at the code, sometimes I think there's perhaps an appreciation that's really simple, but also maybe a hint of disappointment that there's this belief that it should have been more sophisticated when the sophistication is in its simplicity. >> Welcome to Rework, a podcast by 37 Signals about the better way to work and run your business. I'm Kimberly Rhodess from the 37 Signals team joined as always by the co-founders Jason Freed and David Hinimmeer Hansen. Well, we are often talking about the importance of moving quickly when it comes to software development. We recently released a new feature in Hey Calendar that happened so quickly even I was surprised by how quickly things happened. I thought we would talk a little bit about that. Jason, why don't you kind of talk us through this is a hey calendar feature what the feature is kind of how the inspiration started and the process and then David I'm sure we have technical things to add as well. >> Yeah. So rewinding I remember on Twitter or X someone mentioned posted this like full year catalog or a calendar sorry with the with the full year but only showing um spanned events um which is like a vacation or like a birthday or something that doesn't have a time. And I saw that I'm like that's really a clever layout. It's like very useful and helpful. And it's nice that there's not like appointments on here because you don't need to see your appointments eight months in advance, but like spann stuff is just really easy to see and you can kind of get a sense of like your weekends and what's going on, whatever >> across the whole year, like one picture. >> Yeah. And uh I I just thought it was pretty cool. And so I I'd mentioned it in Base Camp in our Hey Project um that I thought this was cool. shared the the the post on X and um I just said this we like we should do this this is cool or something like that and I kind of like left it there and the next day uh Michelle Michelle was somewhere else around the world she's always somewhere else around the world and she's one of our designers and so when I set it like I went to bed and she was up and she just did it uh in basically o overnight and put it together pretty quickly which was pretty great. She worked on the hey calendar also so she was kind of familiar with the codebase and how it was all laid out. So, she built this thing like in one night and uh that was very exciting because I felt like there's this momentum gathering online about this idea that this guy had posted. There's a lot of posts about it. Like people are like, "Oh my god, yeah, totally. We should have this or my calendar should have this or why don't we have this?" And so I felt like it was this really nice sort of call and response kind of moment where it's like someone just said something. It's like, "Okay, we have 24 hours to answer the call." Um, and this a would be a great moment. It's a new year, full year calendar, looking ahead, like perfect timing, great opportunity for Hey Calendar to get out there again and make some noise and and be visible. And so we did that in one day and we got it out there very quickly. But the thing that was interesting was that whenever you see something like this, um, you know, other people chime in, they go, "Oh, could we add this or it would be nice if we had this or if we had that it'd be even better." And there's a tendency for everything like that to just turn into a snowball. That could be, by the way, these are all good ideas in a sense, but also we would have lost the moment. The moment was like within the first 24 hours to get this thing out there and be able to respond the next day, hey, we did this. And that's what we ended up doing. So, we kind of slowed down the role on all the other things we could do with it and just got that thing out there. What was cool is that a lot of other people then began to build similar things like this took on a life of its own over the next few days. Other products came out with with calendars. other people like vibec coded a version of this and it had this like week-long sort of momentum behind it which was fun to be part of uh from the from the early or right from the start I guess >> and Michelle wrote I'll link to it in the show notes she did a write up on hey world like how this came together in 24 hours which is amazing so I'll link to that so you guys can read it >> y >> David I'm sure on the technology side there's always the idea of moving quickly and building momentum getting things out the door is is that true on the tech side of things >> I'd actually say the opposite is true. Almost everyone almost everywhere have a million reasons for why you cannot launch a feature like that in a day. There are, as Jason says, there's additional features you want to add on to something. There's QA processes. There's product management. There's getting things signed off. There's showing it to perhaps someone on another team. There's just always a million reasons for why you can't do something in a day. But those reasons are all just made up and you can choose at any moment to just ignore them and just ship stuff. Now, if you keep doing that on literally every feature, including major stuff, especially if the wipe coding is involved, there's a high chance you're going to snowball into a ball of mud with your codebase, and then it's going to be really hard to maintain and so forth. But even that is a copout most of the time because there is usually always a judo way of doing something. A judo way for us is using this energy that we have, this enthusiasm we have for a new feature and then throwing it around and making it fit within the constraints that we have, making it fit within the existing structure of the codebase. Make it fit within the existing structure of the design. Michelle was able to do this because she was building upon a calendar feature that was already there. If we had had the impulse to, hey, should we add a calendar and do it in one day, that's probably a step too far. We spent, I don't know, two months, at least a whole cycle on that calendar in the first place. But there's just so many opportunities like this where what people want is not like an enormous new thing. They want just they want this. They want this slice. they want this twist on it and very often you can take components you already have and bend them in slightly new ways and deliver that which is really exciting and it's even exciting for us I mean I think in the early days far more of our features would happen in this way because we had less mass we had a far smaller team we had a much smaller code base we had much simpler products we had far fewer customers and that makes all of that easy like the natural momentum as you get more successful, as you get larger, as your code base survives longer is for all that to bog down. And I think that's why even inside of 37 signals, we move pretty fast on a lot of things. But not often that fast, not often Jason drops an invitation to do this and overnight there's something new. But whenever that happens is always a magic moment and it reflects incredibly well on Michelle and on anyone else who've taken this up. I've seen this inside of 37 signals before, especially with new employees. Nothing creates just that enthusiasm by as making things happen. Like Jason didn't say like, "Hey, we need to have this and the deadline is tomorrow and just go go just summon everyone. You drop everything. Just go." It's this planting of a seed and then seeing it super sprout in a night or in some days even just a couple of days that just invigorates everyone. Reminds everyone that software is so malible. We can change almost everything. Not everything but almost everything quite quickly. And you know what? We should remember that. Why don't we work like this more of the time? Why are we not willing to make those tradeoffs more of the time? which is when I say trade-offs mostly about cutting scope mostly as Jason says about like yeah yeah yeah we could do all that but here's the kernel of the idea here's the epicenter of what we're trying to do can we get that out first and even see if it resonates at all this really did resonate right which by the way I find interesting because I think the reason this really caught the attention of this corner of X was it was a bit of a throwback to how UI used to way more information dense, being able to see tons of data in an entire year on a single screen. So much of the critique of modern design is that it's the opposite, right? That information density is just going way down. You have to constantly scroll. There's no way of getting that big overview and that um sort of just mass of information in a single glance. And this was that. So, I also just liked it from that perspective that this was this throwback feature done in this throwback super quick way and then you're part of a conversation which is always good marketing and half of that participation Jason says is about the moment. If you'd shipped this a week or two later, do you know what? No one would have cared. >> Yeah. It also was like we were other people responded but we were sort of first to respond which like allowed these are all little subtle things by the way. none of this like really matters, you know, but but it's nice to not be like the sixth calendar tool to roll this out in 4 days. Like it's nice to be the first to go, you know what, that's actually a good idea. And we gave the guy credit like I quoted his original expost and be like, "Great idea. We just did it, too." You know, that kind of thing. And then he responded back later. He's like, "And I did it also." And like he did I think someone else did a print version. And like it was just super fun to keep improving on each other's work actually. And even this um the initial version we shipped wasn't quite where we wanted it. Actually, the weekends were kind of scattered. It was kind of a bit of a mess. And then that day later, Michelle cleaned it up one more time. So, it was it was fine to ship it even as a bit of a mess because we got to make some noise, talk it up. People weren't paying attention to the messiness. It wasn't the point. The point was that it existed. And then within eight hours, we made it like 2x better. And then we were done with it. by the way, like we moved on because it's also very easy to get stuck, you know, in this honey trap where it's like gooey and you're stuck to it. And we spent the next 3 weeks perfecting this thing that really is a it's a sideshow feature in many ways. You don't often need this, but when you do need it, it's great, but we don't need to spend weeks on it. A day is plenty. Got it out there, made some noise. It was fun to trade barbs with people to get other people to do this. We actually even for a moment started working on a print version of this. I don't know if David even knows about this. we're going to do like a big huge print version which we're going to sell in our store and then we just kind of lost momentum because other things came up and I'm kind of glad we did because it we didn't need to go there and we just moved on. But uh it was it was a fun 24 hours for sure. And it actually did inspire me. I was just talking about this with the base camp 5 team this morning. Work we have a call on on Tuesday mornings about some features that we're working on. And there was one thing that someone did sort of on a whim to clean what's one screen up and it was just so much it took like an hour and it was just like so much better. And it reminded me of those days that David was talking about where we just like shipped something much better very quickly and it wasn't like a huge change but it was a change enough to make a big impact. And I it's easy just to get stuck in like only big releases and big stuff like big thoughtout conceptualized things that take days or weeks versus like something that takes an hour that makes like something considerably better. And so I'm just kind of pushing the team to get back into that realm of like there's a lot of quick wins here. Like what are the quick quick quick high power like low loweffort high value wins? Um not just quick wins actually because quick wins like you can make some changes that don't matter. But there are things you have certain leverage over where you can really make a major change with a small amount of work that makes a big difference quickly. I want to get more of that rolling. And in fact, like don't quote me on this, but I I would love to get to a place where we could make a promise that Base Camp gets better every single day. >> Um, at least one way. Um, and it kind of usually does anyway with bug fixes and stuff, but I would love to be able to release something every single day that someone's like going to see that and go, "Yeah, that's better. Yeah, that's better. Yeah, that's better." Um, and so like kind of these this collection of one-hour fixes, one hour improvements would be a nice thing to do. So anyway, that's just something that's on my mind. You just gave every designer and programmer a little anxiety right now. >> Oh, you know what though? Yeah, maybe. But so what? Like it's good. It's good anxiety. Like let's let's I mean also like uh there's this guy online. His name is um Saurin Iverson I believe is his name if I'm pronouncing it right. Um he he um he's great. He he's on X. I think he might be on LinkedIn, might be other places, too. Those are the only two places I pay attention to. every day he posts an interface idea for someone else's product that's usually quite funny. He like it's just really funny interface ideas and obviously he doesn't have to make these work. Okay, these are just like full mock-ups but really high quality but full and funny kind of mock-ups. Um and that's actually what inspired me in some part like yeah he doesn't have to make these things work but it's our product. We can make these things work and they don't have to be massive changes. They can be subtle small things that matter and there's definitely 365 of those like in the product. So like let's just pick one off a day. Um anyway, so yeah, maybe it gives people anxiety, but I think it'd actually be really fun, a fun challenge. Like these 1 hour one-hour improvements basically is what I would call them. >> I think the reason this can work too is that the anxiety often comes when you set a deadline and then set a fixed scope. This is something we talk a lot about. This is what shape up is based all about. But if you just go, do you know what? Let's make something cool, awesome, better in a day. The constraint, the main constraint is the day. There's a real liberation in that. There's a real liberation in just going like I have this fixed amount of time to improve something and let's see what I can come up with. The human mind is incredibly efficient at pairing something down. When you put those kind of constraints on it, I think the anxiety really comes from here's a fixed body of work that I don't quite know how I'm going to solve, how long it's going to take, but I'm just impose this deadline upon me. That's the death march culture that uh often occurs in the gaming industry where you you just have these month-long crunches. like we don't do any of that but you can still embrace that acceleration of doing something quickly. This is something actually back in especially the early Rails days there was this thing called what was it called? Rails uh camp or something 24 hours a sprint 24 hours come up with an entire app and put it out there make something real. It's incredible what people can make in 24 hours. Again, part of the magic of moving quickly is sometimes when you just start from a clean sheet of paper and when you're working with a codebase like Base Camp in this case that is literally at this point, what is that going to be 14 years old since the first commit, it's not quite as easy, but I also think it is one of the rewards of keeping a clean workspace. 14-year-old code bases have a tendency sometimes to get a little creaky because they haven't been kept in a nice state. There's just endless amount of deferred maintenance. People have been pushing just new features and never going back to revisit some of the core fundamentals. And when I look at the base camp code base the 14 years, I'm actually quite happy with how little creaking there is. There's some give, there's some take, there's some scars that this is a codebase that's lived the real life with real customers and gone down some technological blind alleys that we then reverted from and there's still some traces there. But overall, the reward for keeping your workspace clean, keeping your codebase in good condition is that you can do this kind of stuff. And the most anxiety producing predicament that I see for programmers over and over again is this willingness to want to do that, to want to move fast, to want to be part of the conversation that's happening on X, to put in a feature and ship it right away and feeling like I just can't. There's just the ball of mud has grown too big. If I touch this part over there, I really need a bunch of eyes on it because otherwise maybe I'm going to break 15 other things. So in many ways this is a bit of a reward for doing a good job over a long period of time when you can do this with an existing codebase. We actually talked about this I think it was in getting real this idea of lowering the cost of change I think is what we called it in BC5 as we're working on it now. There's some some CSS that's just like I'm like this is more complicated than it needs to be and I'm kind of afraid to touch this because I don't know what else I'm going to tweak when I tweak this. And there's some of that and we're going to actually go through and and clean a lot of this stuff up. But but it's funny. It doesn't take much to make you go, h maybe not. Maybe I shouldn't do this. It It's barely anything, but it can be like this is going to be like a major problem if I screw something up, so I'm just like not going to touch it. And that's how you sometimes leave things around that aren't quite right. So yeah, I'm totally on board with David's um point about code hygiene and and uh clean workspaces and stuff. It makes a lot of it makes a big difference. just makes things easier to tweak and change and and allows other people to do things who maybe not be might not be as skilled a as everyone else but like it's like long long as you can make sense of it you can figure it out versus like something that's very convoluted and very difficult to figure out you just kind of stay away from it >> and I think this is the part that sometimes is lost on folks when you talk about something that seems almost like a inaccessible luxury like code quality like code size there was just a post uh was it yesterday where someone was looking at our code bases, especially the ones we've released in public, and go, "How can they make them so nice? How can they make them so polished? Why does all the code look so pretty?" And then they were coming up with all these coping realizations. Well, it's because they don't make a lot of features. It's no part of yeah, sort of, but not really. Like the whole thing works together. you commit early on to the idea that you're going to produce quality software that's easy to change and you might take a little longer in the beginning. I don't even think that's true, but even if it was, that investment is just going to pay off tenfold. Both in terms of actual defects, customers finding bugs, also in terms of being able to explain your product if it isn't vastly bloated. But in this example, giving you the agility to be able to do something like this in a single day that happens when a single developer, in this case a designer, Michelle, is able on mostly her own to go in there and get something done and have some confidence that it's not just going to explode everything, right? So it all works together. And this is where when folks from the outside sometimes look at our engineering culture, they think like, do you know what? this is some there's some exotic stuff going on here. They're doing things that no one else can for and then usually there's a bunch of [ __ ] reasons. No, it's really not that. We don't have that many people. Um we don't have that much capital compared to most of the enormous shops out there. And yet we're able to produce something of high quality quickly that can be iterated upon. Those things are more tied to a sense of it's been overused, but this word of craftsmanship that the time you spend on the internals of the machine as uh I think Steve Jobs talking about the inside of the layout of the print boards that that even need to have aesthetic qualities. It seems so silly. It seems so frivolous to someone who's like, "Well, how is this going to convert into business? How can this code quality turn into conversions?" Well, this is how this is this is how being able to be part of a conversation, having people who are uh inspired and empowered enough to be able to make changes right away, all that will convert. No, not the I'm fiddling with the line noise of every single little thing like that in itself doesn't, but all these derivative benefits from it absolutely do. And I find it fascinating that that is still a difficult argument to make. Like we didn't come up with this notion that software is better when it's easy to change. That was the core premise of agile development. That was how you defined good software. That that was software that could change because you realize software always changes and therefore that's a property to optimize for. Yet it is so rare. And I find that this is just one of those fascinating things where it can be easy to say like, "Oh, code quality is important for agility and customer sat or not customer satisfaction, employee satisfaction who are then inspired to do something like this." But actually putting that to use much more difficult. You can sum up so much of the wisdom of software development and software methodologies in just a few lines, but living them much more difficult. I would also think with, you know, we're building base camp 5 right now, this idea, uh, Jason, of making daily fixes is easier when you're starting something new because we're not putting every idea into it. Like, I'm sure there's a place where there's ideas that are being logged somewhere that could be a quick fix, but it's not essential for launching the new product. >> Well, the good news about having an a product that's as big as Base Camp is that there's a lot we can make better. There's just like so many places where like we can by the way these features these 1 hour features these daily improvements. It can be just as much as like like Dave was talking about like increasing the data density on a particular widget on a little thing. Like now there's more information on this card or now the the proportions are better so this is clearer or we added a time to this not just a date. Like they don't have to be like you know life-changing things. They can just be little subtle things that add up over time and make the whole system better. But to see that kind of momentum on a daily basis calling out one like hey this before after like I like to do these little before afters basically and every day. Anyway, this is what I' I'd like to We haven't committed to this, but but let me just jump back for a second because one thing that that that occurred to me, I'm reading this this new book by Stuart Brand called Maintenance, which is a really awesome book about like maintaining all sorts of things from sailboats to to to guns to to um motorcycles to brick wall or stone walls. It's a fascinating look at like the art of maintenance. And one of the things he talks about is that um like durability is an important term which we haven't really used yet, but that like is something if something's durable it means it can last a long time, but it also typically means it can be it can be repaired fairly easily. So things that were hard to repair tend not to get repaired and those things tend to wear out and then you get afraid. We used to call this like code smells I think, right? We're like I don't want to get close to that. Um so so part of this is like building durable software makes means like the the cost of change is is low. Uh you're not afraid to get in there to make the changes and to make things better. There is a place where like I'm not going to touch that anymore. It's too complicated. I think like High-Rise is a good product, a unfortunate story here actually where it just became this big ball of mud and it's kind of a total mess and other teams have gotten involved with it that weren't our core team and we're like we just are afraid to to touch it frankly. Uh, not that you're really interested in touching it again, but even going back in there, you're like, I don't really Yeah, I'd rather not. Um, so it almost it will decay because it we're afraid of maintaining it because it's hard to improve. It's hard to fix. It's hard to understand. It's hard to reason about. The parts aren't interchangeable in a sense. Everything's like bespoke and custom and it's very difficult to deal with things like that. So this idea of maintenance and software just it's ringing true comparing it to physical objects like he's just talking about the Model T how it was just very easy to repair these things because um all the parts were interchangeable versus like bespoke parts that were other cars were in in the early days were all super custom and so people couldn't even work on them because they didn't know if they changed what this what would happen to that and that sort of thing and so those kind of didn't make it while the T for a variety of other reasons uh made it and allowed people to work on their own car and it got people excited about that whole thing. So anyway, um long story short is uh making durable products is not just about making something that doesn't break, but it's about making something that's easy to repair. And a big part of that, I think, is is making sure the code is readable and easy to deal with and and not too convoluted or complex. Now, what I love about that metaphor is how well it applies to the open source work that we do at 37 signals because it's exactly that when we release applications like Vizy or Campfire and people get a chance to look at the code sometimes I think there's perhaps an appreciation that's really simple but also maybe a hint of disappointment that there's this belief that it should have been more sophisticated when the sophistic education is in its simplicity, is in the fact that so many of the parts that we need to build something like Fizzy or Campfire have come from genericizing everything that we built over the last 20 years that we've taken all these things that started out life as very bespoke oneoff inventions, creations to create either a high-rise or a backpack or a campfire or whatever and then putting it into rails. That process transforms the bespoke part to the generic part which then means when someone encounters a codebase 20 years later like the fizzy codebase it all seems so incredibly familiar because it's using all these generic components that we've built up over 20 years which is what gives it a huge part of its ease of maintainability. This is something I've seen time and again when I contrast the Ruby and Rails ecosystem with other ecosystems and especially when it comes to dependencies. A lot of folks working in JavaScript for example use something called npm which is the node package what >> manager >> modular I don't even actually know what the M stands for a package repository and they just use a gazillion bajillion dependencies all these little nuts and bolts that are too small in my opinion to be distributed as one-offs right they should fit into a larger perspective and I think when you start working like that it doesn't seem like a big problem. Oh, so what if I have 2100 dependencies here? And then when you work on something for a few more years, you realize that's not durable. that's not easily maintainable because all of these little bits the folks who work on them come and go and sometimes the incompatibilities just stack up versus in the Ruby and Rails world we really focused on having an proportionate mass to when something becomes a new package and having more of those packages under a single umbrella and therefore building up a body of knowledge and tools that feel truly generic where an investment both in their use and your learning about that use, your knowledge of how to use it best can accumulate over time. Now, you don't always get that luxury because some things move very quickly. I think AI right now is a great example of that. Jason and I were just talking this um morning, actually overnight, about the MCP standard. This is something that we played with in a bunch of different contexts. I even got halfway started on a framework for it for Rails and it only premiered I think in spring of last year. So it's not even a year old and already there's a sense that you know what this perhaps probably isn't the future direction of how agents should be using tools. Now there's something called skills and they work very well with CLIs even though there's still some MCP usage too. There's some domains that just move really quickly. The web mostly is not one of those. whatever investments you made in I don't know how to handle cookies back in 2002, they're still there. Cookies are still largely the same. There's some security layering that's happened on top, but the fundamentals of how to interact with that core technology of the web is still as it is. So any investment you made 20 years ago, you got to withdraw dividends on the entire distance. And this is when I'm often reminded of my favorite Basos piece of advice that Jason and I got. I mean, he's given it to anyone. Um, but he also gave it to us in person, which was invest in things that don't change. Again, you don't always have that luxury. Sometimes you have to be on the new things and you don't know whether new things are going to last. But when you look at the overall picture of where your time should be spent, more of the time should be spent on the things that don't change. more of your investment should go into that both personally and as you're developing a business and as you're making technology which is a little bit like books right like there's this great saying of uh it's better to read old books than new books because the reason old books are still around is because they're really good if something has survived a hundred years do you know what there's some real wisdom in it if it survived 2,000 years I mean hall of flame classic versus you look at any given year 80 90 95% of all releases in that year will be either just not that good or obsolete shortly thereafter. So I think maybe also this is something about getting old. Matista and I are projecting a little bit of this kind of like do you know what when you hit 40 there's certainly this magic appeal to trees right like you could have told 22 year old self like oh here's a nice tree and it be like it's a [ __ ] tree and I know this because I have three kids and I often tell them wow look at this tree and sometimes they'll play me like yeah that's a nice tree but I can tell right like they're not yet at the stage where they generally appreciate sort of the longevity of a beautiful tree. But then you get past 40 and you suddenly start caring about trees. You start caring about the durability of a stone wall. You start appreciating that the pantheon still stands. Um so this is why it's good to have a little bit of both, right? That if you veer too much in that direction of the durability and the longlasting and whatever, you can get kind of old and crudy and just about the past. And the magic of software is that you're also forced into the new stuff. At least if you want to still be relevant, if you want to still be taking advantage of everything that we're making. And this is what I'm really finding with AI. We talked about this on another episode. It's infusing all of this newness into all these crevices. And we have to wrestle with not throwing out everything we've learned over 50 years of a software uh development understanding. And then also taking care of all the new stuff. And some of that helps simply by age, right? Like Jason and I both over 40, closer to the 50. Um, actually, you're 50, aren't you? >> 51. >> You [ __ ] old man. Um, don't trust anyone over 50. I have at least three and a half more years to go. So more years, but this sense that like even in hiring too, we should have something for both ends, right? Um, so I'm always really happy when we end up with that nice mix that we have people who appreciate trees and then people don't give a [ __ ] >> Okay, well with that we're gonna wrap it up. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37s signals.com/mpodcast. Full video episodes are on YouTube. And if you have a question for Jason or David about a better way to work and run your business or their favorite trees, send us a video question. You can do that at 37s signals.commpodcast or email us at rework@37s signals.com.

Sometimes speed matters more than polish. In this episode, the team shares how a HEY Calendar feature went from idea to shipped in about a day — and what made that possible. It’s a look at when moving quickly helps, when it doesn't, and how writing clean code gives you room to change your mind later without breaking everything. *Key Takeaways* 00:00 – Episode highlights 00:46 – Shipping a new feature in roughly a day 04:06 – Catching the moment while it's hot 09:09 – Shortening the path from idea to implementation 13:41 – Making change easier with clean, thoughtful code 21:51 – Designing things that hold up and are easy to fix 25:18 – Building for the future *Links and Resources* "Building HEY Calendar's Year View" from Michelle Harjani's HEY World – https://world.hey.com/michelleharjani/building-hey-calendar-s-year-view-2e08d77d Maintenance of Everything (Part One) by Stewart Brand – https://amzn.to/4qNCLbZ Fizzy is a modern spin on kanban. Try it for free at https://www.fizzy.do Record or upload a video question for Jason and David — https://www.37signals.com/podcastquestion Get a free Basecamp account at https://www.basecamp.com Books by 37signals – https://37signals.com/books 30-day free trial of HEY – https://www.hey.com/ Once. com – https://once.com/ Campfire – https://once.com/campfire HEY – https://www.hey.com/ The REWORK podcast – https://37signals.com/podcast/ Get some REWORK podcast merch – https://37signals.com/podcast/shop *Let's be social!* Twitter/X: https://x.com/37signals Instagram: https://www.instagram.com/37signalshq/ Rework is a production of 37signals. You can find show notes and transcripts on our website https://www.37signals.com/ Leave us a video question at www.37signals.com/podcastquestion or send an email to rework@37signals.com, and we might answer it on a future episode.