Should You Still Learn to Code? A Convex Engineer's POV

I kind of like rejected AI tools a little bit for like the first year to year and a half of working because I was like I just like need to know how to write good code otherwise like I'm going to be just like clicking accept all the time and you're like [ __ ] like I don't even know if this is good. If I'm asking Chad GBT to make all my decisions for me I'm not building an intuition or like a framework of how to make decisions and I don't have a framework for how I made one decision versus another. I was just like chat GBT told me to do it. So like I think it's like part of the human experience for you to like just try things and some of those things just don't work. as we continue to work in these like code bases that like have like these stacks that are like okay we have a database and we have a backend and we have a front end and we're not using convex like it's going to be kind of tough for these like LMS to reason about constraints between all these different platforms and so I think that for a while we're still going to need to have these like humans in the loop reasoning about this stuff at the end of the day like we as software engineers are accountable for the code that we're writing Jordan so I heard you are a bit of a badass and here at Convex you're an info engineer and you have been with the company for a a couple of years and I would love to talk to you today a bit about what your backstory is. So I went to school at a small college called Harvey Mud. Okay. Um it's based in SoCal, like 45 minutes east of LA. Um it's like 800 kids, so pretty small. Um but yeah, I went to college not knowing that I wanted to work uh in software engineering or CS. Yeah. Um yeah, so the really cool thing about the college is that you actually didn't have to decide your major uh before you started. So it kind of got Yeah. You get the chance to um try out like all the different types of classes. Yeah. So you get to try out like math, physics, computer science, engineering, all that kind of stuff. And it's like specifically in STEM. Um and so yeah, I like got really lucky that my freshman year I had uh a few of my I guess like roommates, they um had interned previously at Facebook. Yeah. I think one of them worked at Facebook, another one had worked at Microsoft. Um and so I kind of got exposed to that pretty early. So, I um had taken like a CS class my freshman year and I was like, "All right, like this seems pretty cool." I like was always somebody who just like really enjoyed solving problems and so um really like fit well with I guess my like natural I guess inclinations and so um yeah, I ended up applying to like a few jobs my freshman year and ended up uh getting an internship uh at Facebook University which is like a small program to get people into computer science and Facebook University was okay. All right. Uh, and so yeah, it's like for first and second year computer science students and I did that. It was like a little 8week program and yeah, it was like really good just to get an intro to like how I guess software engineering works um in the real world cuz like I don't know classes are very different than um like software engineering in practice. Yeah. And so I did that and then did like their official software engineering um internship that like next spring. So, we got sent home my uh I believe it's freshman second semester uh from COVID like for because of CO. Oh, is it 2021 or something? 20 2020 like early 2020. Yeah. You got I think it was halfway through the semester we got sent home and then we I did one semester of uh college from um from home, but then I was like, "All right, like uh why would I pay to go do school when I could get paid and do an internship instead?" So ah so so internships are paid because this is a thing like I wasn't quite aware of like I grew up in England and I wasn't quite aware of like so in England internships are paid but I heard that a lot of internships in America aren't paid. Is that but yours was? So I think um in software engineering specifically um most companies or like all the big companies pay interns um and so I I think that like I don't know I think there's some other internships maybe across like law or like other stuff like that that don't get paid but I think that um I think that yeah most of engineering internships are paid. Absolutely. Yeah. Okay. Okay. So then after the Facebook internship you went back to college and finished college. So I mentioned that I did that in spring. So, I took a semester off from school and that next summer I interned at ASA. Oh, okay. Cool. Um, and I think they had just IPOed around the time that I joined and they were like around a thousand employees. So, it was a very different experience from Facebook. Facebook is how many? Like 30,000? Yeah. Yeah. Something on the order of that. Yeah. And so, um, yeah, I I worked at a sauna. It was really great experience. Um, kind of got to be a lot more hands-on. Got to work on lots of interesting things and got like a lot more ownership. um cuz I had like done the previous internships and plus like there's just like way more I guess like the teams own a lot more service area and so got to kind of just like figure out what the team was working on work on a lot of cool stuff there. I worked on I believe like the pricing and packaging team while I was there. Um so just like a lot of like billing stuff and of course we're dealing with that now convex. Um but yeah got to work on a lot of that like there's all kinds of like migrations and like changing billing providers and all that kind of stuff. M that was the kind of stuff that I worked on while I was there and got to work on um yeah a lot of a lot of cool stuff. Um and then and then yeah I went back to school um for my I believe that was my junior year and then my like last internship before I graduated was at Netflix. Um Oh nice. So so these are all internships then. Okay. Okay cool. Um and so yeah I worked at Netflix. Um very interesting experience because I think I mean the team at Netflix is very experienced. Um, for a while they like didn't hire junior candidates. Like they only hired senior software engineers. I was like their their thing and I was part of like one of the first intern classes to to to work at Facebook. Um, so yeah, I mean lots of very smart, very talented people there, but I think that I mean I think it's important when you're hiring especially like young talent that you have like really good mentorship and I think that they were still I guess like learning how to build that muscle. So it wasn't necessarily the best place I guess to to come in and learn a lot and grow your career and stuff. And so did it feel very elitist there? cuz not is it I wouldn't necessarily say it was elitist. It was more like it was just more that like I think that the mentorship like the culture of mentorship wasn't amazing. Okay. Um in addition to the fact that like they're like a really big corporate company so you just have like lots of people. I mean they pay a lot of money. So like people are really there to just like make a lot of money and so they're they're a lot less motivated to kind of like try out new things. It's like how do I just like make sure that I don't lose my job. Exactly. And so it's a lot more of that vibe. And so I guess like through all of those experiences I kind of got pulled a lot more towards startups and like had worked at ASA which obviously was still quite big at a thousand employees but like still a little bit on the smaller side as far as um just like big tech companies go. Um and so I like was like okay like I don't think I can do this big company thing anymore and decided to um to to join a startup and and through that process I like I found Convex and yeah I was really excited about the team and so this is postgraduation. Yeah. Okay. All right. And so you're in ComX. You found Convex and you like this was what two years ago now? Oh yeah. Two and a half years ago. Two and a half years ago. Yeah. And you interviewed here and were a good fit and joined. And what was the first your first experience like in the first week? Was it welcoming or was it challenging? Do we get just thrown straight into it and just good luck? Yeah. So I I think it's kind of interesting because I as I like mentioned I never I mean ConX was yeah like around 20 people when I joined. um you have a very different experience joining a startup than you do joining a big company. Big company it's like we know what you're going to be doing for every day up until you're like 90 days or like whatever. Yeah. Yeah. You're like this is who your mentor buddy's going to be. This is who your like manager and all this kind of stuff and these are the projects you're going to work on. Whereas I felt like when I started at Convex I like it's kind of like okay like we're starting and like you have like your first project and then it's like okay like kind of just like figure it out. Yeah. you're right into it, which is I guess a little bit stressful cuz if you're not used to that, then it can be like a lot of like I just like don't know what the hell is going on. Um, but I think that it was also like a very good learning experience for me cuz cuz you're like getting to work on the important stuff and there's no room for anybody to work on like some like little [ __ ] project or something like that. Um, it's like that small cog in in a small wheel versus a small cog in a big wheel type of thing. Yeah. And so I think that I mean the really great thing was just like I mean I think the team is all really amazing about just like answering questions and being like open to I guess yeah like teaching. And so I think that that I guess like that culture was like extremely helpful cuz I think like even though I was like thrown into things I think the entire team was just like willing to to to help like mentor me and help um help like grow me as I I was like onboarding. I think that that like even even if you don't necessarily have like the infrastructure or like the um I guess like yeah the infrastructure of um of like mentoring people and being like oh yeah like this is how like this is how often we're going to check in like do all this stuff as long as the team's like really committed to making sure they're like answering questions and like really excited about um onboarding new people and I think it ends up being a really good experience cuz I just like felt like um yeah everybody was like committed to doing that. So what was the first thing you worked on while you were at Convex? So I I remember I did like some small tart smart some small starter tasks um in the dashboard. Yeah. Um and then I think yeah the and then after that um the first thing I worked on was postal service. So postal service is the only service in convex which is built on convex. Um and so postal service postal service like basically handles sending out emails to our customers. Um and so these are emails about like at first it was like sending emails to like uh to free users when they're like approaching the limit of their um of their plans. And so like when they're approaching it when they're going over and then that like has expanded to also like we implemented spending limits. So when customers are getting like close to their spending limits um and then yeah just kind of like managing like all the customer I guess like life cycle stuff like all the like sending out emails and like figuring out okay like this is how much usage you have. this is like when we send out these emails. Um, and so yeah, we um basically like helped build that um when I first joined. And did that give you some good experience on like what it's like being a user of Convex as well as obviously getting your hands dirty and some infrastructure kind of stuff in Convex as well? Yeah, I think I think it was a really good project to really just like learn a lot more about building on climax because I think that um I guess like at times it's a little bit hard to know I guess exactly how our customers feel and so it was like nice to kind of like dive in and be like okay like these are the things that are great about it and these are the things that are like not so great about it and especially like at that time we were still making quite a few tweaks to like the core platform and so um yeah it was really great to just kind of like get to learn that and then after that ended up diving into some more like kind of infra type projects. Yeah, before we get there, because one of the interesting things about, you know, so I've only been at Convex a year now, and we've had one build on Convex day, and it's interesting because I guess it's one of those sort of like continual battles where your head's down building some low-level service or something and you don't actually get to actually experience it as an actual developer. You don't get to dog food. Yeah. So, I mean, do you find do you find that like internally mentally yourself like, "Oh [ __ ] I need to build more convex projects to be able to feel what other users are feeling or you're just like you you're separated from those kind of things these days." I think that in the beginning, I think it was really important those these like build on convex days just because like we just weren't really sure about what the right thing was to do. Um because yeah, I mean we at the beginning we were really just like marketing a lot towards like hobby developers and stuff like that and so you really just like need to get that feedback and it's and you can get a lot closer to what your customers are feeling in one day but I feel like now we just have customers that are a lot bigger and so it's a lot harder to like in one day just kind of say hey like this is how our customers feel building on convex and a lot of times I think the best feedback that we have like comes from our biggest customers like running into weird pain points or being like hey it would be really great if we could do this thing and then kind of like figuring out like okay like how and I I guess like understand their use case and understand why they want these things and I feel like a lot of the the like best I guess like now that's like where a lot of our like really good ideas come from cuz it's just hard for us to to use convex at the scale that our customers are using it those edge cases and stuff. Yeah. Yeah. It's cuz some of the very interesting stuff that's coming up is based upon like pain points from customers that are much larger. So um I think what I kind of like touch on now is like some of the other bigger projects that you worked on. So I think you mentioned you did some conductor stuff next or Yeah. So would you like to explain what conductor is? Yeah. So so we can talk about um we can talk about conductor but first I guess I can talk about I guess like how I ended up getting into like working on info stuff cuz I I guess like conductor was a little bit more recent around like the beginning of this year. Okay. Um, and so, um, yeah, like one of the I would say like first like really exciting in products I got to work on at Convex was, um, essentially we have this like durable I guess like transaction log at Convex, like this document log. It basically keeps track of all the like every single update that you make uh, in your convex tables. And so when I like how this works essentially is that like whenever you update, add delete this like all ends up just being like a new row in the database instead of instead of like instead of editing like a previous document. Um and so we like as you can imagine like over time we like when you when you get bigger and bigger customers this log basically grows unbounded because if you have high like update load like you might have these basically like inactive rows that are no longer visible from a current time stamp. Um, so one of the first, I guess, like really exciting projects I got to work on was basically like working on cleaning up this um this document log. So like all inactive documents uh were no longer that were no longer visible got cleaned up in that log. And that was like a really um exciting project cuz I got I guess like yeah I mean the team had trusted me to basically like go in on this project and I mean of course if you delete the wrong things then you're deleting customer data, right? And so it was really exciting to kind of like go in and like really learn the like internals of of convex and get to write like some SQL queries deep in our deep in our stack. And basically like I guess like how the algorithm works is that like you basically see like hey is this document visible like we want to we want to preserve like some like window in which we can like recreate like that state of the database. For example, like let's just say like our retention window is like 3 days. And that would mean that we want to like be able to create that database state from like any time within those 3 days. But like if the document is like not visible from any time in those 3 days, then we want to like delete it because it doesn't matter for um our use case. And so basically like built an algorithm that um that essentially like calculates that and like deletes all uh documents that are that are not visible. And that was really exciting cuz I mean yeah we got to re reduce our like database um storage by over 50% with that project and it was like yeah it was I mean yeah we couldn't I guess we couldn't even imagine like having that architecture today cuz like our customers like have really high write and update loads and so yeah exactly and so and so we um yeah we had to work on got to work on that project that was really exciting. Conductor is essentially are like multi-tenant I guess service that can host multiple convex uh deployments on like the same machine. So when I first joined um we basically had um each convex project or each convex deployment would map to a single machine. Um but this like wasn't very scalable because we can't share resources across projects because like some projects may be super active but other projects are um like dormant and don't have like a ton of requests coming to them. And so we wanted to basically find a way or like update our architecture in order to support like running multiple customers deployments on like the same physical machine because it allows us to basically like amortize the cost of running all these different projects across like yeah like just like a few different machines and like being able to like load balance across them. Um and so just like makes our I guess like utilization or like our our um I guess like our infra utilization like a lot higher and not and like being able to share CPU and memory and stuff. And so yeah, we basically worked on this project and I guess like what really enabled this is we had like two really big projects that like happened before this that I wasn't a part of. Um but like one of them was basically like we have this thing called funr run and I believe we have uh I believe Emma wrote an article about this um online but essentially it's like our function execution service. So it's like the thing that executes your like like runs the um it runs JavaScript and basically executes your queries, mutations, actions and then like you get the like reads and writes from that transaction that like gets sent back to like your I guess like convex in like deployment and then like yeah we have like the committer that basically processes all these like reads and writes and like applies stuff to the database. Um, and so we like we scaled that out. And then we also have this like basically like I guess sync service. And this is a thing that I guess like handles subscriptions and like basically decides uh which I guess like conductor or I guess which um I guess before it was like just a single machine. So we called that like backend like but it would determine like which backend we would send the request to. Once we like built that I guess like those two services out, it allowed us to basically like unify those um these projects into like a single or like into like have unify these projects into like a single I guess machine because then like usher can just like when we get the request for like a single instance we can say hey like which uh like which conductor is this deployment on and then you can like route it to that um to that conductor. So so you mentioned Usher in there. So what's Usher? So Usher is like a sync service. So basically like it handles like we have websockets in convex and so like and so basically like handles um it handles uh like the the websocket. So basically like the the websocket itself is like connected to usher. Yes. But then like it determines like basically which request to send to the um to the machine. So like it has like RPCs that are sent to uh the machines like in order to like update subscriptions or or like or like rerun a query query or run a mutation. So is it like AWS CloudFront? Is it like the proxy in front? It terminates the websocket or or and then it forwards it on to the correct conductor. Is that so I guess like it it's like the the websocket itself is like well I guess I actually don't know the exact terminology cuz I'm like all right like terminating the websocket means that it that like the websocket is not like passed through to the conductor like it I guess like yeah I guess you could say like terminates the websocket at the at usher but then like it basically gets the information that it needs from the conductor. Okay. using different RPCs. But like as far as like managing the subscriptions and stuff like all that stuff is like done in Usher and then Usher basically just says hey like if I want to subscribe to a query do I want to um do I want to update a token? Do I want to do all this kind of stuff? Um then yeah that's what Usher talks to backend for. I guess the natural question for me would be is why not Kubernetes? Yeah. Um or I guess this is at like a different layer. I think Kubernetes is like an orchestration platform and I believe instead of Kubernetes we use Nomad on Nomad. Yeah. So I think that like yeah I don't know I I wasn't part of the decision I guess to make to decide to use Nomad over um Kubernetes but I guess like yeah we we still do use like a container orchestration platform in order to to run all of our okay so hardware. Yeah. So does it the so nomad does the balancing of between physical machines like the compute between or I thought that was what conductor does. So I guess like there's two different things like conductor is just like I guess like the binary or like whatever that we run on the machines. Okay. But like we do have like a orchestr like we do have like a like a orchestrator like we use nomad to basically like place different conductors on different machines and like that kind of stuff. I see. So the unit of execution is conductor. I see. Okay. All right. Cool. Um, in addition to working on a lot of this deep diving infrastructury kind of stuff, you've also done more like obviously 2025 is the year of AI and you've done a bunch of stuff on Chef which was a I don't know what do we call it like a proof of concept like vibe coding platform that. Yeah. Yeah. We were just really excited about I guess like having AI work well with Convex and we knew that it would work well because um it just like has abstractions that developers love and we we know like yeah having to glue together all these different types of platforms for developers has been um a really complex problem and AI is like no different. It also has to do all these things if it wants to build an app and so we're like AI would be work well with convex. It doesn't have to do all these things and so we wanted to really just show the world how well AI works with convex and so we decided to build chuff. Yeah. Yeah. Yeah. Yeah. Nice. And what was that like building that cuz I heard that we built it like very very quickly. Yeah. So I it was it was stressful but like in a good way. I think like we we were like we want to do this thing and we didn't really have like a blueprint of like how we should do it and so um we really just had to like kind of sit in rooms and like figure out okay like what is architecturally want to build and like what is the one that we can build fast and then like you just have like all these variables um trade-offs and stuff. Yeah. Exactly. And so um yeah there's like a lot of conversations. We initially came with one architecture where we were like [ __ ] like this might be too complex to build in whatever time frame that we had. So we had to move to something a little bit simpler made us take like a few trade-offs and so um yeah but we ended up building it and I like the exciting part about building chef was that we had like done some stuff that was I guess like pretty exciting at the time which is like we had O built in by default and we had and I guess like the type checking of convex which is like already feature of convex which is like so exciting because you like the AI basically has like a good heristic for if it's like correct or not. which I think was like so challenging cuz like when you write like SQL or or like some of this other stuff, it's just like really hard to know like if this thing is like doing the thing that you expect it to or if it even like would work if you were to like run it. Yeah. Um and so basically like yeah, I was like really excited to basically say like hey like if we type check um if we type check convex and like we're pretty confident that like it will work pretty close to how we expect it to. Yeah. So that was I guess like the really I guess like novel insight and it's really kind of like we've kind of been able to showcase that over time and what developers have realized as as they've adopted these um AI tools that like convex just works so well because like you just have like a lot higher confidence that the stuff is like doing the things that you expect it to and like can work autonomously. And even like working with I guess like AI like in my day-to-day job it's like so it's so helpful when like it can run tests or like understand if its code is correct or not. um because it just like can get that feedback and LM are really good when they have good clear feedback um about like the tasks that they're working on and yeah because TypeScript effectively is tests for JavaScript like runtime well sorry not runtime a compile time type checking and various other things and because convex is type safe from front end to back end it just catches so many more things that the AI could mistake hallucinate or whatever um yeah and I guess as you mentioned it like your day-to-day coding like you do you do mainly TypeScript code or Rust or what's your language does your so I think it varies a lot um I've probably written a little bit more Rust than I've written TypeScript at this point but I've written a lot of both um but yeah I mean I think I think it's very interesting because I think that like I think that LMS are a lot better at or like it's a lot faster for them to write TypeScript cuz like I don't know like you don't you're not spending so much time at compiling and stuff and the rest compil Yeah. And so with like writing Rust's a little bit tougher and like what I end up using most of the time is just like autocomplete or something and then and like most of the time just like writing code. But I think that like in general the um the things that I find I guess like AI most useful for in my job is like stuff that like I know how to do it pretty well and like I spent I guess like I kind of like rejected AI tools a little bit for like the first like year to year and a half of working cuz I was like I just like need to know how to write good code otherwise like otherwise I just like am going to be just like clicking accept all the time. like [ __ ] like I don't even know if this is good. Um so I really wanted to like Yeah. And so um yeah I think like I don't know at Convex and I'm sure in a lot of places like you have to have high accountability for the code that you write and you can't say oh [ __ ] like uh cloud code wrote like yeah exactly. Um and so it was just like really important for me to kind of build that skill of like learning how to write good code. But then once I did that it like became a lot easier to like kind of delegate tasks are like pretty easy or like I guess like easy or like clear slash like straightforward. um to like these AI coding tools because it means that like hey like I know how I would do it and then I can look at it to see if it like looks about right or not and like make a few changes here and there and then just like submit it and then yeah and so I feel like and that's the cases those are the case that like I have made like um I guess like that those are the places that AI has like been the most successful for for me like using like in my day-to-day um job but at risk of philosophizing too much where do you think it's going where do you think engineering is going to in the future, are we going to even need to look at the Rust code, the TypeScript code? Um, so I think that it's very interesting because I think that there is like no I guess like right way to code. Um, and so it's like kind of tough because I think that like we you still I guess need to have like a little bit of probably what we consider like taste like like if you write con code at Convex versus like a bunch of other companies that like code looks different and they care about different things. Um, and so I think it's like important that um that yeah, like you still have like some human in the loop. And I think a lot of like I think that over time these like OM will get better at I guess like mimicking human patterns. I think that's just like you just need to have somebody I guess like orchestrating or understanding the code slash like reading it because like there are I think that for a long time there will be there will be like certain types of problems and like constraints and stuff that like the LMS just like won't be able to understand especially like as we continue to work in these like code bases that like have like these stacks that are like okay we have a database and we have a backend and we have a front end and we're not using convex. um like it's going to be kind of tough for these like alums to reason about constraints between all these different platforms. And so I think that for a while we're still going to need to have these like humans in the loop reasoning about this stuff because at the end of the day like we as software engineers are accountable for the code that we're writing. And so I I I like have not found any tools like I haven't found a way yet for I guess LM like have accountability for the code and like go ahead and like fix it and all this kind of stuff. And I mean obviously there's like some exciting stuff around like observability and thinking about like how LMS can like help like automatically make fixes to your codebase and all this kind of stuff, but I just think that I just haven't seen anything that's been like promising enough yet to make me think that uh yeah, we're not going to need that like kind of like problem solving like kind of like uh yeah like that problem solving I guess like um like mindset like to engineering and I haven't kind of seen that um kind of like come out in any LM tools yet. I guess another way of phrasing it is like if there's a high school kid maybe coming out of high school, going to go to university soon, what would you say to them? Would you say you still need to learn to code or would you say it's more important to learn how to prompt better for example? I think that I mean I think that at its core I think software engineering is like problem solving. And so I think that you should just like learn how to use tools well and like you do need to have those fundamentals of coding. I think it's still very important because it like helps you build intuition for like how software works. Like I think that even though like yeah even though you might have better tools like you still need to understand like how like you you you still are a better engineer if you understand how the code works, right? And so so you want to have like good intuition for like object-oriented programming or like just like how how databases work and like all this kind of stuff because it just like will help you think about things in a better way. And so I mean I think that this like high level thought process is not something that's going to go away but like yes our tools might change. Um but like yeah you still have to figure out how to how to like how to apply them and know when to use what and like all that kind of stuff. So you think it's still important to learn certain patterns like you mentioned object orientated there. Is it in still important in 2027 8 that a software developer needs to understand the list of substitution principle for example or needs to understand the difference between functional code and object-oriented code is it still important that they need to know the difference between Rust syntax and typescript syntax when they don't even look at the code anymore really is that do you think that's going to be the case are we ever going to get to that point or is it going to be like my son's five years old sure and I want to teach him programming soon so I'm probably gonna teach from scratch, you know, which is a visual drag and drop type of thing. And it will give him the basics understanding of like variables, loops, and things like that. Does he need to go any further than that? Does he need to learn another language? Does or does he now understand everything that he needs to know from a problem solving perspective? What do you think? I mean, I think I mean, I guess like it remains to be seen. I I wish I could predict the future because I have Sorry, I'm asking you a very a very difficult thing. But then but but then I guess Yeah. I mean, I don't know. But I just like seem to think that people who like know how to write code generally write better software. Like I think like I think that I mean I think that over time I think it'll be kind of interesting cuz I think that like like engineers will have like a lot of their jobs. I guess like the jobs will change, right? Like it will matter like maybe like you have like more I guess like product sense and stuff cuz like maybe you be spending like a little bit more time like doing that kind of stuff. But I still think that like if over time you want to build like really durable software, then it's like important that you still have those like fundamentals and like know how to do things in like a reasonable way and know how to reason through trade-offs and all that kind of stuff. And you just sometimes might not get that depth if you're just like doing something at like a scratch level and like haven't built these I guess like more complex systems. I don't know how much like just cruise control vibe coding you've done yet, but I've been doing it a fair bit and I got to admit I do find myself getting dumber already. Like this is just 2025. Like when I'm doing something and I'm not looking at the code, I do feel myself like going, "Hang on a second." Yeah. I've got no idea what's going on here and I feel like parts of my brain are shutting down. Yeah. Absolutely. So I I worry about that. Like I worry about what's kids of the future going to be like, you know, when the AI can basically do like all the engineering for them. Yeah. Like are we going to end up with a bunch of like old cobalt programmers like like who are the only ones who know actually how code works? Yeah. I mean I I mean I think the biggest thing is like you want to make sure that you're like building intuition, right? Because if you're never making any decisions and you don't build any intuition for like how to do things. I think this like applies to AI like not even just in like software engineering like in general like if I'm asking chat GBT to make all my decisions for me. I'm not building an intuition or like a framework of how to make decisions and I don't know like how it felt to I don't know I don't have a framework for how I made one decision versus another. I was just like chat GBT told me to do it and so like I don't I mean, I think it's like part of the human experience for you to like just try things and some of those things just don't work. And so like it's but even like when they don't work, you actually probably learn more than it does if it does work. And so and so you just like you want to have like some type of intuition. And so like this is why I guess like for like all the hard I guess like interesting stuff. It's like kind of fun to I guess like do that do it myself. And I mean occasionally like I'll use AI to try to like I guess like build a proof of concept just to kind of like see how I would potentially do it. And I'm like, "All right, [ __ ] I just want to like write all the code myself and kind of like have that experience cuz it's like, okay, I'm thinking through some of these like harder problems or whatever and like kind of making sure I'm still flexing that muscle of trying those harder things." And that's why I say like for the stuff that's like a lot easier. It's like really easy for me to just kind of delegate that to to AI because it's like I know how to do it and like it's not really making me any better by doing it. And so it's just like I can just do that and like it's I mean it's something that needs to be done. So and then I can focus like more of my energy on like the more important more complex things. Yeah. Yeah. And I guess closing the loop as well, this is one of the big reasons why you joined Convex in the first place. So you can stretch your wings, so you can do more interesting things rather than being told what to do and just doing it mindlessly. Yeah. So the other thing that you've worked on at Convex, the big thing is components. Um components are I would say like one of the kind of like fundamental parts of Convex that is pretty unique. Um what parts of components have you worked on while while at Convex? Yeah. So we we released components I want to I don't know how long it's been. It's probably one year November 2024. Okay. Yeah. So it's been about a year. Um and we released it and was really exciting because it's basically these like many backends that you can put in your convex back end. It has this like sandbox data sandbox schema sandbox um sandbox function execution. Um, and so it's really powerful because basically allows you to like install like basically new functionalities that you wouldn't previously I guess like have access to or that teams like spent a lot of expertise building just like with a single npm command. Um, and so um, yeah, we like we built components but we like all the original components were built by the Comvex team. Um, and the like authoring experience was like not great because we kind of just were really excited to build this but then like didn't kind of like we I mean there's so many exciting things happening at ComX that we just kind of got pulled into some other things. Um, yeah. Yeah. And so we didn't like end up closing the loop on making the authoring experience really nice for developers. And so um we had like had a bunch of things that were on our list of like okay like we really love to do this before we like allow any companies to um to like make their own commerce components. And so we um yeah, over the course of the last few months, we basically like spent some time basically basically like um cleaning up the API for like exposing like the internals of components to like um the like higher level application that you have. Um and so we we did that. We added a new API. Um and then we also um like made it really easy to kind of like develop components like a a specialized command just like codegen for a specific component. And so yeah, and then we like updated all our templates and kind of like made really nice docs and kind of like went through the whole process of figuring out, okay, like when should you be using components versus like authoring components and kind of thinking through all those things. And so um yeah, been doing that over the past few months and then I believe last week or the week before that we released um the components authoring kind of like guide experience. Um and so yeah, it was really exciting to kind of like go through that because we we know that components are going to be like a really um big part of Convex's future. um just like it's it's going to be really exciting for um basically allowing people to split up their code bases um but also um really exciting for like allowing other companies to maintain integrations with Convex like I think yeah we we built a Stripe component we have um like a a work OS component we have all these kinds of different types of components and so um it'll be like really exciting to see like as our convex like developer base grows and and people want to like have their products work well with Convex um then yeah they're going to be like really excited to maintain these components and we're going to have like such a full-fledged like ecosystem of um of of things that and things and functionalities that people can just like drag and drop into their into their um into their convex deployment. And so um yeah, it's like it's really just like exciting I guess for the future of convex cuz I think like I mean like I guess the premise of Convex is just making software development like easier for everybody. Yeah. Yeah. Um, and so it's like you're getting like all these functionalities basically like out of the box and people have already thought really hard about these problems and how to solve them in the right way. And so components authoring was just like the natural next step in that um in that process. Yeah. Well, you say natural next step. I don't know whether I would have thought of it but it's it's Yeah. Thank you Jordan for talking to me today. Is there anything else I should mention do you think? Um, anything else? Yeah, I don't know. I think I think that's it. Yeah, it's been great chatting with you. All right. Brilliant. Thank you very much. All right. Awesome. Cheers. Cheers.