Jonas Downey is the design lead at Basecamp. In this interview we discuss the ethics of designing and building constraints into your product that change human behavior.
Jonas Downey is the design lead at Basecamp. In this interview we discuss the ethics of designing and building constraints into your product that change human behavior.
Build a custom point of sale that connects to Square Terminal, an all-in-one credit card device built by Square for contactless and card payments.
Start building with Square Terminal API by visiting https://developertea.com/square today!
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
What happens when you have the audacity to redesign, rethink something as big and as commonly used as email? In today's episode we talk with Jonas Downey. Jonas is the design lead at Basecamp. He's also the co-creator of the Hello Weather app. He's currently working on Hay and I'm very excited to talk to Jonas not only because of the kind of scale of the projects that he works on but also because Basecamp has a unique approach to almost everything that they do. In many ways the approach that Basecamp takes is probably not one that you would find in a classical kind of business book. Most of what they do they have run through a lens of philosophy and opinion and I find that incredibly inspiring and challenging. So I'm really excited to get into this interview. We've been doing a series on what it's going to be like post pandemic and we're going to pick that series up after this interview with Jonas next week. We will pick that back up and we'll continue talking about life as an engineer after the pandemic is relieving and I'm excited to pick that series back up but today let's get into this interview with Jonas Downey. How do you build a product that's good for both the business that you're running and the user? Do we always have to trade off value from one to the other? That's one of the things that I talk about with today's guest Jonas Downey. Jonas is a design lead at Basecamp and spoiler alert. No, no, you don't have to trade off and give away value to add value to the user. So it's exciting to talk with Jonas in this episode and hopefully you will get a little bit of inspiration and hopefully some conviction out of this interview. It is a two-part interview so make sure you subscribe if you want to miss out on the second part. Let's get straight into the interview with Jonas Downey. Jonas, welcome to the show. Thank you. Thanks for having me. People who are listening to this know about Basecamp and I'm sure that they have probably seen some of your work but I'd love for you and assume that somebody who's listening to this has no idea who Basecamp is, what they do, what you do. Can you give it a two-minute introduction? Sure. Basecamp is a software product company. We've been around, I think about 20 years now and over the years we've made lots of different products. Our most famous product is the one called Basecamp so our company is named after the product and it's generally known as a project management tool but it's kind of not a fair description of it. It's really a communications tool for small businesses and teams to get work done and to keep in touch with each other, keep track of everything, stay on the same page. Within that there's chat and to do and things like that. That's Basecamp and then we recently launched a brand new product called Hey which is an email service. It competes with things like Gmail or Yahoo, you can sign up for a Hey.com email address and it's a sort of reinvention of email. We took a look at email and basically blew it up and came up with a bunch of new ideas and distilled all that into this new product. I think that's the summary. Yeah. Basecamp seems to take on all of the projects that when you first start being, a lot of people listening right now they become a software engineer and they're like, oh, I'm going to build a productivity app. There's kind of this meme culture around the idea that, oh, yeah, of course, your first app is going to be a to-do app, right? But then Basecamp actually takes it the next step and I'm like, no, we're going to actually build this thing and do the whole, you know, start in these really, really hairy, difficult problems like email and productivity and project management. All of the things that are hard to tackle because there's so, first of all, so many competitors in space. Secondly, there's so much kind of religiosity around how to do these things. And I've always seen Basecamp as someone or someone. There's a big personality that Basecamp has of taking on these hard problems, having opinions about them and sometimes having, I won't say countercultural because it's really a buzzing term, but having opinions that other people are quick to criticize. So I'm curious if you have that same perception of Basecamp in kind of the super culture. Yeah, I think that's right. Definitely our products swim in heavily populated spaces. There's lots of competing products and lots of ways to get worked on. There's lots of ways to send email. Those things aren't novel, but what is novel is our approach to how we run our business and how we think of this software and how it fits into people's lives. That's really the way that I think Basecamp contrasts against most of the other companies building tools in these spaces. So we are very opinionated about running a company that's profitable and small and respectful of our employees' time. And we build the products that we use to run our company. So the products have those same principles and that ethos built into them as just the fundamental of how we approach work and communication and time. We thought a lot about those things over two decades. And so when you use any of our products, we're going to get the kind of distilled version of how we translate those opinions into tools. Yeah, it seems that I've always kind of thought this way about Basecamp. It's a philosophy company that happens to have products that they work on. That's a good way to think of it, yes. So I have one more question for you because a lot of these tools, they have a way, capital W way in mind of what seems to be a good, and we'll get into ethics a little bit later in our conversation, but what seems to be a good way to do things. Think about the products that try to do, be all things to all people and they end up failing because there's no prescribed what would you call a happy path or well-trut and pathway a way of doing things is not enough of opinion. So do you think that where do you think the average Basecamp product falls on a spectrum of trying to be so flexible that you can bring any process, any of your opinions are all welcome here versus having an very strict working pathways for example for a project management. Are there these best practices that are built in, baked in to the products all the way? Right. I think it's a nuanced answer. Basically, the way I think of it is there are some things that we are against fundamentally that we just won't do in our products. So certain things like a very common thing that people ask for years and years in Basecamp is like a Gantt chart. It's like a common way that people do project management. But we sort of have opinions about the way that projects get created and the way they get communicated about and we didn't find a Gantt chart to be the way that we wanted to approach this problem. So it's a thing like we're not going to put in. Whereas another company that's less opinionated might get customer requests for Gantt charts and say, sure, we'll add Gantt charts. That's great. So we really go into it from a holistic perspective and think about the totality of the problems we're trying to solve. And then we make decisions based on what we think is best for our customers and for us. And that may not fit everyone. We do make the tools to be generalized enough that like you can show up to Basecamp with any number of different processes and it probably will work for you. But if you do have certain specific requirements, like you have a rigid project management process and you need X, Y, and Z features to accomplish that, Basecamp might not work for that because we don't try to run the gamut of every possible thing. The idea is really we give you the right tools, just enough tools while keeping the product overall simple enough that you can invite 200 people to it and they'll pretty much know what to do. They don't have to learn the ins and outs of detailed project management become certified and learn all this stuff. So we try to kind of be in that middle space where it's friendly and simple and respectful, but not so bloated or full of specific features that we've gone over the top of it. Yeah. So it's interesting you mentioned Gantt charts because I have my reasons why I never want to see another one again in my life. I'm sure other people do too, but there may be somebody who's listening right now and I'm like, what's wrong with Gantt chart? Why did you decide that Gantt charts are against the user's best interest? And I'm curious, those kinds of decisions, I mean, you can use that when it adds the working example, but how do you arrive at that? How have you developed those kind of blacklisted items or blocklisted items that you're unwilling to, maybe not unwilling, but that won't make it into a product because you think it's not good for the user? Some of it, Gantt charts are kind of a weird example, but one issue with a Gantt chart is it sort of communicates a degree of certainty about a project schedule. So if someone fills out a Gantt chart and they have a bunch of dependencies of like time blocks that are going to happen, you know, one after another, within, let's say, like a six week block of time that you have to complete a project. You're sort of blocking out the time you think something is going to take and then you can refer to this chart as a way to say, like, where are we? None of that is necessarily bad. Like, those are okay things to do, but we don't want to promote that way of working in base camp because we don't believe that projects have that kind of certainty and we don't want to really put information in that format. It's not that we don't want to provide tooling that accomplishes some of the same goals, but we want to do it in our own way and we want to not fall back on like a pre-existing solution that people are just used to rather than thinking through that problem from scratch and saying, like, how else can we do this in a way that's better suited to what we believe in? Yeah, it's interesting. You know, when I hear you talking about this, I'm reminded of, for a very short period in my college career, I actually was pursuing a degree in journalism. I realized pretty quickly that I didn't want to do that, but this feels a lot like the ethics that a journalist might approach their work with because, you know, for example, data visualization. Data visualization is not a totally transparent picture of the data. It's always going to present a picture that is somewhat skewed. Right? There's no way to remove all of the bias out of it. And the choice of different colors can certainly communicate a lot to the viewer, but of course, we've all seen those different types of data that are presented in a two charts that look like totally different things, but actually it's the same exact data that it's representing as because you can skew them. And this reminds me quite a bit of that because this idea of saying, okay, we're not going to do that because we don't believe that presenting information in that particular way is effective because it's actually, it could harm your team. It could harm you as our customer. It might give you a false sense of security. You know, are those the kind of conversations that you're having when you're considering different feature sets or requests from the end users? Yeah, absolutely. We actively avoid using lots of common design patterns and things that we just fundamentally disagree with. Another example of that is in our new email app, we don't show counts of emails anywhere, which is like a thing that if you use email apps, you may have subliminally just absorbed and not even really realized what's going on. But if you use Gmail and you look at the boxes in Gmail, all of them tell you how many emails or any box. And the numbers tend to be ridiculous. You might have my wife has like 13,000 unread emails. And most people are used to that because that's how most email apps are designed and it's sort of taken for granted that like if you have email, you know how many unread messages you have. We took a look from the beginning and said, okay, what is it about email that we want to solve and what don't want we want to solve? And we think something like that, an unread count is actually an anti-pattern that's bad for people because it gives you a feeling of remorse and guilt and obligation to have to deal with this like pile of stuff. And in fact, the pile of stuff actually in terms of your life probably isn't that important really. So we question everything. We don't just like automatically assume that like these questions have been asked before and that the existing answers are the right answers. We go into it cold and say, well what really do we want and how do we build an app that respects our time and treats us as humans and doesn't you know try to use little even small details like that to get people to take actions that we don't think are necessary. Yeah, yeah. So it is interesting because I can understand, you know, I'm imagining if I were to go into Gmail and remove all the numbers. And that wouldn't be a sufficient change, right? Because I still need to understand my inbox to some degree, but I can imagine the immediate craving for those numbers again. This feeling of, well, I don't know where all this information is. It reminds me of this, of another thing actually from my college years. The different types of information, so sometimes you have encyclopedic information, which is what Gmail typically could be considered where you have this massive amount of information. And it's navigable, but really the whole point is that you can see the entire thing, right? There's no selection process, no filtering really. It's encyclopedic and it's your responsibility to dig through it in some way that is meaningful to you, but Gmail is kind of going to shovel that responsibility onto you. And they'll tell you that you have a million unwriting emails. You know, good luck, right? So there's this interesting feeling that not having those numbers would evoke, which is, ah, I have to be mindful about what I choose to read now. Right. And I have to, it's not just as simple interface. It's not just we don't like numbers because they stress us out. It's a totally different approach to that particular task, right? Right. Yeah. And you have to think of the problem holistically, so you could imagine you could take Gmail and delete the counts and say like, that's Gmail without counts, but it doesn't, that doesn't actually do anything really. You still, you basically have the same software. So what we like to do is think about, okay, this is a design pattern that people have used to indicate that there's like new things or there's a quantity of things. If you take that away, how do you design the rest of the system to like make up for that deficiency? Because now that is like a little bit of an information sent that like if you remember, oh, I used to have 12,000, I have 12,000 and 10, you know, you have something new, whatever. If you don't have that anymore, now what do you do instead? How do you still make it clear when there are things happening in the system? And which things do you choose to prioritize? Like how do you encourage people to look at the important information that they probably do need to see right away and shove everything else off to another place? So it's like you can't look in a vacuum at any one detail, but some details kind of give you a leg into the idea that like, you know, I'm tired of being shamed by my email app, telling me I have so many under it messages. How else could we do that? And then that opens up a whole new line of thinking. It's not just about that count then. It's about like the holistic idea of the workflow of the system. We'll get back to our discussion with Jonas right after we talk about today's sponsor, Square. With Square, you can build a custom point of sale that connects to Square Terminal. This is an all in one credit card device built by Square for contactless and card payments. Square Terminal has a five and a half inch corner to corner touch screen and a built in thermal printer for safe and distanced payments. It's easy to disinfect. It's built to make payments easy and safe. Square Terminal syncs seamlessly with your app via the Square Terminal API to accept Apple Pay, Google Pay and other NFC payment methods plus MagStripe and chip cards for smooth checkout experience. Terminal API is compatible with basically every web and mobile platform. So it's easy to integrate your iOS, Android, Flutter, React Native, or your Windows applications. And Square has your back. You can build with the Terminal API and take advantage of squares into end encryption, dispute management, and fraud detection. It's your app to the all in one payments device merchants love with the simple rest API. You can get started by heading over to developertea.com slash square. That's developertea.com slash square. Start building with square terminal API today. Thanks again to Square for sponsoring today's episode of Developer Tea. If I'm thinking about your job as a designer and my job as an engineer, it seems that the approach from the average engineer is to zoom out and say, OK, well, the designer is going to worry about the holistic approach. And I'm going to worry about the implementation approach and getting all the details in place. But there is some kind of inversion of that principle when the designer starts talking about the details, right? And when there's some collaboration, some interested in what you think about kind of the realms of responsibility between these two roles. And also, how are these two roles best going to work together as these lines blur, assuming that the lines are blurring? What do you think about that? Yeah, well, I think in general, I think designers specifically have a great deal of influence over human behavior. If you think about our daily lives and how often we are interacting with apps and websites and phones and cars and appliances, almost all of those experiences was at some point decided on by a designer and a team with engineers. So we have a very manufactured existence. And so we have a lot of people that are defining systems and constraints in those systems and making decisions about what you are able to do as a person who is working within them. And all of that adds up to influencing your daily actions and behavior, whether you realize it or not. And I think most people don't really realize it. They kind of just go along with it. So design is really powerful because people will kind of just do what is directed most of the time without questioning it. And I personally don't think that design and engineering are separate disciplines. I think that they overlap in a great deal of ways. I think that engineers are almost as much designers as designers are designers. They think like if you are working on a system and you are deciding how it operates, what the function is, what something what happens when someone does something and what the effects of that are, you are making decisions about the systems design. So at Basecamp we are much more overlapped in terms of our job responsibilities and than other companies. Our designers are all also programmers. We mostly do a lot of the front end development of the products we make. And then we work with a programmer to do more of the backend and more of the hard stuff. Our process is very collaborative. The designer and the programmer working together through the whole time throughout a project. The programmer can push back against a design idea, designable change that design. The designer can tell the programmer no, we are not going to do it this way because that is not what we believe in. The programmer will change it. So we think that it is a two way street. We don't think that design stops and then you hand a design to a developer and then development happens and then you have a product. That process is actually part of the reason you will find breakdowns in some of these issues, like breakdowns in thinking through the totality of the system, thinking through the ethics of the system, spotting ways in which it might be harmful before it ships. All those things. So we are collaborative and together the designer and the developers are better, better you can do. Now this is definitely endlessly interesting because it is the process of product development. Product development is a design exercise. It's kind of like the, oh, I don't know what the cultural reference is, but you are practicing a design exercise whether you're choosing to do it or not. If you're developing a product, you're placing something in the pathway of human behavior and despite all of the many different definitions of design. That is certainly one of the most salient ones, which is we choose to make something in the world a little bit different. We're adjusting pixels. We're adjusting people's time when we adjust these pixels in some way. We're changing the course of their behavior. So it's definitely something we're thinking about. I think one step further and something that we've already discussed in advance of this episode is that because you have this opportunity to change behaviors, it's not just an opportunity. There is some level of responsibility and you can choose to kind of view it as responsibility or not, but there is some level of responsibility that you have to other people. You're going to be an ethical designer. I want to get into that. Before we go down that path, I do want to ask you a question that I typically saved for the end of the episode, which is, what do you wish more people would ask you about? That's an interesting question. I think one thing that doesn't get talked about very often that could be, especially around this topic of ethics and respect and product design, is how caring about those issues can actually also be positive for your business. I think that one of the reasons that everyone feels very defeated about these problems is that a lot of the tech companies now are focused so much around performance that like, okay, yeah, we'd like to do things that are better for our customers or whatever, but we also have to show profit and growth and all these things. That always wins, basically. The capitalism beats ethics. What we've been trying to prove with, hey, not directly, but I think what we did kind of prove was that you can make these decisions, make ethical decisions and build a respectful product that is also a financial success and also becomes popular and so on. That's a thing that I think people still don't necessarily believe. They're like, oh, well, if I don't do, if I don't juice my conversion and all this stuff to the absolute most degree, we can't make a business out of it. I don't think that has to be the case. I think that's an aspect that people should do you into more. There is some sense of a zero. If people are listening, you have an every this term zero sum, the idea is that there are certain things in the world and the universe that are zero sum. The conservation of energy is an example of this. We can't add new energy to a system. There's only so much available. We relearn this in kind of like seventh grade physical science or something. That's not always true, but we often apply that same model to all systems. As a simple example of this, one version of this might be, well, if you're not going to give that person money, then another person is going to get the money. That's not necessarily true. Also, if you have a hundred dollars to spend, you can either spend 50 in one place and 50 in another or 100 in one place and zero in the other. Well, actually, there's a lot more you could do with that money. You could invest that money and turn it into two hundred dollars. This is where the idea of zero sum comes from because the concept is just to equalize those two amounts or to not be able to change whatever that fundamental building block is in the system. I think what you're pointing out here is exactly that. That's the false dichotomy between designing mindful systems and designing economically profitable systems. Those can be co-existent. Right. Yeah. Some of it depends on where you start. If you think about, if you compare Gmail to, hey, let's say, those two examples, they start from different angles. Gmail has a business model that's built around advertising. The business incentive for Google with Gmail is to have people using a Google product and looking at it as much as possible so that they can see ads, so that they get revenue from ads. They can do any number of things around that to make that experience more mindful and more respectful, but fundamentally, that's the case. It's like that's the root of where they started. As with, hey, our root was to build an email app that preserved your time and respected your attention and to care of you and that hopefully became a business. That was our way of thinking about it, which are just two totally different ways of coming at that problem. Right. So, in hey, we got to do a lot of things that Google would probably be disincentivized in doing because it wouldn't benefit them in the way that it might benefit us. So there is a little bit of a trick there where depending on which way you come at a problem, the amount of movement you can make in one direction or another can be constrained. But with that said though, you're right, it's not zero sum. There are a million ways to design things and we all get to make choices. So as designers and developers, we have a lot of authority. We might not think we have a lot of authority, but we do. And we can choose if we want to build something that's sticky and attention grabbing or if we want to not do that, but we don't think it's right. Even within any of those contracts or even if you work at like a company that's built on advertising money, that's fine. There are ways that you can do that that are better or worse. So you always have to kind of weigh this and try to promote the things that you believe in and come at it from a principled perspective. Yeah, that's a very interesting, it brings up an interesting question, which is, okay, is it okay for me, and I don't know that you can be the person that answers this for everybody. I think everybody has to kind of answer this for themselves. But the thought experiment is, is it okay for me to do something solely for the money? And is that an ethical pursuit or not? And I don't think that the answer is as simple as we hope it is. But it is an interesting question, is it okay to do something that is purely for financial gain? And I think the logical walkthrough of this would lead us to say, well, if you didn't make money at your job, you probably wouldn't be there, right? So there is some point at which everybody says, okay, I will not do that unless there is money involved. So how do we parse through that? I'm not sure that there is an answer, but I think it's worth talking about. How do you parse through those competing incentives? And you say, okay, well, I've got this stressor to do something that I otherwise wouldn't do where it not for the money. Right. Part of the problem is that right now the way our industry is set up, we are essentially deflecting that decision onto the employees at the end of the chain who are doing implementations. So that's why we are doing the implementation work and saying, you know, you came out of college and you needed to get a job and your family doesn't have a lot of money and you need to be self-sufficient. And you managed to land a job at Facebook. And now you're being well taken care of and you have a well-paying salary and you crawled out of a difficult place in order to be successful. And we should be able to celebrate that, but that's wonderful. At the same time though, you are now working for a company that does a lot of manipulative and harmful things. And globally to a very large audience. And so squaring that is a really difficult thing to do. And I think the answer can't be that the individuals at a company are the way to do the protesting. So if Facebook employees, 30,000 people or whatever, you can't realistically expect that those people are all going to just walk out because they have children, they're feeding and they have concerns that are beyond maybe their ethical preferences. Certainly, some of them who have the capability and can leave in protest or whatever fine, but that's not really fair, I think. So the thing we need more in the industry is one, some regulation around what's okay and what's not okay at a high level. And I think two, something more like the code of ethics that the medical profession has, which is like if you're a practicing doctor and you do something really horrific to your patients. They don't allow you to continue to be a practicing doctor, but you're out. That's not a thing that's allowed anymore. And we have almost as much influence on people as doctors, as the people who make these systems. So I think that to me is what's missing is we don't have some sort of overarching understanding of like where the boundaries are. And we're leaving it up to every individual to be able to like grapple with those decisions alone, more or less individually. And stuff. The individual people working is what you're saying. Yes, right? Yeah, the individual employees at companies, yes. Yeah, it's kind of an interesting thing because you could probably poll the individual workers about how they feel about these various things and some of them would, you'd have a full spectrum of answers. It wouldn't be, I think it's kind of like the wrong mindset of thinking, oh, as an example, soldiers in a war, not all of those soldiers equally believe the same things that they're fighting for. Right? For some of them, it's just this is, they were 18 when they joined the military as a job and now they're fighting in a war that they don't even, maybe they don't even understand why they're fighting that particular war. Right. I think that's, there's some kind of economic, mega force. You know, nobody is actually radicalizing all of Facebook's employees, right? I don't think that that's even economically important to Facebook to make everybody at Facebook believe that what they're doing is good. I think instead, it's about money. Right. It is an interesting problem and I don't know that, like you say, I'm pretty sure that the individuals can't really hold all of the responsibility here because, well, what are they going to do? Not have a job, right? Like, because I have to feed my children even if it makes the world burn down to some degree and, you know, there are, there's a lot of balancing to do. Yeah. There's the easy answer, right? The tough part of it too is that that argument can also be used as a cop out by the people who are doing that work, right? So it's a very common excuse if you talk to developers or designers, they say, well, we don't have any power. We just, you know, the people at the top of the company make decisions about what we're doing and we execute those decisions and like, that's our job. So like, what do you expect us to do, right? And that, to me, is a hollow defense because it's basically admitting your complicit and refusing to take any degree of responsibility for what you're doing. And so I think there has to be a balance there, you know, someone who is working at Facebook right now and cares deeply about a lot of these issues and is trying to do their best to make the company move in the direction they believe is right? I think like, you know, you're doing what you can and what works for you right now. But that defense that designers and programmers at heart, you know, authoritative is wrong. I think they are. There's none of this stuff can get built without us. We are a line of defense. We may not be the top line of defense, but we absolutely are critical to the operation. And if enough people speak out and stand up against things like it will stop. So I think there's a balance there. You know, I don't think it's fair to put all of the ethical concerns on the individuals who work at these companies, but there's also some amount of it that you do own. It's like a collective action problem very similar to, you know, taking care of our planet, right? We can't say, oh, well, me recycling this bottle is going to do nothing in the grand scheme of things. So I'm just going to throw it away because it's easier for me. Right. It's convenient to not have to deal with recycling and paperwork and all that. But there is a collective action problem there, right? When we all do that same thing, it's the tragedy of the commons. And we all choose to go the easy path and we all suffer from that collective inaction. Right. Well, I'm interested. So I want to stick on this for a little bit longer because it's something that we rarely talk about on this show, but it's incredibly important and relevant to our lives right now. You know, I wonder if, so there's this kind of maybe a narrative or different narratives about how we got here. I, it's hard for me to imagine that there was a person who started a company and called it Facebook and their grand plan was to start meddling in democracies at some point. You know, I don't think that that's, that that was the initial intent of this, of this venture and somewhere along the way, despite that not being the initial intent, something like that has happened, right? Or at the very least, some very serious manipulation as a result of advertising, that certainly has occurred. So how did it happen? Right. That's, you know, how did it happen? And the reason I asked the question is, as we build these new products, there will be another one, right? There will be another product that comes along that has the same level of or more, certainly as we, as our products gain more complexity and fidelity, we're going to have even more leverage over people's behaviors. So, you know, where do we insert ourselves as designers and developers and product managers and, and people managers? How do we figure out how to not cross that line? Yeah, well, I think if you, if you walk back the histories of companies like Facebook or Twitter, the problem is not that they set out to take over the world and meddling democracy, it was that they didn't set out to do that and then ended up there anyway. I think the, the naivete of how those platforms started versus where they grew and what they became is the problem. That like, you know, if you go back and look at what Twitter was like 15 years ago when it started, it was a joke. I mean, like it really was. Like, people were on there just goofing around posting, you know, stuff about their dog or whatever. It wasn't serious. Like, it was meant to be kind of just a place to play around and then obviously within the last four years it became like the bully pulpit for the US president and they've grappled with any number of ways and they had to censor him and all these things. So it turned into a platform that was not what they originally designed. The original designers who thought of Twitter did not think of that. They did not imagine 15 years in the future that it could be used in this way. And if you are a person who is building a new product or a new platform and you're thinking about doing, you know, a communication system, that's kind of the reality you're facing now. You need to think of those effects on day one. They're like, okay, hopefully this thing will grow. We don't know if it will. If it did, what would happen? Like, do we have a way to moderate content? Do we know what we'll do? Like, how will we grow this and is it okay? And have we designed it up front to protect people who were vulnerable who are going to be using this to communicate? Because if you don't think about that in the beginning, it's very hard to graft on protections after you've already built something. So that's the problem that Twitter and Facebook find themselves in. They have an existing system. It has all these rules and already has all these constraints and decision decisions in it. And you can't walk those back because that's what they have. So all they can do is sort of like bump it a little bit in one direction or another, but it's not enough. Like, it's not enough to really fix the root problems that came out of it. Thankfully now, we've learned that. And like, if someone sets out to make Facebook too or whatever, maybe they would take all that into account and build something that's healthier. But they're very difficult problems and they're new problems that we only arrived at in retrospect. Thanks so much for listening to today's episode of Developer Tea. The first part of my interview with Jonas Downey. If you enjoyed this episode, I encourage you to subscribe so you don't miss out on the second part. Thanks again to Square for sponsoring today's episode. Head over to developertea.com slash square to get started with the square terminal API today. Another reminder that we have a discord. We have a community discord that is invite based, but anybody can join. All you have to do is reach out to me on Twitter or via email on Twitter at Developer Tea and via email Developer Tea at gmail.com. Thanks so much for listening to this episode of Developer Tea. And until next time, enjoy your tea.