Developer Tea

Interview w/ Julian Shapiro (part 1)

Episode Summary

In today's episode we're joined by Julian Shapiro and in this first part of a two-part episode, Julian talks about building Velocity. js and what he learned while building that project. Be sure to subscribe in whatever podcast app you use so you don't miss out on part-two, coming out this Friday.

Episode Notes

In today's episode we're joined by Julian Shapiro and in this first part of a two-part episode, Julian talks about building Velocity. js and what he learned while building that project. Be sure to subscribe in whatever podcast app you use so you don't miss out on part-two, coming out this Friday.

Thanks to today's sponsor: Manifold

Why build your own logging platform, CMS or Authentication service yourself when a managed tool or API can solve the problem for you?

With services covering authentication, messaging, monitoring, CMS, and more, Manifold will keep you on the cutting edge, so you can focus on building your project rather than focusing on problems that have already been solved.

As a Developer Tea listener, you will get a $10 credit to put toward services when you sign up. Get started at https://www.manifold.co/devtea.

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

If you'd like to connect with Julian about anything he mentioned in today's episode be sure to follow him on Twitter. Be sure to check out what he's working on over at Julian.com and his past work over at http://velocityjs.org/

šŸ§” 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.

Episode Transcription

You've probably used something that today's guest builds without even realizing it. Today we're talking to Julian Shapiro. Julian is the author of velocity.js. He also writes a bunch of very useful guides at julian.com. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on this show is to help driven developers just like you connect to your career purpose so you can do better work and have a positive influence on the people around you and we do these interviews to try to figure out how other people are doing exactly that, how they're connecting to their purpose, the struggles they face and we try to learn from their experiences here on Developer Tea. Let's get into the interview with Julian Shapiro. Julian welcome to the show. Pleasure to be here. I'm excited to have you on and I'd love for you to answer this question to kind of kick us off. What do you want people to know you for? Julian. Interesting. So I'd say looking back 20 years from now, I'd love for them to think of me as someone who earnestly tried to write the best summary of everything I'm passionate about and I hope that got them similarly inspired to be passionate about what I am. So marketing, the science of building muscle, critical thinking, how to write, that's what I would love to be known for. Yeah, and you're writing about these things now, right? So this isn't just something that is a future dream of yours. You're actually acting on those desires, yes? Yeah, it's something I sprinkle in through all my free time. But what's also interesting is, even though I don't have as much free time as I'd like, what I realize is how much better subsequent drafts are of everything I write when I simply allow time to pass. And it's self evident. It's almost a cliche actually. People, many people are familiar with this, but when you're literally forced to space out revisions over the span of half a year, because most people probably would have gotten done, but I get done in a much shorter period of time, but when you're forced to, because you really don't have the time, but you do have the consistency, it gets so much better. I'm embarrassed by the previous draft of everything I write, including everything currently on my website. So I really, really benefit from that. Yeah, okay, so that's a very interesting kind of effect and I want to get back to it. What do you think people might already know that you've worked on and maybe they don't know that it was you that worked on it? Yeah, sure. So I guess I built something that a lot of people use under the hood, which is Velocity JS, an animation engine. And it was the output of me having taken a year off from working and trying to figure out what is the sort of highest leverage fix that I could work on for front end development as a whole. It could have been anything. I was just interested in coding. I was interested in doing so without any sort of business objective. And I landed on performance, like the actual speed, the paint time, the effect on UX of having just performant website animations. So I went through the docs for the browser engines and the CSS facts. And just try to figure out and log the performance of our little tweak and try to figure out how can I squeeze as much performance out of front end animation because the status quo at the time was jQuery and therefore jQuery's own animate function, which was notoriously slow. So you couldn't do all these beautiful sexy animations. You would get through web GL or through even flash. You couldn't really do that across most devices. So this was like four years ago. So I set out to build that. And it actually culminated interestingly enough with jQuery asking if they could use velocity JS, if they could actually merge it into jQuery to replace its animate function. And so that was a cool little serendipitous moment. And I guess one quick last thing, this might be a longer answer than you're hoping for. But in the process, I wanted to demonstrate its adoption and not actually less so demonstrate to others, but more so know for myself who's using velocity. And so I built a second project when velocity was released called libscore, which was in partnership with Stripes Open Source Grant. And it crawled the web that basically spun up phantom JS instances and crawled the real time essentially variable environments of the top million sites on the web, ranked by traffic, and then sniffed all those global variables and tried to figure out what were they associated with, which library. So when we were scraping HTML, you were actually sniffing the global variable environment so we could figure out what gets injected by module loaders and whatever else to get to the real bottom of what's running on this web page. And so we released that into the wild. DigitalOcean was kind enough to actually give us an un-build account. So like a bottomless pit of just compute. It's pretty cool. And so we ran this across the web and found out for the first time ever, all of the thousands of websites that are using velocity. I had no idea. I had no way to tell. And so launched it, crawled, got the results. And I remember basically turning on my screen, looking at the results of this crawl and realizing that Uber, Samsung, Microsoft, New York Times, like everyone, all these big names that I had looked up to were using velocity. And then it became useful for other developers as well because they also had no idea. Yeah, wow. And when was some of this stuff released for the first time, just to give people a time frame kind of a mental time frame for when they may have encountered velocity? Yeah. So I think velocity was maybe four years ago and then lib score maybe a year after that. That's the right, yeah. The interesting parts of this story, I mean, did you haveā€¦ An engineering background before you started on this project? See, that's why I love that question because it gets to a deeper, imposter syndrome, which I wonder if other people feel. So I have zero comp-side background. I went to school for, I had to do a bachelor's, one in film, and one in economics. And my knowledge of CS was just hacking garbage code together, PHP, JavaScript, eventually node, then back to the front end for velocity. And even while coding velocity, which a lot of people say, wow, you coded an animation engine, a physics engine, it's like, I'm not that competent. Basically I justā€¦ I look at it almost as like general AI and narrow AI. I am not the general AI. I am not a good coder who could be hired by others. And in fact, that's a little bit of a story about that was straight. But what I am is much like my writing on Julian.com, I go very narrow and very deep and become obsessive about mastering something. And so in the case of velocity, I went obsessive about mastering browser performance. So there was a time where it was basically maybe Paul Irish myself and some dev advocates on the Chrome project and Firefox who knew as much about browser performance, not under the hood, but on the actual user facing side as I did. I just knew everything. And then I learned what else I needed to know to actually build out a well-tested, stable animation engine. But the way it was architected was by no means brilliant. And I'm sure it's done a lot better. And I remember there was a moment where you realize like if you go to CDNJS.com right now or some other service for tracking CDNs for JavaScript or even look at the NPMJS stuff. Yeah. The loss these used, I think serves a few billion impressions or maybe tens of billions impressions per month still. And so realizing that I don't know how to code. And if you look at the history on the repo prior to me stopping working on velocity about a year and a half ago, every line was coded by myself essentially. So the fact that I was singlehandedly coding what was powering his major websites was very freaky. And I knew I'm ever thinking to myself like guys I haven't unit tested this very well. And I was Microsoft using this. I swear to God I barely, I have not tested this properly. Just craziness. So yeah. Wow. And the truth is, so let me fill in some gaps maybe for people who are unaware of why this is a big deal and why, you know, why having an engineering background would be more kind of expected in this scenario. Doing animation stuff is pretty tough, right. But beyond that, jQuery at the time they released velocity J as was to put it, you know, very simply it was the leading JavaScript everything on the way. Essentially every person writing JavaScript either knew about jQuery and decidedly chose not to use it or they used jQuery, right. There was no, there was no kind of in between. It wasn't like there was a war amongst a lot of options. Instead, this was kind of the thing to use. And so there were tons of animation kind of stacks that were built on top of jQuery as a result. So for Julian to come in and build a library that essentially directly challenges jQuery without a computer science degree is very much so. I guess you could call it like a David and Goliath story, even though they aren't necessarily against you. And as it turns out, eventually work quite the opposite and you decided to work together. Now, this is not really what you would expect as a brand new developer to be able to write this thing kind of out of the gate that ends up being such a powerful and important piece of software for the web and not just for the web, but for the browser, really. Yeah, it truly was the first project I'd ever coded from start to finish and release publicly or even any sort of production environment. It truly was the first thing. And I think it's completion to one, my sort of fanaticism and two, the realization that if this doesn't work, it could break a website. It could not. It could a modal might fail to animate to full opacity and so a site might not work. And so I got pretty obsessive about just trying to actually bought maybe 12 different devices and sync them up through this like ghost browser thing. I forget what it was called and just test religiously the absolute wrong way. But my point is I became compulsive about ensuring I was doing the best job I could from a de-risking perspective. And I figured if I coupled being obsessive about de-risking with being obsessive about understanding everything one could know about performance so I could squeeze out the most performance out of this engine versus anything else out there, I was like, that should be enough. And if I focus on that, it doesn't matter how well it's architected, it just matters how much fun I'm having and whether I'm going to see this to completion. And that's really most of the battle. I think most people simply don't complete their projects. You've mentioned this word a few times and I think it's incredibly important to kind of pull out and maybe inspect a little bit deeper. The word obsession. I'd love for you to tell us first, is this something that you feel like as a part of your DNA? Have you always been in the positive sense of the word obsessive about the things that you do? And number two, how can developers cultivate and perhaps use obsession to their advantage? Because obviously this was a key part in the development of this very successful project. Saying that, or I guess accepting the idea that luck was involved beyond luck, your obsession kind of gave you that other factor, maybe of grit. And I'd love to know, how do you stay obsessed or cultivate that obsession? For me, I think obsession is basically shorthand for the combination of flow and the joy of hacking stuff together. And if you are in a flow state while incrementally hacking something together, obsession naturally follows. And so I'm actually misusing the word obsession because it's not an obsession where I feel truly emotionally compelled to do something. It's just that I don't want to break my momentum. And it is so pleasurable to stay in this momentum. Like the dopamine hits are so real and so recurring that the inertia is really what I'm describing. And so when I think I'm good at identifying things that cultivate inertia in me because I think I know what I like. And so when I can identify something I like that can be hacked and has a reward cycle that enables flow, then be over. I'm going to be locked into it. I'm going to get it done. So a couple of examples. A velocity of course is one in the form of hacking together performance benefits. And the flow state there is I would find a performance benefit. I would then run my test suite. I would see the decrease in lag or the increase in frame rate. And that back and forth reward cycle creates a lot of inertia where I keep wanting more and more and more. Basically, game of finding my pursuit. And another example is the writing I do on julien.com, which is very much the same thing where let's say I'm writing a guide on how to write well. I will start by obsessively finding every single book ever written on how to write on Amazon with decent reviews and a certain threshold like a threshold count of reviews. And I will buy them all. I will read every single one start to finish no matter how boring. And I will try to pluck out the gems of wisdom, the diamonds and the rough, even if the book's terrible. And then I'll collate all those together. So at this point, my flow, my reward system is just, did I find a diamond in the rough every few pages? Great. Copy, paste, throw into a document. And now I'm collecting and incrementing and hacking together this giant rubric of how does one write phenomenally well. I'm not saying I'm there, but I will get there thanks to this process. And so as I hack that together, I can then formulate and figure out the natural structure of how to teach that to other people. So I would say almost everything I do follows this same pattern. And if I were to try to help others to repeat those steps beyond what I've just mentioned, it's have a real understanding of what it is you like. And that usually comes about from trying a lot of stuff and is being honest with yourself. We talked about this in today's episode and we talk about it in other episodes on Developer Tea. One of the worst things you can do is waste your time. And sometimes that's not so easy to figure out exactly how you waste time. Managed cloud services save Developer Time and effort. It wouldn't really make sense, for example, be to build your own logging platform or your own authentication stack or your own content management system. In a managed tool or an API can solve the problem and often solve it better than you could in the first put. But how do you find the right services to integrate? And on top of that, how do you take the biggest advantage of these services and stitch them together in really unique and powerful ways? And how do you manage access to all of this and the credentials between multiple projects and multiple teams? Managing these details alone is essentially a full time job. Manifold makes your life easier by providing a single workflow to organize your services, connect your integrations and share with your team. You can discover the best services for your projects in the Manifold Marketplace or you can bring your own custom integrations and manage them all in one unified dashboard. With services covering authentication, messaging, monitoring, content management and more, Manifold will keep you on the cutting edge so you can focus on building your project rather than focusing on problems that have already been solved. Once you have the services you need, you can deliver your configuration to any environment and deploy on any cloud. Now while Manifold is completely free to use, by the way, that's a huge reason to support them, if you head over to Manifold.co slash devt that's Manifold.co slash devt, you'll get a coupon code for $10, which you can use to try out any service on the Manifold Marketplace. This $10 basically for free just for being a Developer Tealistener, head over to Manifold.co slash devt to get started today. Thanks again to Manifold for sponsoring today's episode of Developer Tea. That is extremely important. That's kind of the whole point of this show actually. I'm glad that you kind of backed your way into that as you went along because the whole point of this show is to uncover your purpose. One of the real and very important aspects of your purpose is understanding what you like. In some ways, they are orthogonal to each other. The idea that we have preferences, and when we combine those preferences with the values, the things that we care about, the being true or the ethics that we want to forward in the world, the legacy that we want to leave behind for the next generation or how we want to impact the other people around us. When we combine our preferences with that, then we come up with something that we really do actually care about. And that care can fuel us. And I love that flow state for you in this reward cycle, you're gamifying and using your preference, it's kind of a two-sided sword to approach mastery. You're using all of these kind of psychological principles to set yourself up for a pursuit of mastery on a given subject. Exactly. And I think a key ingredient that some may overlook is actually being interested. And so it's the interest plus the self-gainification, you need both to attain mastery. I feel pretty strongly about that. So your interest in browser performance, what do you think is kind of the deeper thing that caused you to be interested in that? And we're just using this as an example. There's certainly more things. It's a really good question. And I actually know this because I had to think about this a couple years ago for an interview. And I realized it was having watched, I think Iron Man the first. And I saw the animations in Tony Stark's heads-up display within the helmet. And I thought, damn, that's really cool. How neat would it be because VR was coming out around the first version of the second dev kit version of the Oculus was coming out around the time that I was releasing velocity? And I thought, how cool would it be if we could replicate those HUD effects in the Oculus? And I could power it using JavaScript because I didn't want to have to learn whatever was being used then to make Oculus games. And I wanted to empower everyone to do really cool stuff. And I thought that would be one of the greatest things ever. And so it was something about getting that cool superhero animation effects that mixed with the beautiful trailers before these types of movies I wanted to see if those could be replicated on a website, not as a video, not as WebGL, but like DIVs and tables, you know? And that, I get a huge kick out of gorgeous web animation. For whatever reason, I just find that, or animation anywhere, frankly, HUDs, websites. And so it just wasn't possible to do it very well in pure JavaScript, which is the most accessible language to the highest number of people who know how to code. Yeah. Wow. And so there's this kind of factor. And I think on this show, maybe there's, you know, I try to play out what I think people who are listening to the show are saying in their heads when they hear, when they hear me discuss something. And I think one of the things, one of the narratives about this show that maybe believed is that I'm extremely serious. Let me kind of break that down, then your purpose has to be some, you know, altruistic motive. And then everything has to be about, you know, making the world better in some fundamental way. And that's not, that's not at all the case. There's so many things that go into this. And your example here is, is a perfect example of this. You watched a really cool trailer that somebody used probably after a fact or something, and they built this awesome animation. And you wanted to make this, this kind of, this movie fantasy thing a little bit more accessible. And that can be a purpose for a person because you just really enjoy it. You think it's super cool, right? That's, it doesn't have to go, you know, deep to your core and your identity as a human to be a valid reason to do something. Absolutely. And I think that comes down to time horizon. So in the short term, I think it's okay to have a non altruistic, low sort of purpose, pursuit so long as you're loving it. But I would not want to be the guy who is doing, a HUD animation, so heads up display animations throughout the majority of my working life. Because if I look back when I made it, as per Jeff Bezos's re-initization framework, where, you know, choose what you work on in a way that if you were 80 looking back at where you are now, you would not have regretted not doing something else. And so back to my points, I would not want to be doing that forever. But in the short term, it's a wonderful excuse to have fun while learning. And once you've gotten those learnings, then you can apply those to something that you find more meaningful. Now, I'm not saying one cannot find life-long purpose in something like this, but I could probably make a decent argument that most couldn't and most people would want something deeper. And so I think again, it comes back to time horizon. How old are you? What is the short term? And can you do a purpose this pursuit to gain mastery on something that could then serve you in perhaps a larger vision? Yeah. And I think it's also important to understand that these things stack, right? There's not just a single, you know, outcome from this. You mentioned learning, but there's so many other things. You make connections along the way, right? You actually had a chance to learn, you know, it's not just learning about JavaScript, maybe it was learning about some of the fundamental ideas and the modeling of animation, maybe things that you hadn't experienced before. And so the learning is, you know, at a fundamental level, it's experience, right? And so if we take our experiences and we stack them together, then even the things that, like you say, are on the short time horizon can absolutely be stepping stones to those longer term visions that we have. And that was exactly the case for myself. So let me walk you through the byproducts of having pursued velocity. So I built the animation engine, I pushed it out there, I was living in Vancouver looking for an excuse to somehow come to California. And keep in mind, it's not that easy to get a green card. Certainly, now if you're unwilling to work for someone else, I wasn't quite sure how I was going to come to California because I was already working on my own stuff. And so I released this animation engine. And what's that Adobe Google, a few YC companies, YC, why communist companies, I wanted to work wanted to hire me. And it was enough of a sort of kick in the butt, like fire into my butt to say, you know, let me go work for someone. And despite, let me stop the start up I'm pursuing, let me go and work for someone because I really want to be in the US, I want to be around awesome people. And that led me to the second byproduct, which was there was a period there may still be, I don't have a poll for this, like lib score is a poll for library usage, but where a lot of people had heard of velocity. A lot of people were using it, a lot of people subsequently, or consequently knew my name in San Francisco in particular. And so, so a bunch of people sort of follow me on Twitter. And this is this this tiny little bit of cloud I had, I was able to leverage into meeting just what everybody I had wanted to meet. So CEOs, people who were who were working on major open source projects, writers, all sorts of people. And it was because I looked like I had a, I had something I had a following at some sort of social proof as a result of velocity and its adoption. And another thing that happened with velocity is I released it and Stripe offered the open source grant to me, which is a program they're running to fund open source project Developer To come work out of their offices and work on those projects in their in the Stripe environment surrounded by all those smart people and resources. And so I got that and that was an amazing, that changed my whole career trajectory doing that. And so one thing I want to point out before I wrap up with like with my list of velocity by products, with none of which were planned, all of which just came about naturally from the following thing. I grew velocity. And that's another key distinction that, well, let me step back a bit. So there's kind of two problems that I think a lot of open source developers face. One is they don't finish their projects. And another one is they don't then grow it after they finished it. And when I say grow, I mean market, you know, get the word out. And when you don't grow your open source and amazing it, and mission engineer, whatever your project is, what was the point of building it? You build it for yourself. Okay. Well, how about you put in now 10% of the time it took you to build a thing. And if you want to do the truly altruistic thing, allow other people to hear about it so their lives can be bettered by what you've done for yourself. If you live in a little chamber, that was actually a pretty selfish act. It was not also the best use of time probably. So there's this sort of angst. Some like if you consider the cliche of the like Linux, neckbeard guy who's like, you know, I'm going to build it. Well, he wouldn't say yo, first of all, but you'd say, I'm going to build this thing. And I'm not going to market this. People will come to it. They'll either see its merit or they won't. And so these are the type of people who as this cliche goes are unwilling to do, you know, quote unquote, cheesy, gross, salesy marketing. But you're short selling yourself. It's not cheesy and gross. You're doing the world a favor. And so to wrap all this up, I put in, I actually, I explicitly thought to myself after I released philosophy. I said, that took a long time. That was like eight and a half months of my life. I'm now going to spend at least a month and a half doing nothing but full time getting the word out. And that's exactly what I did. And that is what led to this momentum of awareness, which led to all those byproducts that I mentioned. Wow. There's so much to unpack in this story and in the particulars of this story. And I especially, I want to focus on this last thing that you mentioned, the idea that to work on a project for myself and to not put marketing effort into it, not grow it, not share it with the world. You know, for example, not taking the time to even write documentation for the thing that you build that is open source and available to the world. And that that is actually in a way, it is a selfish act. And the idea here, I think perhaps the reason for this actually, the reason this happens more often than it should, is maybe connected to our fear that what we make is not valuable. And it may actually be a bit of, you know, imposter syndrome that's happening where somebody says, Hey, you know what? I'm going to make my own little animation library. Imagine in an alternate parallel universe or something. Julian, you decided to make your own animation library because you're not trained and because there's this huge juggernaut jQuery. And because you didn't write the unit tests and you know that you didn't do it that, you know, the right way, you decide not to tell anyone about it. And in fact, you don't even name it velocity. You just name it Julian dash animation.js, right? And then it goes away and nobody ever knows about it. And unfortunately, you know, all of these kind of mental models, these preconceptions that we have about the world and about our place in the world and about our participation in the world, they can fall apart. They fall apart because we don't really play it out. And this, this perspective that we have of ourselves and the work that we do as not very valuable really is is often incorrect in one way or the other. And we overvalue the things that we create. But more often than not, these open source projects, these open source scripting even, right? Very simple stuff. Even at the work that I'm doing at ClearBet, sometimes we have really simple things that if we were to share them with each other, I encountered one recently, it was actually filters for Gmail. Such a simple thing, right? And it seems like, oh, this is just for me. This is something that I don't really need to share because certainly everyone else has filters. Certainly, everyone else has already solved this problem. But as it turns out, that one thing saved me a massive amount of time and headache of trying to go through and figure out filters for myself and somebody has shared their filters with me. And this simple act of sharing, even if it doesn't end up going gangbusters, blowing up and Jake where he asks, you know, comes knocking on your door and asks to merge with you, even if you don't have the same success story that Julian, you've had, that doesn't mean that sharing that value won't provide some benefit not only to other people, but also to you. And I think that's really kind of the ultimate moral of this story, Julian. Yeah, if you're honest with yourself that you are solving a problem, meaning if the problem you choose to solve through your open source project is one that actually exists and hasn't been adequately solved. Meaning, if you're just being blind to the reality that it is actually a solved problem, and at least one other person is going to have your problem. And most likely, many other people will have that problem because if you're working in JavaScript, a lot of the problems are universal. And so let them, let them market using growth in sales terms, actually dictate whether it's valuable or not. Don't prejudge if you solve your own problem that's enough of a criterion to say, let's see what other people think, and to give it a real shot to know what other people think, you have to do at least a little bit of marketing. And that's something that we're going to talk about pretty at length. This is something that you care a lot about. And it's really what you do kind of as your bread and butter business, right? The work that you do at Bell Curve is all marketing and growth, correct? Yeah, that's right. And the itch for that came about from the obsession I had growing velocity. So the flow state and the reward cycle of building velocity, looking at the browser performance hacks, then translated to or transferred to the actual growing process of velocity, where I would get a little bit of blog post coverage, get a little bit of adoption, and the reward cycle was fulfilled by seeing the additional GitHub stars. It's a superficial metric, but it is a proxy for general adoption. It's something. And so that cycle took off. And I was like, oh, well, how else can I get the word out? How can I get 5,000 more GitHub stars? How can I get, you know, Samsung to use this? And that just became its own part of my life for a few months. And I pause and said, all of these skills I'm learning, how to get the word out systematically, they apply equally to a startup. In fact, they apply better to a startup because you can do so in service of actually earning revenue, and you can put money in to put poor fuel on that growth fire. Because with velocity, I'm at the mercy of my purely my wits and my resources and my social networking essentially, because I'm not paying for any discovery. And so it comes down to, well, how else can I use these skills? But most importantly, I fell in love with the process. And I realized this is the branch in my career that I'm now going to pause at and choose a direction. And I chose, yes, use these skills I've developed and pursue growth marketing, which I'll define briefly. So you have your marketing, which is all encompassing, getting the word out about your thing. And then growth marketing is specifically the subset of marketing focused on moving the needle on your metrics. So improving revenue, doing so in a calculated and attributable way. So you know it's positive return on investment. That's what growth marketing is. You can contrast that to say brand marketing, which is kind of like scratching your back, getting the word out, sponsoring a conference, putting up flyers. You don't know how well that's performing. It's probably not doing that good of a job. You're kind of getting the word out. That's what I don't do. It's just less effective for all the things I'm interested in. Thank you for listening to today's episode of Developer Tea. And a huge thank you to Julian Shapiro for joining me on the episode head over to julian.com and sign up for updates when Julian writes he releases these guides. They're completely free and they're incredibly useful head over to julian.com. Thank you so much for listening to today's episode and thank you for heading over to check out manifold manifold.co slash devt. You get $10 worth of credit for free just for being a Developer Tealistener. And by the way, manifold is free to use. And check it out manifold.co slash devt. Thank you so much for listening. If you heard anything useful, anything valuable in today's episode, then it's probably a pretty good bet for you to subscribe and whatever podcasting app you use because we do episodes like this one on a regular basis, three episodes a week. And subscribing is the best way to make sure you don't miss out on future valuable episodes. Thank you so much for listening. And until next time, enjoy your tea.