« All Episodes

Interview w/ Ben Orenstein (pt. 2)

Published 1/2/2019

You might remember today's guest back in episode 19 & 20. Today, we talk about new projects with the guest of the show, Ben Orenstein. During part 2 of this two-part episode, we dig into financial opportunities and I challenge you, while you're listening to this episode is to consider the lessons you've learned in 2018 and continue to grow in 2019.

If you'd like to connect with Ben, you can find him on Twitter, @r00k: https://twitter.com/r00k and view his work on GitHub, @r00k: https://github.com/r00k

Thanks to today's sponsor: Sentry

Sentry tells you about errors in your code before your customers have a chance to encounter them.

Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.

Give it a try for yourself at Sentry.io

Get in touch

If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea

🧡 Leave a Review

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.

Transcript (Generated by OpenAI Whisper)
You want a financial advisor that you pay every time you see them a certain amount and then they don't make a cut up based on what they recommend to you. Yeah, I treated more like a therapist than somebody who has invested interest basically in where you put your money. That would be, yeah, so don't go to somebody for free. It's actually not that advice. In today's episode, we're going to continue talking with Ben Orenstein. Ben has been giving us great information from his experiences as a developer. Specifically, we left off talking about finance, personal finance. We're going to continue the discussion. We're going to talk about some of Ben's personal experiences in today's episode. I encourage you, if you missed the last episode, which released on New Year's Eve, then I encourage you to go back and listen to that. Also, I just want to give a little plug here for Developer Teaor daily Developer Tea, T-break challenges. Right now, we're posting them on Twitter and we're posting them on Spectrum. Go to Spectrum.chat to find out more about how to sign up for that. You can also find out more on the Developer TeaTwitter that's just at Developer Tea. These are going to be very short challenges. They're tweet length challenges that will help you grow as a developer on a daily basis. Every single day, you can get these messages. Go and check it out at Developer Teaon Twitter. Let's get into the second part of the interview with Ben Orenstein. All right. While we've covered that, I think that's really important, though. It's actually something we don't talk about a lot on the show, but I think it's really important. I think it's a topic that a lot of developers first of all, they shy away from because money is such a weird thing for developers. It's a weird thing for everybody, especially culturally in the United States. Conversations about money are difficult for a variety of reasons, but it's also weird for developers because our pay can fluctuate by even 100%. I can easily see that. More than 100% over a short course of a career, five years or so, you can imagine developers pay doubling. Knowing what to do with that, I think is really important. Developers are in a unique position in that regard. I have one more financial thing I have to mention before we leave the topic. Please do. Please do. Counter-offer. When someone offers you a salary, ask for more. There's good blog post on this on the internet. Patrick McKenzie has a great one, but the TLDR is whatever they say, ask for more, no matter how high that number is. Also, every single number on an offer letter is negotiable, including the number of days of vacation, everything on there. What about the offer letters that have unlimited vacation? There are a few things you don't have to. That just makes it more of an ad hoc negotiation. Is it really unlimited? Because it's not. It's the thing. Just keep your distance. You have to really... We won't dive too deeply into that. I think it's important that... Especially, let's say you're a company. If you're a developer who is also a manager or a hiring manager that's listening to the show, when you make that statement that you have unlimited paid time off, make sure you clarify what that means and why. Why is your company doing that? Because there are some companies that do this as an attraction point. There are other companies that actually recognize this as an important part of the health of their employees. A lot of those companies have started to try to make more concrete terms for those paid time off days. That developers can understand it more thoroughly. There's no unclear expectations. Nobody's waiting for you to come back from those paid time off days. That is the culture that you want to seek after. That's a high horse from me right now. I've seen companies do this in both ways. It can be really damaging if you do it wrong. Totally. I want you to talk a little bit about your new company. I know we're shifting gears entirely here. I want you to talk about what your new company does. Then I'm going to rewind again and ask you a few questions about your journey along the way. But first tell me about what your new company does. Sure. My new company is called Tupel. We make a tool for remote pair programming. We looked at the state of the remote pair programming world after screen hero got shut down by Slack. My take on it was that nothing out there was really that good. You can do it with some of the solutions out there. They all kind of sucked for various reasons. After looking at the market, we said, hey, I think this is a pretty good opportunity. We decided to try to make the tool that we wish existed. We started in May of this year and we're getting ready to launch our first version to our alpha customers in January 7th. Wow. This is a problem. I am a remote developer myself at Clearbit. We're using a variety of things to try to solve it. This is a really big pain point. The closest thing that I've found that does a decent job at this right now is teammate. But even that has its downfalls. I'd love to know what kind of problems are you seeing that you're solving in new ways? What's exciting about this to you? The exciting thing to me is that it's a thing that's sort of simple to describe, but there's so much to ring out of it to make it really good. I love products that are focused on what they do. I love when a sharp tool that has a single use. This is that. Only there's so much optimization that can be done behind the scenes that I'm excited about working on this for the long term. I'll give you some examples. One is just dual mouse cursor. It would be nice if two people could use the mouse at the same time. Well, the operating system, so we're Mac only right now. I don't know how Windows actually is, but at least on Mac, the Mac operating system is firmly entrenched in the idea that there is one mouse cursor, and you cannot tell it differently. If you want to do two mice, it's always a hack. It's like, how much of a non-hack can we make this so it feels good? The very naive version is horrible, and the semi-ni-version is pretty horrible. After months and months of working on it, it's bad. Right now, we are dropping down to the level of intercepting a mouse, like USB mouse events, before it hits the kernel. Wow. Stealing the code that implements the mouse acceleration curves for OSX so that our fake mouse cursor feels real. It's one of these problems where it sounds easier or something or at least straightforward, and then the actual implementation is just crazy deep. Wow. I never would have thought that you'd have to go all the way down to that level, but I guess it makes sense if you're doing an OS level thing, then you can expect maybe you're going to have to dive into the OS. Totally. This is the reason why a great answer to this doesn't exist. Screen here, I would say, was a great answer and it is not anymore, but so few people have done this, it seems like. Not because they're not smarter, but because it's such a pain. You have to really care about pair programming and think this is going to be worth it from a business sense to spend the time writing C++ and stealing mouse events and doing all this nonsense that we're doing. Yeah. This means that you're writing C++ now. That's really the big takeaway. That's the third version of this app, by the way. Version 1 was like, maybe we can just write this in electron and it would be great. We already know JavaScript and we can get to market so fast and it sucked. Everything sucked. You can get a crappy version together. Really fast. I see me learned quite a lot through that process. I wouldn't say it was a waste of time. It was probably worth building that prototype, but our conclusion of that prototype was like, oh yeah, this is definitely too high level. It's not going to work for us. Version 2, we wrote in Swift. We're like, okay, we're going to drop down. This is going to be serious. We're getting hardcore now. We're going to write this in Swift. But we still actually are pretty far from the metal in that point. In particular, one of our big dependencies is WebRTC. WebRTC is written in C++. If you're constantly bridging between C++ and Swift, it's possible, but it's painful. You can't do everything you want to do. We don't have the full control because we're still removed from the level of abstraction that we want to be. If the current version and what we're going to ship to our customers in about a month is a C++ app. Does that surprise you? Did it surprise you that you would end up doing that or did you have a feeling along the way that you may end up there eventually anyway? I did. Yeah. I had that sense. So like, first of all, one of the co-founders of ScreenHeroes was nice enough to talk to us before we even launched. So before we went down this path, we did a call with him and said, hey, do you think this is still a good idea? He said, yes. We're like, great. Would you write this in a different language? He was like, no, you probably still want to write it in C++. We're like, no, that's wrong. We're not going to do that. So we spent many, many months not writing C++. Then here we are. Then you're going to send him a letter of apology and thank you. I'm sure. Yeah. Exactly. You were right. That's great. But like I said, this problem I think is cool because there's just so much to ring out of it. So I like when products don't get more feature-full, but instead just get better at the things they currently do. Yeah. This is a perfect implementation of that, I think. So there's sort of four components, where it's keyboard, mouse, video, and audio, to this. Then maybe we have, maybe a fifth where we have some interesting paraprogramming specific features coming. But it's mostly just four things. So the app will probably only ever do four to five things distinctly. But if every couple months, each of those things gets 10% better or 30% faster or something, then the app will just keep improving and it will just become sharper and sharper. I'm excited about building a product that's like that, where we don't just need to keep adding stuff to it, but instead it can just make the existing stuff better. Yeah. What's very interesting about this to me is it seems like a problem that would have been solved a long time ago. It seems like one of those elemental core functionality problems that want to have networking ability. Well, of course, the next step would be to merge the UX of two machines into one process or something. And as it turns out, I mean, other people have had this idea. I can't remember what the guy's name was, but there was a multi-curse or demo that was done one time. And of course, the project was abandoned. I think this is like way back in the 1980s, 1990s. But I think your point is really important. And it actually is a good lesson for Developer That just because the idea exists and just because the idea has been, you know, is valuable to a handful of people, doesn't mean that the idea will come to fruition either by some natural process, like somebody actually has to do work. And secondly, that the market is ready for that particular product. And it may be that the market is ready now, right? But it may have been in the 1980s that this was just kind of an edge case. It doesn't really make sense to spend a bunch of resources on this. Totally. Yeah, like a big reason we went with this idea versus some of the other ones that we were considering is that the macro trends, I think are very much in the favor of this. Like there are more developer, remote developers, there are more remote Developer This year than last year. And I expect that to continue for a long time. Yeah, I agree with that absolutely. So it makes complete sense that as developers are collaborating and, you know, even if so let's the perfect person for this would be somebody who is a hundred percent on board with extreme programming and, you know, that they are doing that every day. But there are other people who they just want help, right? There's a bug they can't figure out. And normally in a physical office environment, they may have somebody come look over their shoulder, but they don't have that. So this is kind of the for those people of proverbial looking over your shoulder, you know, option, there's a lot of reasons why, you know, it's not just a niche group of people. This can also be a teaching tool, right? If you're a mentor and or like a senior developer and a junior developer and you're just saying, Hey, I want to show you how to do this thing so that when you encounter it in projects and the company that you're working in, you have the context that you need, there's plenty of reasons for this to exist. Totally. And a couple of the people in our alpha actually are teachers and want to use it for that purpose. And we're I'm in talks right now. Well, that's a fancy way. I'm having chats with people that run boot camps. And they are also interested, possibly in having their instructors use it with their students because there are more and more remote boot camps too. But the funny thing is, and this may surprise you is like, I'm actually kind of resistant to like thinking about these use cases. So I think a big, so our marketing message has been really resonating. Like we're sounding a lot of people up to our million list. People seem pretty excited about it. And I think a lot of that is because we're so focused. And like we're saying like, tuple is a remote pair programming tool. And we're going to optimize it for that and make features for that. And it's not for your IT help desk. It's not for doing demos. It's it's not Google Hangouts. It's not Skype. It's a different thing. It's for a different group of people. And I think that's that's going to be really core to our strategy. Is that positioning and that marketing and making it really good for that group? And then eventually, yeah, if it turns out to be great for other things, maybe we pursue that if we want that kind of growth. But I'm pretty content keeping it very tightly scoped. Yeah, I think it makes sense. I think, you know, for developers, so you know, I mentioned teammate. I actually am a them user. And part of the reason for that is actually the videos that you did on upcase. I watched all of them. I learned them from you. You're the reason that I am a them developer. Basically, that's awesome. So thank you for that. But first of all, but secondly, you know, teammate is a really highly focused thing for teamux users. Like if you don't use teamux, then teammates not really going to make a lot of sense to you. You know, you could use it. You could use it for a single, you know, terminal shell or whatever. That's not really going to be super useful either. Right. So like, there's there's a small group of people and granted, this is not something that I pay for. So we can't really talk about it in the same scope as what Tupel will be. But but the concept of having, it was kind of the Unix philosophy. This this single tools that that compose well together and, you know, maybe down the road, you'll find another way to compose this tool to to do the teaching stuff that you're talking about, you know, people potentially wanting. But when it comes down to it, this is about one person and another person looking at one piece of code together. And both people having full control of that machine. That's so interesting. And there's not something that does this very well right now. So I'm really excited about it. And just a reminder clarification for people who are listening to the show that we don't do any of these things are as sponsored messages and Tupel's not sponsoring Developer Teaor anything like that. So we are genuinely just excited about the about new cool tools and certainly about bins involvement in Tupel and the stuff that's going to come out of that. So I do want to take a moment and, you know, oh, and by the way, you said it's releasing. When is the release date? So we have a group of customers who have prepaid to get access to our alpha, which is January 7th. There's our target for that. I expect the alpha to run for some number of months, probably figure like let's say two or three, two to four, two to ten, who knows development. But hopefully some small ish single digit ish number of months. And then we will start doing a beta. So I'm actually kind of lightly recruiting teams for that beta now. It's also paid like we're asking like we're intentionally making it kind of hard to get in because I want the true believers to help shape the product on the early days. But so we're coming up on it. It's just a few weeks now. That's awesome. Very exciting. Can't wait to hear about the feedback on that and see where the product goes from there too. Yeah, me too. A huge thank you and a welcome to the list of sponsors that we love so very much. Today's episode is sponsored by Century. Your code is broken. So with Century, you can fix it together. We're lying on customers to report errors and essentially treating them as an offsite QA team is not a good plan. It's rude to customers is bad for business. And ideally you could solve this problem with tests, right? Why not just cover every single scenario with a test? Then life will be perfect and fine and great. But here in reality humans are pretty bad at writing perfect tests. Not just because we're all kind of lazy and maybe a little bit dumb, but also because we can't anticipate every single way that users are going to interact with our product. We're not going to cover every single use case. They might do something really, really strange or out of the blue that we don't even think about. That's why Century tells you about errors in your code before your customers have a chance to encounter them. Not only does Century tell you about the errors that your customers are encountering, but they also give you details that you'll need to be able to fix them. You'll see exactly how many users have been impacted by a bug. The stack trace, the commit that the error was released as a part of. And even the engineer who wrote the line of code that is currently busted. And plenty more. Go and check it out. Head over to century.io to get started today. That's century.io. And just as a disclaimer, we actually do use Century at ClearPet. And we've used it since well before Century came to develop a T as a sponsor. So this is something I certainly believe in and I use it on a daily basis. Go and check it out. Century.io. They have excellent tooling available for pretty much any platform that you want to use. Thanks again to Century for sponsoring today's episode of Developer Tea. So I want to kind of rewind, like I said, and talk about a few moments along the way that, you know, maybe are high and low points for you. And we want to start with the moment or maybe the period of darkness or confusion, a time when you couldn't really, you didn't really know what the next steps would be. And kind of take us to that moment and the things that you were feeling and experiencing. So I've touched on this a little bit already. I would say the most recent like actual period of darkness was a handful of months after I had left Thopbot, after I launched my course and I was kind of looking at like what's next for me. And the like I said, the conclusion I came to was I don't want to do this by myself. This just is not a good fit for me. And so I didn't really know where to go from there. Like I knew I knew the like the high level goal. I was like, I want to build a company with some friends, but like all the pieces had not come together. And so I felt like I was kind of a little bit like retreating or kind of like kind of slaced putting off that goal, that dream for a little while by taking a job. And that was kind of crappy. That didn't feel good. Yeah. So then and how did you like process through that? Or do you do you know, do you like process through your feelings by thinking about them? Or did you actually, it was this a time when you were, you know, going to a therapist at the same time and trying to work through like how did you actually overcome this, this sense of unknowing? I am a, I rely on other people a lot when I'm working through stuff like this. So I've, I've been fortunate enough to sort of build a support network over the years of people whose opinions I respect and trust. And so like I consulted with some of those people when I left Thapa and I consulted with them as I was struggling with this afterwards. And so that helps, that's always been like kind of my go to. I definitely make progress thinking about things on my own, but there's something about like maybe it's the extravert in me again. But like when I process like when I'm working through something with somebody else, I feel like I make the most progress on it. Yeah, that makes sense. That makes sense because people can provide you perspective that you can provide yourself. Exactly. And it's so valuable. Like that's more or more than anything. Like I'm great at looping through the same five facts in my brain over and over again and trying to figure out what that means. But once someone like shows up with fact number six that has alluded me for a while, it's like it's, it's going to be so huge, it can really unblock stuff for me. Oh yeah, yeah. That's, that is excellent. That's a great way to think about it. There's a really good book on this. It's not just on this subject. It's a quite large book, but Ray Dalio wrote a book called Principles. Sure. In Principles he talks about some similar things, but one of the most important things he mentions in there is the idea that, hey, you know what? Like you have to accept that you have that you have weakness, that you have blind spots, and that other people are really the most efficient way to deal with those. Like you're not going to be able to reveal those things to yourself because they're legitimately, you can't see them. Yeah. So that's one of the kind of the main points in the book. It's like I said, it's a long book, but one of the main points in there is, hey, like for you to be able to actually achieve what you really, you know, are capable of achieving in the long term, one of the most important things you can do is cross reference yourself with other smart people who care about you. Hmm, sounds good. That's good stuff. Yeah, excellent. I still doubt, I still doubt reading principles. Like I really enjoyed like the story, like the narrative section, and then I hit the principle section and I was like, this just got kind of really dry, and I ran out of focus. It is definitely dry, and I actually didn't go all the way to the end. I'd skimmed all of the index of principles, but I didn't finish all the way through the business principles. I went through the life principles completely, but not all the way through the business ones. The life principles are really kind of reiterated in the business principles, basically, but you know, I think it depends on your personality, right? It depends on if you like that kind of analytical. It's essentially building an argument for how to be from the ground up, and some people are like, oh, that's too, you know, that's cutting away too much for it to be interesting, but for me, that's the kind of argument that I like to make. Sure. Okay, so we've covered this dark period, and a great takeaway there is sometimes you can't just get out of it on your own. Sometimes it really helps to have other people in your life, a support network, and people who can kind of illuminate things that you otherwise wouldn't have illuminated. Totally. Yeah, and this is it. This is probably why a advisor, like a therapist can be so useful, because you don't even have to beat that brilliant sometimes to just notice the things about somebody. Oftentimes, my therapist is literally just pointing out, well, you said that X is true, and here you're doing this thing that makes it seem like you don't think X is true. Do you really believe that? Or why are you not operating in like concordance with this thing that you supposedly believe? And it's like, yeah, it's not even like the most brilliant insight ever, but damn, you're right. That's, that says a lot. Right. It's kind of like, you know, it's, you can't see every inch of skin on your body, and it's like somebody just holding up the mirror in just the right spot, in just the right angle, so you can see the parts that you can't see. It's a very interesting phenomenon where you see something that's a part of you that you didn't realize was a part of you. Yeah, definitely. And like, it's crazy how often I've had this experience in therapy of them just saying like, did you hear what you just said? And then just like, like forced me to stop and listen to myself for a second. Yeah. You're not even pointing out new things. You're literally just like making me listen to my own thoughts. Like, what am I paying you for? But it, it, it, damn, it works. It's like, it's crazy. What a self-deluded haze we walk around in. Yeah. Well, the idea of kind of being in our brains or kind of unaware of our thoughts, right? And this is something that, you know, if you're practicing anything mindful, yoga, or meditation or anything like that, one of the first things that you'll learn is that you can begin to kind of separate yourself from that. And instead of being, you know, just experiencing your thoughts and not being able to observe them, now you're taking time and doing exactly what your therapist can quite literally forced you to do, which is, hey, wait a second, back up and look at what you just said, which is a representation of something you were thinking. Now let's, let's think about the thinking. Yeah. And that's really powerful, right? Totally. Okay, Ben. So we've made some good progress here today. I do want to talk about, you know, we've talked about the unknowing, but I'd love to talk about more of the kind of the epiphany moments or maybe exciting moments where things kind of suddenly became clear for you and high points along this journey. You know, what are some things that you remember that that kind of stand out? You feel like you're going to remember in 10 or 20 years from now? Hmm. So when we were thinking about doing this, I was like, you know, it would be great to talk to one of the screen hero guys and just see if they like what they think because so screen hero got gobbled up by slack and then shut down. But like, I was like, so I think there's still a market here, but I wonder if maybe I'm wrong, maybe like the the slack version of screen hero is sufficient or or someone else has shown up and eaten this market and I'm just not aware of it. And so we did a call with with the sky and his feedback was like so positive. He's like, I think there's totally still a need here. There are a lot of problems with the one that slack rolled out that make it not suitable for paraprogramming. It's fine for a general collaboration tool, but it's not good for what screen hero was going to add and what this market wants. And he was like, yeah, you should do it. Go for it. It's doable. It's hard, but you can do it. And yeah, which was awesome. Very encouraging. And then like the next day, so I have two co-finders, but at this point, there was only two of us total. And so we had a chat in a coffee shop and it was the like, so we're going to do this chat. And it was really clear that conversation with the screen hero person like really pushed it over the line. And it went from like, this is a fun idea we're talking about and batting around to like, all right, like, are we going to quit our jobs? And the answer was, yeah, we're going to quit our jobs. Wow. Wow. And that's such an important moment. But it's not the only moment. I love that you have this kind of this linchpin thing. And I think it's a really good reminder for us as, you know, just as humans that encounter each other every day. The conversations that we have with other people, you know, if fast forward, you know, somebody comes to you and asks you, hey, should I do idea X? And you take the time to take that call. And you say yes. And that person for that, for, you know, in large part because of that conversation, that person goes forward and makes an incredible product, right? And it's really interesting. The nudges that we give each other without really considering the long term. How does this actually affect that person? And I love that story because it's not just, you know, you're not making a decision and a bubble. And you and your co-founders are not just making decisions and bubbles. You're taking an input from other people and you're looking at the market and you're listening to what the people at screen here will have to say. And it's not just this calculation. There's a lot that goes into you. What would finally end up being this huge decision for you all? Totally. And I would almost like zoom out a little bit there too, where there actually have been so many people that have helped us since we decided to go do this. And we are, I think we all feel really grateful for that. Like it's not like there's this sense when we first started where I was like, okay, this is a hard technical problem. But I bet we can eventually figure it out. And my mindset has kind of shifted to like, this is a hard technical problem. And with the help of a bunch of people, we will eventually get this figured out because people just keep being willing to like, they keep taking our calls, they keep helping us out, they keep offering advice, they people are willing to become early customers and give feedback or connect me with somebody else. And like, let me come on their podcast. And it just, just by like kind of the goodness of most people out there, I feel like eventually we will hopefully succeed. And but succeed or not, like we've been given a really good chance because of the kindness of a lot of people. And so I would say all three of us are actually really excited to hopefully it works out or maybe it works out it doesn't, but to pay it forward basically and to be that for other people later. Yeah, that's really exciting. And I hope that all of this goes that direction not only for you, but also for all of the people who need this tool that you are that you're currently working on. And I know I look forward to to the chance to try it out in the future. So thank you for doing the work that you're doing. And I have one more question for you before we end the show out. And it's a very simple one. If you had 30 seconds to give developers a bit of advice, what would you tell them? Hmm. Believe in your ability to learn and achieve things. Your brain is super plastic. You can change it. Don't talk about yourself as a static entity. Think of yourself as a variable that mutates over time and just have a lot of faith in your ability to become the thing or the person that you want to be. That's excellent advice. Ben, thank you so much for coming on the show. That pleasure is a lot of fun. If people want to find out more about Tupel or about the things that you are doing, beyond that as well, where can they go? So if you want to hear like when Tupel, like when we're opening up spots and whatnot or just sort of stay in touch, tuple.app is our landing page. We have an email list, of course. If you want sort of more regular updates, you can follow me on Twitter. I'm R00K. And I also host a podcast each week called the Art of Product podcast. And it's me and my co-host talking about what we're doing in our businesses each week. So you kind of get a two-fer of two software startups. That's very exciting. Cool. I actually will have to go and subscribe in that. Thank you so much again, Ben, for coming on the show. My pleasure. I loved it. Another huge thank you to Ben Orenstein for joining me on Developer Tea for the second round of our interview and for the second interview on the show. I really appreciated Ben's time and all that he had to share with developers like you and developers like me. I hope that some of you are encouraged to, for example, maybe go out and start your own thing. That's the kind of thing that we hope happens as a result of this show. But beyond that, very small changes. Small changes in the way that you think about your career, small changes in the way that you think about your personal health. Those are the kinds of things that we're trying to insight as a result of this show. Speaking of small changes and challenges, I encourage you to go and follow Developer Teaon Twitter. We're going to be posting every single day. We're posting a T-break challenge. This is a daily thing. We're going to be expanding to other platforms, but we wanted to keep it relatively small to begin with to see how people catch on to this idea. But the T-break challenge, you can find it on Twitter at Developer Tea and of course, on spectrumspectrum.chat. Thank you so much for listening. Thank you again to today's brand new sponsor, Cintry. However, to Cintry.io to get started fixing your code today instead of relying on your customers to report all of those errors that you didn't want them to see in the first place. Thank you so much for listening to today's episode. If you are enjoying Developer Tea and you haven't subscribed yet, I encourage you to subscribe. At the beginning of 2019, we're kicking things off in high gear. We're going to have tons of episodes at least three a week throughout this year. I encourage you to subscribe if you don't want to miss out on that content. Thank you so much for listening and until next time, enjoy your tea.