Kent C. Dodds (00:01.164)
Hey everybody, it's Kent to see Dods again and I'm joined by my friend Julius. How are you doing, Julius?

Julius (00:06.905)
I'm good. How are you?

Kent C. Dodds (00:08.92)
Super, super, very excited to chat with you about product engineering and how we can develop the right skills to know the right thing to build, not just building the thing right. That still matters, but as models and and harnesses continue to improve, being able to know what direction to point that agent to just becomes so much more important. And so that's why we're talking about this.

Julius, why don't we get a little intro to you? What do you work on? What products have you built in the past? And yeah, tell us all about yourself.

Julius (00:42.612)
Right. So currently we're mostly building this new agent orchestrator T3 code. And before then T3 chats and then so like been doing like AI chat stuff now for a little over a year. And before then I was actually like still in university back in Sweden.

working like part-time with Theo and Mark at their previous products, like upload things. So we built a file upload service and yeah. So I've been doing some product development for past like two and a half years or so. But now recently I've gotten more and more into AI and what that looks like.

Kent C. Dodds (01:29.838)
Yeah, like many of us, for sure. Yeah, think from what I can tell, the T3 ecosystem cares very much about things being really fast and that user experience just being excellent. That seems to be the, at least whenever I'm hearing Theo talk about it, that's like the key differentiator.

Julius (01:31.892)
Yeah.

Kent C. Dodds (01:57.184)
is that that user experience is so good and it's so fast. What's your read on that? Is that kind of a priority for you guys over there?

Julius (02:01.875)
Yeah.

Julius (02:05.428)
Yeah. So like when they started t3 chat, that's what like, um, their like core, core principles was that like every ad chat at the time was very slow and very like, not very user friendly. So they built t3 chat and don't solve that. And then I jumped on that and started working on that. But then like in January, I got like super peeled on the like agent orchestrators like conductor. Uh, and it was like very productive and just loved the workflow.

But it quickly just like got very slow. And like when you're like running 10 agents in parallel, because it's very easy to build stuff now and you just gotta plan out to work. And like my MacBook Air that I had at the time was just like going crazy. And it ran out of memory because the agents was taking too much resources.

Kent C. Dodds (02:57.134)
no.

Julius (03:03.636)
And then the Codex app came out and it was like kind of the same thing. It's like a very good built app, but it takes system resources like nothing else. So yeah, like that's the elevator pitch by T3 code is like, we want to do this right in the sense that you can run it on like any machine and it shouldn't like make your fans explode and like, just be a good user experience and a fast way to interact with these agents.

Kent C. Dodds (03:08.366)
Hmm.

Kent C. Dodds (03:14.702)
Yeah.

Kent C. Dodds (03:34.178)
Yeah, okay, cool. the one question I have about that is that, so T3 code is not a harness. I actually just saw a video from Theo calling it a harness harness, which I think makes a lot of sense. So you can choose to have it run cloud code and codecs and cursor and all these different other harnesses. how do you, like maybe I'm misunderstanding where the bottlenecks came from. Maybe it was just the app.

Julius (03:47.54)
Ha

Kent C. Dodds (04:03.342)
So is the underlying actual harness not the slow part for these different apps? It's like cloud code, the app itself, that's a two-way, right? So I'm not sure. And then codecs, like that's an app for sure. So is the app part the part that is slow or how do you make it fast?

Julius (04:23.73)
So like, depends, like the agents is always going to be slower than the app, of course, but.

At like, least at the start of the Codex app era, like opening a thread took like up to a second for me. And when you're navigating around this app for the entire day, that like time, yeah, it adds up and it's just like, that's not what I want to do. So what we've put a lot of folks in, like, it's just making the app very snappy so you can like navigate around it, like supervising your agents.

Kent C. Dodds (04:38.55)
Yeesh.

Kent C. Dodds (04:43.054)
It's painful.

Julius (05:00.498)
You don't have to look at loading states all day. But yeah, of course, the actual agent run will still be slow. We're not controlling that. But yeah, just putting in a lot of focus and making everything very snappy is currently where I'm at.

Kent C. Dodds (05:19.852)
Yeah, yeah, that that makes sense. And all the demos that I've seen of it, it's super snappy, makes a lot of sense. You mentioned earlier that back in January, you got kind of orchestrator pilled and and for a lot of people listening, January 2026 was like a really huge shift, which I actually I think is kind of interesting because GPT 5.2 I think came out in December. And if I remember right, Opus came out in November. So it took a little while for

for people to kind of get it because everybody references January or like, yeah, December, January kind of timeframe. So I actually think that a lot of that is just the harnesses taking advantage of these models in the best way possible was kind of where the unlock happened. You need the model first, of course, but then a really good harness for it. What was your experience like at that time? like, how did that change the way that you think about building software?

Julius (06:21.428)
So I think the biggest shift has been like the parallelism that previously I was like working in cursor, having like one agent at a time looking at the code that it was writing. Cause it was very hard to, you know, do multiple stuff in parallel because none of the apps really supported that workflow. In curse you can only, you could only have like one project open at a time and then.

Kent C. Dodds (06:38.894)
Hmm.

Kent C. Dodds (06:48.216)
Hmm.

Julius (06:48.69)
Yeah, you could have like multiple agents, but then they would like run into each other. no, like when I came back from the holiday breaks in January, Theo like asked me to try these agents more, like go more all in. I don't, I had already like started going deeper and deeper into it, but it was still like one agent that at the time was running. But I'd say like, yeah, maybe like December, November.

Since like Opus came out, more and more code was generated by AI, but it was still this like sequential workflow. when now that the orchestrators has like exploded, everyone seems to be doing an orchestrator these days. That works just now. Yes. It's just so much easier to have stuff being built in parallel and you can like implement 10 features in parallel and the bottleneck becomes like a...

Kent C. Dodds (07:31.296)
Yeah, you're self-included.

Julius (07:45.522)
deciding whether this feature is worth having or not. Be like, what are the long-term consequences? Because yes, you can push out 10 features in an hour if you want, but will that code be maintainable long-term? Probably not. Will that feature like step on future product development, product decisions like toes? Maybe. So like, yeah, you just got to be very good at like filtering out the noise.

Kent C. Dodds (07:48.397)
Mm-hmm.

Julius (08:15.858)
because building is not the bottleneck anymore.

Kent C. Dodds (08:18.348)
Yeah, yeah, precisely. And that's exactly the conclusion I came to around that time period too. It's like, shoot. Like traditionally my job has been accelerating experienced engineers acquisition of knowledge and experience in a particular area that they didn't have an experience in before. Like, okay, you know how to develop software, but you don't know React yet. Let me teach you React. You don't know how to test. Let me teach you how to test. You don't know full stack. Let me teach you that. But see now,

I do think that those skills make you more productive when working with agents. I don't think that those skills just like disappear, but the pain of not having those skills is felt a lot less. It just doesn't hurt as much to not have those skills. And so obviously a very impactful part of my business, but I'm not crying about it because I like ultimately, aside from of course feeding my family, my goal is to just help people build quality software.

and I'm not needed in that realm anymore. But what you said, I think speaks exactly to the direction everything is going. Now it is how to decide whether a feature is worth having or what the long-term consequences are or whether you're gonna step on product development. think that is really the skill that software engineers need to have now. And so from your experience, how do you decide whether a...

feature is worth having or the long-term consequences of it.

Julius (09:48.35)
So like I've been thinking a lot about that like this past two weeks pretty much like we have a lot of people forking T3 code now and adding a bunch of cool features and asking, when is this gonna come to like the core product? And it's pretty much points down to like, it's very hard to, it's very easy to put that feature into existence in your own personal software. And like, that's great. Like everyone can fork and make their own features.

Kent C. Dodds (10:02.221)
Ha.

Julius (10:17.3)
to suit their own workflows. But when we're building the core part that people can build on top of, we gotta be a bit more careful with what we add. So I've seen cool features adding stuff to the sidebar, but you can't combine them because then they would look ugly because it would be way too much stuff there. So on their own, they're super cool, then, yeah, it doesn't scale up, I would say.

Kent C. Dodds (10:39.182)
Yeah.

Kent C. Dodds (10:46.094)
Hmm.

Julius (10:46.948)
And like when it comes to making the decision, that's sometimes just got to come down to is this extensible? So one example I have there can be like people adding browsers to teacher code or people adding like split paints. You can split like having multiple threads open side by side. And each PR that I see adding that is doing it in its own like isolated way. And so I'm going to think about like, okay.

How can we generalize this? So like I, in my head, I can see like just needing to make the whole layout system better and not just adding the feature to add to chat side by side. And like by adding the better layout system, I can like accommodate for everyone's needs in the future by then the folks can just like plug into that. So I think like that's where my head is mostly at now.

Kent C. Dodds (11:27.047)
Mm-hmm.

Julius (11:44.35)
Just like making a good foundation that you can build on top of and not just think one feature at a time.

Kent C. Dodds (11:52.94)
Yeah, that is such a useful and valid skill for people to develop to not just take every single user request and say, okay, great. Let me just fire off an agent to go do that. But to see the whole product as a full picture and say, we can like knock out all of these requests by just having a better layout system. And now like you can lay out the chat here with a browser.

there too, and you can use that for all sorts of things rather than just having specifically feature two chats open next side by side, for example. Yeah, that makes sense.

So you also mentioned like how to know or knowing whether a particular feature that you're adding is going to step on future product development. I wonder like, do you ever run into situations where you feel a lot of pressure to ship something that you know is maybe not the right direction to go in long-term?

and it's going to slow you down in other areas, but is the right decision to go for now? Like, well, we know that the models are getting better, or we know that like this, especially since you're a harness for harnesses, we know that Cursor is working on this, but they're not done with that yet. So we've got to ship something, you know, to make up for that failing or whatever.

Julius (13:21.716)
Sometimes, I saw that they were, or like, before we even started T3 Code, was like, yeah, Cursor is going to make their own version of this. And like, it's probably going to be good enough for me, but we didn't want to wait for that. So we did it. And now they have Cursor Glass. And from my experience, it's like, not the best app.

Kent C. Dodds (13:33.582)
Mm.

Julius (13:49.842)
Like I love the cursor harness. I love the cursor like cursor specific features, but whenever I try the app, it crashes my computer. So,

Kent C. Dodds (13:50.595)
Mm.

Kent C. Dodds (13:58.598)
no, yeah, I guess maybe that's like a power user or like a hidden skill is just using lower powered machines. Because it helps you like instead of a beefy MacBook and get a MacBook Air and.

Julius (14:16.75)
Now I'm on a beefy MacBook Pro, so I shouldn't boil down. I got this because my memory was running out when I had like five plots running at the same time. yeah, like, yeah, I feel that pressure. Like when you look at Twitter and seeing all these clones or clones and forks adding stuff, I feel like, yeah, I should add this. I should add this and be more proactive in that sense.

Then you gotta like take a step back and see like.

Julius (14:52.19)
I don't think it really matters. We weren't the first agent harness or orchestrator and we're not going to be the last. like the feature we add right now, I just like want to be quality. And I'm like sort of back into reading more of the code for a while there. was like, yeah, just by goodness and type thing to existence. If it feels good to use, it's good enough to ship.

Kent C. Dodds (14:55.093)
it like slow down

Julius (15:19.508)
And like those, those decisions are sort of catching up to me now. I'm like wanting to add new, new stuff and just like looking into the mess that Codex has created. So now I, I'm sort of like taking, taking a bit slower and just making sure it's, it's good before shipping it and not necessarily being first.

Kent C. Dodds (15:31.689)
Hahaha

Kent C. Dodds (15:45.75)
Yeah, yeah, I think that's a recurring theme in this podcast series is to slow down. We've had some people who are much more on like I read every line of code. Other people are kind of in the middle and a little bit of I think it largely depends on the app that you're working on. Like if you are the only user, then just five code that thing like you know who cares? But if you're building something that you've got.

Julius (16:10.398)
Yeah. Yep.

Kent C. Dodds (16:15.595)
users who are paying or many users or like maybe it's a library lots of people use then being a little bit more intentional is probably a call.

Julius (16:27.198)
Yeah, think it was like, depends on how long you intend that app to like exist and be useful for. Like, cause you can like, you can one shot amazing stuff into existence now. And if you just want an app for one specific thing for your personal needs, that. Like by all means the agents will, for the more than capable to, to like do that in a few prompts.

Kent C. Dodds (16:54.536)
Mm. Mm.

Julius (16:55.508)
But if you're like gonna keep working on this in a year, maybe be a bit more deliberate, like review the code a bit to like know that it's writing the biggest mess. Because like maintainability has always been a concern, think, like at least for me. And I think the like speed that the maintainability of software is going.

down rapidly now with these pipe coded apps. So if you want the software to exist in four months, five months, maybe take a peek under the hood at least and see like it's not backing into a corner for future decisions.

Kent C. Dodds (17:39.278)
Yeah, yeah.

Kent C. Dodds (17:45.492)
That actually is really like that phrase you just said to avoid backing into the corner for future decisions. I think that's actually what the value that our historical engineering skills still offers. If you are a totally brand new software developer, you've never coded a day in your life and you're just vibe coding all the time.

You don't know when the agent is making decisions that are gonna put you in a corner that will make it harder for you to implement future features or whatever. Like it's making an infrastructure decision that's gonna make it really hard to migrate when things actually matter and different things like that. yeah, experienced software developers are still really valuable because of the battle scars that we have from making bad decisions in the past.

Julius (18:37.618)
I would like to think so at least.

Kent C. Dodds (18:39.726)
Yeah, it makes me feel better, yeah. All this time was not wasted. I'm curious when you're making these product decisions, how are you determining the vision for the product, the direction you're going? I don't think you're working solo on this and you've got obviously lots of open source contributions. Do you have, maybe a steering committee is not the right word, but a team?

and that you're using to make these product decisions and how do you determine that? Or is it just kind of like open the PR and then we'll look at it and decide like how intentional is the vision?

Julius (19:22.868)
I think that the long-term vision is mostly set by me and Theo discussing stuff in our office. And then he's a very busy man. it's basically me. The engineering force is basically me and all the open source contributors out there. yeah, so that means that I need to do the engineering and also the open source maintenance right now. And that is a lot of work.

Kent C. Dodds (19:51.726)
I imagine.

Julius (19:51.762)
So that's why we're not getting that many big PRs merged. It's just like, you don't have the staff for it. It's just like bug fixes. try and look at them because I know that's, I don't know how many PRs there is open now, probably 300 or so. I know there's like gold in there, but just like filtering through that noise is too time consuming. And at least like for the short term, I think we...

Kent C. Dodds (20:09.53)
my goodness.

Kent C. Dodds (20:15.619)
Yeah.

Julius (20:22.024)
We like got to add more harness supports right now. We're just like cloud and codecs and we've been trying to add cursor for a bit now, but they're ACPS and missing features that they've been like proactively adding for us. So hopefully getting that out this week and then like the same for open code. But then like when, when it comes to like, we got to monetize somehow like this, this product is.

Kent C. Dodds (20:36.334)
Hmm.

Kent C. Dodds (20:40.398)
Hmm.

Kent C. Dodds (20:50.051)
Yeah.

Julius (20:50.75)
free to use, no one's gonna pay us to use this. And like figuring out what that is, I think is what we're currently like discussing. And we have no idea.

Kent C. Dodds (21:03.5)
Yeah, yeah.

Julius (21:06.334)
So like where the product will go is for now mostly like what we ourselves feel like is missing from the ecosystem. Like what does Codex not do or what is, how can we like take the gold from Cursor and integrate it into our app? Because like I love Composer too. I love their cloud engines. I love the like debug mode, but the actual app I don't really want to be in because...

It just crashes my computer.

So yeah, we'll see where we end up. So yeah, long-term we got to find some way to monetize, think, if we don't get acquired before then. yeah, there are so many features that I would like to add, just don't have the time for on my own.

Kent C. Dodds (21:53.41)
Hmm.

Julius (22:06.158)
and prioritizing that. Sometimes it just like works out by itself, feel like, which might not be the best product decision. But like sometimes.

I feel like I have some part of my workflow that is the bottleneck. Currently that is like review. And so that's might be what I'm going to be like planning out next, how that is going to look like. Previously it was like the remote control. Like I want to be able to control my agents from anywhere. And so like we added that. So like a bit selfish, I guess, but.

Kent C. Dodds (22:29.784)
Mmm.

Julius (22:52.242)
Yeah, it is what we, what we too feel like is missing from the current solutions at least.

Kent C. Dodds (22:58.252)
Yeah, that really is the best situation that, or I guess it's different, but it's so nice to be a user of the product that you're building. And then you can just say, I'm just building what I think would be great and hopefully it's great for everybody else. But like you said, you do have to eventually like make money doing this so that it's sustainable or potentially get acquired. And so I'm curious.

because you were involved with T3 chat as well, how does going from a free product to changing to a paid product change the product itself, change your priorities? How do you make sure that you're both like serving the user but also making a sustainable business?

Julius (23:53.14)
Yeah, that's a very good question because T3Chat was, you get your own subscription for that and then we pay the inference to the providers we use in the backend. So there we got to be very careful with how much inference we offer. And we currently may, like in the beginning of the year, we made changes to the pricing structure just to be more sustainable long-term.

Kent C. Dodds (24:12.878)
Mm-hmm.

Julius (24:23.764)
But with E3 code, people are bringing their own subscriptions from these labs that are subsidizing like crazy. Because we could never offer a subscription that is competitive in this space. Like when you can get $5,000 worth of credits on Codex or however many times they are resetting their limits nowadays. We can't compare. We can't compete there.

Kent C. Dodds (24:29.198)
Yeah, that's a lot better.

Kent C. Dodds (24:37.027)
Yeah.

Julius (24:53.99)
So like, yeah, it will, that's also like.

making it harder to know what the monetization will be like. yeah, for T3Shad it's way more like...

sort of constrained by the feature we can build because some features just won't fit in the subscription. Like we added the better image generation canvas flow, beginning of the year. And we had to like introduce a bigger tier for that because image generation is too expensive to offer on an $8 a month tier. And like...

Kent C. Dodds (25:14.51)
Hmm.

Kent C. Dodds (25:27.894)
Hmm.

Julius (25:34.332)
Also, we're like limiting the amount of tool calls you can make on a chat app. We're not like offering the like integrations that Cloud App is using for like Excel and shit. Which I think is very, cool, but just another thing like we can't offer that because it's going to be too expensive. So those that is, it's very much, it's way more fun to work on Teachable Code when you don't have to think about like what it's going to cost.

Kent C. Dodds (25:51.886)
Hmm.

Kent C. Dodds (26:04.332)
Yeah, yeah.

Julius (26:04.372)
because someone else is putting the bill

Kent C. Dodds (26:07.512)
That actually that's part of how one of the things I love about MCP is that like I can build all of these really awesome capabilities and then let people bring their own agent and they they pay for the inference and I can just say like use my MCP server and I can superpower your agent with whatever I want to do but I don't have to worry about inference.

Julius (26:30.248)
That's the way, that's the right place to be in. You don't, when you don't have to think about the inference and competing with the major labs.

Kent C. Dodds (26:38.562)
Yeah, yeah. So what like, when you decided you wanted to jump into building the harness harness, what were like, how did you decide the most important things to build first? Because like you already said, you have so many features that you want to build now that even with the agents that we have, like you're still limited on how much time you can work on those different things.

And so when you're just getting started, you gotta like kind of prioritize somehow. Like obviously you're prior prioritizing now, but like at the very beginning, feel like deciding the most critical pieces to build first would be a little challenging. So how did you make those decisions?

Julius (27:34.9)
Let's see, what did we add first? Like coming from a different app, I came at the time I was using the Codex app. So I had gotten used to certain workflows that I know I wanted to like at least keep in the short term. Even if we had like bigger plans longterm for changing that workflow. But if I...

Kent C. Dodds (27:52.334)
Mm.

Julius (28:03.282)
I knew I wanted to like switch to using teacher code myself. So like I'm a user of the app that I'm building every day. think that's a very important part. like some early product decisions came down to getting to feature parity with the core workflows that the other apps supported at the time, just to make the like migration easier over. So now I haven't opened the codex app.

Kent C. Dodds (28:22.798)
Hmm.

Julius (28:34.846)
for a very long time. I'm still like in the cursor around, mostly like the AID. So like looking at the code and making changes sometimes using their agents there. But I wanted to like move as much of my workflow as possible to the three code so that I can like dog food it the best I can. I think that's where like the early decisions came down to getting the core features from the existing apps in.

Kent C. Dodds (28:36.653)
Hmm.

Julius (29:05.384)
And now we start thinking a bit more long-term like, okay, what is the...

What is the next year going to look like and how are the workflows going to change and how can we accommodate that in the future?

Kent C. Dodds (29:17.934)
Yeah, yeah, that makes sense. So with you being the primary user that you're focused on, that makes it a lot easier. But I think a takeaway for people who aren't the user of their app, maybe it's some guy building a lactation app for mothers or something like that, they're not actually gonna be using this. The key here is,

finding a good user or determining whose job are you solving? Like somebody's got a job to be done. How are you taking that? And then comparing that to existing workflows that they have already and hitting at least feature parity with those and then incrementally improving those workflows to suit the needs of those users better.

It sounds like that's kind of what you did for yourself, but like if you were building a product app that wasn't for yourself, you could relatively easily do the same thing just by focusing on a couple of users and like getting really good feedback loops with them.

Julius (30:29.416)
Yeah, I think like in order to get users from the beginning is sometimes it's easier if they have something to compare against that they're like familiar with. And so if you can offer them that, it's like easier to get them to try your stuff out.

Yeah.

Kent C. Dodds (30:51.508)
so it's about finding pains and coming up with clever ways to solve them. Did you, like with you being the user of your app, you have a lot of clarity of the problem yourself. Did you ever find yourself building out a solution to some pain in your workflow and then realizing, no, this stinks. I gotta go a different direction.

Julius (31:16.596)
Kent C. Dodds (31:22.85)
Maybe for you it's like part way through implementing it, you realize like before you even ship anything like that, that's probably a bad direction.

Julius (31:30.472)
I've had it a lot of times, like just the way the agents are implementing something, like I can prompt something that I think will work very well. And then like when I see the agents just going in circles, I felt like maybe I wasn't clear enough on the problem or maybe I'm solving the wrong problem. And,

Kent C. Dodds (31:47.192)
Hmm. Hmm.

Julius (31:52.732)
It's been a while since I like manually wrote a lot of code. So like mid implementation has changed, but that's like also if you like supervise your agents a bit, not just like throwing them in a cloud sandbox and checking back five hours later, you can sort of steer them. And a lot of people has been asking for like message queuing in D3 code. And that is not something I've prioritized yet because I don't use it myself. I mostly like to steer the agents.

Kent C. Dodds (32:14.285)
Mm-hmm.

Julius (32:22.204)
like sending prompts like midterm. Because I've noticed like if you just leave it be and with a vague prompt, it can like make bad decisions on the fly. can like back itself into a corner. It can like go in circles trying to fix something. And what you end up with is maybe what you were looking for, but not in an elegant way.

And I guess that comes down, comes back to what we were talking like earlier. If it's gonna like be sustainable long-term, kind of gotta.

Julius (33:03.796)
Yeah, you gotta see a bit what it's doing.

Kent C. Dodds (33:07.022)
I think this is an interesting call out though, because maybe some people are using T3 code to just vibe code something. Like this is not something I'm gonna maintain long term. And so they want this feature. Maybe some of them want this feature because they are just sending off an agent to work for five hours and they don't wanna, they're not being very responsible. But there could be.

some of your users who are saying, no, I really am just like, by coding a little side project here, I do want to send queuing. And so getting a good representation of feedback from users and like tightening that loop is really valuable. With yourself as a user, you've got the tightest feedback loop possible. I don't know how you make that any tighter, but.

especially as your app grows in popularity, there are use cases that you might wanna support that are not necessarily the way that you would, like the workflows that you have, but do represent like a broad use case for your user base.

Julius (34:18.194)
yeah, definitely. I think that that's what, when like now that we have a lot of decor laid out, that's going to be like the next set of problems to tackle is like, okay, now that we have the stuff that we need, what is like more general needs, what are like different ways to accommodate these workflows. And, in some way that's like good, good and bad to build for developers is

Kent C. Dodds (34:45.176)
Yeah.

Julius (34:46.546)
developers tend to really want to customize their apps. Like the workflows want to have like very custom to themselves. And so you got to build a product that you can customize, but then it's kind of hard to also like show the core workflows. is the like, recommended way to do this? Okay. Now you have, I can customize this to have like four or five different ways to solve this problem, but what do you recommend? like,

Kent C. Dodds (34:49.772)
Mmm, yeah.

Julius (35:14.92)
I've seen people on Twitter asking me like, what is your agent workflow? And I've been like reluctant to share it mostly because I think you gotta like find it yourself. what worked for me is not going to work for everyone else. So, but also like building that in so like you can capture all those user groups is going to be very difficult.

Kent C. Dodds (35:27.214)
Hmm.

Kent C. Dodds (35:44.268)
Yeah, well, in

Julius (35:44.34)
going to be a fun challenge to tackle in the near future.

Kent C. Dodds (35:49.548)
Yeah. And, and one of, that is a technical challenge. it's, an interesting technical challenge because it's very much a people challenge as well. And, I appreciate that you originally pushed back on message queuing because you know that that, in your experience that, it makes for software that's harder to maintain. And, like it's not just, let's load this feature or this, this thing up with every possible workflow.

but you're actually being thoughtful about the job to be done. It's not just what do they want, but it's what do they need and do they need, in your mind, people are using this to build maintainable software and maybe it expands beyond that. so, okay, we're gonna add message queuing because it's for more than that. But at the same time, you want to build in features so that the pit of success is wide. You don't want to make it easy for people to build bad.

software with your software, you want them to have a positive experience using the software. And so you're going to prevent them from doing things that are harmful. It's like the same thing as like a fence around a roller coaster. Like it might be fun for people to walk right up to the roller coaster, but that's dangerous. And so we're going to put up this fence to prevent you from doing that. And so like just having the sense for what are things that people might.

want to do with this that we're not going to let them because it's not good for their overall experience using this product.

Julius (37:24.872)
Yeah, maybe. Yeah. Like I'm not going to like prevent them from doing it long-term. It's just like more of an, I'm not going to prioritize that when there are other more important things to solve that is like, yeah, cause like people are going to use it. know a lot of people is using it to build personal apps or bad-coded stuff and they don't have the same problems as I do. And I'm not going to say no to that, but it's just hasn't.

It's like, yeah, it's the priority queue. I guess you can call it is sort of decided in an order. And those workflows, at least for me, it's not something that I'm going to spend like my time on right now. If someone else comes in and build it, fine. I can review it. can like, I know it's something that we're going to add. This is like when we're going to add it.

Kent C. Dodds (38:14.636)
Yeah.

Julius (38:23.454)
when I'm going to put my time to it.

Kent C. Dodds (38:29.88)
Cool, well, Julius, it's been awesome to chat with you about how you think about product engineering. Before you go, I like to leave people with a homework assignment, something specific that they can do to improve their product sense, their product engineering skills themselves. So I want you to think a little bit about what is a specific thing that somebody could do that could put it on a list and check it off? I did that thing.

that would get them just a little bit closer to being a skilled product engineer, having the right product decisions. So what's something in your experience that has made you a better product engineer that somebody could do to just like practice?

Julius (39:15.668)
I think for me, it's really been that skill to like take a step back and broaden your eyes a bit. look at the problem from a different perspective. Especially like working with Theo who can be like very good at getting a proof of concept out there and like showing me a feature. He can like be very good at that, like getting something working very fast.

So then it's sort of like been my job to take this step back and see like, okay, how's this look long-term and is the solution like good and maintainable for us to develop further on over time. So I think that skill has been like pretty good for me.

Kent C. Dodds (40:08.436)
Awesome, good. So folks, your homework for this episode is to take a step back and look at your product from the whole picture. Lots of developers listening to this work on a massive product and they're just like on one little sliver. For those people, like look at the whole picture, the parts that you touch, the parts that you don't touch, and then for the smaller products, even those, unless you're building like little mini apps all the time.

Which even that, there's a way that you can take a step back and maybe don't look at the app specifically, but more at the users that you're serving and what their actual needs are. That is the homework assignment. So Julius, thank you so much for giving us some of your time today. Appreciate you very much. if there's anybody who has questions for you or want to follow you and keep up with what you're up to, what's the best way for them to do that?

Julius (41:04.436)
Currently X.

My tag is like Eulerino. I think that tag way back. So yeah, let's just tag me there. I might reply five times or.

Kent C. Dodds (41:15.223)
Awesome.

Julius (41:20.5)
but that's probably the best way.

Kent C. Dodds (41:22.904)
Super, thank you so much, Julius. I appreciate your time and hope you have a great one. We'll see you all in the next one.

Julius (41:29.14)
See ya.