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.
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.
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.
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/
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.
You've probably used something that today's guest built 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 Cottrell 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. 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. Yeah. Yeah. At the end of the day, of everything I write when I simply allow time to pass. And it's self-evident. It's almost a cliche, actually. 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 what 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 VelocityJS, 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 animation. So I went through the docs for the browser engines and the CSS specs and just try to figure out and log the performance of every 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 WebGL 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 VelocityJS, or 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 Stripe's open source grant. And it crawled the web. It basically just went from there. And I built a second project when Velocity was released called Stripe's open source grant. And I basically spun up PhantomJS 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 we weren't scraping HTML. We 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 webpage. And so we released that into the wild. DigitalOcean was kind enough to actually give us an unbilled account. So like a bottomless pit of just comp 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 I was like, oh, this is a really good idea. And I was scrolling through the evolution of evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution Velocity was maybe four years ago and then LibScore maybe a year after that. Okay, yeah. That sounds about right, yeah. And 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 sci background. I went to school for, I had a dual 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, oh, 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, I have a little bit of a story about that with Stripe. 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. I wish 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 could have been a lot better. And I remember there was, there's a moment where you realize, like, if you go to CD, njs.com right now or some other service for tracking CDNs for frontend JavaScript, or even look at the NPMJS stuff. Or then, yeah, Velocity's 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 I was, if you look at the history on that repo prior to me stopping working at Velocity about a year and a half ago, it was every, every line was coded by myself, essentially. So the fact that I was single handedly coding what was powering these major websites was very freaky. And like, I knew, I remember thinking to myself, like, guys, I haven't, I haven't unit tested this very well. And how is Microsoft using this? I swear to God, I've barely, I have not tested this properly. Just craziness. So, yeah. Wow. It's, and the truth is, so let me fill in some gaps maybe for, for people who are unaware of why. Why this is a big deal and why, you know, why, 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 that you released Velocity.js was, to put it, you know, very simply, it was the leading JavaScript everything on the web. Essentially, every, every person writing JavaScript. Either knew about jQuery and decidedly chose not to use it or they use 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. And so for, for Julian to come in. And build a, 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 we're quite the opposite. You decided to work together. This is, this is not really what you would expect as a brand new developer to be able to write this kind of stuff. Right? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.! start to finish and release publicly or even any sort of production environment it really was the first thing um and i think i credit its completion to one my sort of fanaticism and two uh the realization that if this doesn't work uh it could break a website it could not it could 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 uh just trying to i actually bought maybe 12 different devices and sync them up through this like ghost browser thing i forget what it was called and just tested 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 doesn't matter how well it's architected just matters how how much fun i'm having and whether i'm going to see this to completion and that's really um most of the battle i think most people simply don't complete their projects you 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 um i'd love for you to tell tell us first is this something that you feel like is a part of your kind of dna where have you always been um you know 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 you know this this was a key part in the development of this very successful project um you know saying that or i guess accepting the idea that luck was involved beyond luck you know your obsession kind of gave you that other factor maybe of grit and i'd love to know you know how do you stay obsessed or cultivate that obsession for me i think obsession is 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 evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution 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 game over, I'm going to be locked into it. I'm going to get it done. So a couple examples, uh, velocity of course, is one in the form of, uh, 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, uh, creates a lot of inertia where I keep wanting more and more and more. I'm basically gamifying my pursuit. And another example is the writing I do on julian.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 everything that I can find that I can use to make a good product. And I'm going to start by 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 that the diamonds in 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 hacked that together, I can then formulate and figure out the natural structure of how to teach that to other people. So, um, I would say almost everything I do follows this same pattern. And if I were to try to, um, uh, help others to, 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 just being honest with yourself. We talked about this in today's episode, and we talk about it in other episodes on developer T 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 developers time and effort. It wouldn't really make sense. For example, for you to build your own logging platform or your own authentication stack or your own content management system, when a managed tool or an API can solve the problem and often solve it better than you could in the first place. But how do you find the right services to integrate? And on top of that, how do you take the, uh, the biggest advantage of these services and stitch them together? And how do you find the right services to integrate? And on top of that, how do you take the, uh, 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 dev.com, you can find all the services that you need to deliver your configuration to any environment and deploy on any cloud. That's Manifold.co slash dev.com. You'll get a coupon code for $10, which you can use to try out any service on the manifold marketplace. That's 10 bucks basically for free. Just for being a developer T listener, head over to manifold.co slash dev.com to get started today. Thanks again to Manifold for sponsoring today's episode of developer T. That is extremely important. That's kind of the whole point. 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 kind of uncover your purpose. One of the real and very important aspects of your purpose is understanding what you like. In some ways, they are kind of 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 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 and 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-gamification. 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 watchers. I 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 time, 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? And I thought, how cool would it be if we could replicate those HUD effects in the Oculus and I could power it? 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 raddest things ever. And so it was something about getting that cool sort of 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? Yeah. Um, and that to me, I get a huge kick out of gorgeous, uh, web animation for whatever reason. I just find that or, 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, there's this kind of factor and I think on this show, uh, maybe there's. You know, I, I try to play out what I think people who are listening to the show are saying in their heads when they hear, uh, they hear me discuss something. And I think one of the things, one of the narratives about this show that may be believed is that I'm extremely serious. Let me, let me kind of break that down. Then your purpose has to be some, you know, altruistic motive and that, uh, 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 are so many things that go into this and your example here is, is a perfect example of this. Uh, the, you watched an, a really cool trailer that somebody used probably after effects or something, and they built this awesome animation and you wanted to make this, this kind of, um, 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, a low sort of, um, purpose pursuit so long as you're loving it. Uh, but I would not want to be the guy who was doing. Uh, PUD animations or heads up display animations, uh, throughout the majority of my working life. Cause if I look back when I'm 80, as per Jeff Bezos is regret minimization framework, um, 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, um, so back to my points, I would not want to be doing that forever, but in the short term, it's a wonderful. Wonderful. 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 lifelong 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. Uh, how old are you? What is the short term? Uh, and can you dual purpose this pursuit to gain mastery? Yeah. Yeah. And I think it's also important to understand that like these things stack, right? It, there's not just a, a single, you know, outcome from this. You mentioned learning, but there's, there's so many other things you make connections along the way, right? Um, you actually, uh, had a chance to learn, you know, it's not just learning about JavaScript. It, maybe it was learning about some, some of the fundamental ideas. Uh, um, and the modeling of animation, um, 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. Um, certainly not if you're unwilling to work for someone else. So I, 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. And WhatsApp, Adobe, Google, um, few YC companies, Y Combinator companies, uh, wanted to work, wanted to hire me. And it was enough of a sort of kick in the butt, like fire under my butt to say, you know what, let me, let me go work for someone. And despite, let me stop this startup I'm pursuing. Let me go and work for someone because I really want to be in the U S I want to be around awesome people. And that led me to the second byproduct, which was. At the time when I was still working for Atomic Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp who are working on major open source projects, writers, all sorts of people. And it was because I looked like I had a something, I had a following, I had 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 developers to come work out of their offices and work on those projects 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 my list of Velocity byproducts, 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, actually, 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've 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 animation, animation engine or whatever your project is, what was the point of building it? You built 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 it lives 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, yo, I'm going to build it. Well, like he wouldn't say yo, first of all, but he'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 Velocity, I said, that took a long, 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 the 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 built that is open source and available to the world. And that that is, that's actually, in a way, it's 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 because, you know, you're not going to be able to do this yourself. You're not going to be able to do this yourself. 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, you know, parallel universe or something. Julian, you decided to make your own animation library, but because you're not trained and because, you know, 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 quote, 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-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 potential, and about our anticipation in the world, they can fall apart. They fall apart because we don't really play it out. And this perspective that we have of ourselves and the work that we do as not very valuable really is often incorrect in one way or the other. Sometimes 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 Clearbed, 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 shared their filters with me. And this simple act of sharing, even if it doesn't end up going gangbusters, you know, blowing up, and jQuery 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 not just being blind to the reality that it is actually a solved problem, then 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 market. Let them market. Using growth and 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 Bellcurve 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 paused 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 pour 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 of this coverage. 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, you know, 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 marketing. And that's what I'm going to talk about today. So I'm going to talk about the 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, you know, putting up flyers. Like 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 dev tea. You get $10 worth of credit for free just for being a Developer Tea listener. And by the way, Manifold is free to use. Go and check it out. Manifold.co slash dev tea. 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 in 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. Manifold.co.