Kent C. Dodds (00:01.314)
Hey everybody, it's Kent C. Dodds and I'm joined by my good friend Aaron Francis. How are you doing Aaron?

Aaron (00:06.737)
I'm doing great and I feel like I should correct record Aaron D. Francis. If we're going middle initial, you know, might as well tell the people Aaron D. Francis. It's good to be here. Thanks for having me.

Kent C. Dodds (00:10.906)
Hahaha

Kent C. Dodds (00:16.088)
That's great, Aaron D. Francis. Sometimes when I say Kent C. Dodds, people think it's Kent C. as in like, that's just my first name is Kent C.

Aaron (00:25.057)
Literally, I only ever call you Kent C. Dodds. So it's a good brand. Whatever you're doing is working.

Kent C. Dodds (00:28.046)
Fun and quick story. I've been watching this true crime YouTube channel called Mr. Ballin and His name is actually Michael B Allen but his Instagram is Michael B Allen and so people would DM him and say hey, Mr. Ballin and That's where that came from Yeah, yeah

Aaron (00:36.868)
Mm-hmm.

Aaron (00:47.544)
Amazing. man, I wish I had a cool nickname like that.

Kent C. Dodds (00:54.05)
Well, cool, we're talking about product engineering. That in my estimation is where, the, if software development ever goes away as a discipline, the last skill that the last software developer will have that's still valuable is product engineering. And so what do you think about that, Aaron? What is product engineering to you?

Aaron (01:16.464)
I think that is a directionally correct take. I think we both agree the death of software engineering has been greatly exaggerated, but I think we would also both agree that it's changing. And that like what we as software engineers should be doing is morphing a little bit. And that's both, it can be terrifying. think...

It was terrifying for a while and now it's exciting. I think we've both gone through the valley of despair and we're on the other side. And I agree that I think the future is more, don't, maybe higher level is the right term. think what we've been doing, both you and I as educators, what we've been doing for a long time is teaching people, here's how you write.

Kent C. Dodds (01:45.388)
Yep.

Kent C. Dodds (01:51.137)
Yep.

Aaron (02:09.766)
this specific little piece of code in a maintainable way. Here's how you implement any of those acronyms that Vercell has, ISR, SSR, PP, whatever, all those stuff. Like here's how you do this like super low level technical stuff. And I think the agents have just gotten really good at that like rote, like implement SSR. Like they're just, of course they still make mistakes, we still need to verify and all that. But that level of,

ticket taking development, is what I call it, where you just like, you sit in the bowels of, you know, AT &T or some bank somewhere and you just grab tickets off the board and implement it. I think that is becoming less valuable. And what you're calling product engineering, I think is the correct term, is becoming much more valuable. And to me, that is, we can like hold constant the

the talk to people side for a second and just think about the development side. What does this thing look like at the surface, where the user interacts with it? How does that go down to maybe the front end, the back end, the database? Let me take this whole vertical slice and think about from soup to nuts, what is this thing supposed to do? How is it supposed to work? And then, of course, you layer on the whole like...

Well, what do the users want? Like what do the actual humans want? And that is, think, where you can go from a mid-level, like valuable employee to a senior super valuable employee, is you actually are hopefully talking, but at least thinking about like, what should we build? What do the users want? What do they expect to happen here? And I think that kind of starts to encompass the product engineering moniker.

Kent C. Dodds (03:35.758)
Mm.

Kent C. Dodds (04:01.954)
Yeah, yeah, and taking into account the fact that the users might not know exactly what they want. And I listened to a book recently titled, Jobs to be Done, which is the Clay Christensen idea to, the basic, one of the premises in there is that the users don't really know what they want, but they do have a job to be done. so like figuring out what that,

Aaron (04:06.672)
Mm-hmm.

Aaron (04:11.684)
Mm-hmm.

Aaron (04:24.656)
Mm-hmm.

Kent C. Dodds (04:29.934)
actual job is and really understanding the problem space is a tricky thing. It's hard to learn. What are you currently product engineering, Aaron? What are the things that you're working on right now?

Aaron (04:35.739)
Mm-hmm

Aaron (04:42.94)
So the most product thing I'm engineering right now is a desktop application. And the app is called Solo. And of course, it's ostensibly for AI, but it comes at it from a slightly different angle. And I think this is maybe an interesting thing to surface was I was doing the stuff that we all do. We got ghosty open and got

12 tabs and anything you can dream, you can build. So I'm working on three different projects at once. And one of the things I started to notice was like, well, I've got all these tabs open in different projects and the agents are spinning up in PM run dev themselves. And so they're backgrounded somewhere and I can't see it. And so I think something we should put a pin in was I had a huge problem that I was experiencing and I thought this sucks and I hate it. And so

Kent C. Dodds (05:32.109)
Mm-hmm.

Aaron (05:42.244)
I had in the past built out a Laravel package for basically a terminal multiplexer written in pure PHP to solve this same kind of problem. And I thought, well, I'm not living in PHP anymore. What if I built a desktop app for it? And so that's what Solo does is you've got all those agent orchestrator tools, which are all great. This is more of a pure like

Terminal Multiplexer Agent Organization. There's an MCP server so the agents can talk to each other and all that kind of cool stuff. But it is very much a scratch my own itch. It separates the agents from the dev stack so you can like spin up your dev stack and then the agents can read it, that sort of stuff. And it's been a surprise hit, honestly. Like I put it out and thought this will be marketing for other stuff that I'm working on and people were like.

Kent C. Dodds (06:37.998)
Mm.

Aaron (06:39.0)
I just want that and I want it to do these 50 things. And I'm like, shoot, I didn't think of all those 50 things. And so that's also been an interesting journey of receiving all the DMs and the emails and the feedback and trying to, like you said, figure out what does this person actually wanna do? Because they say they want a button here. I don't think they want a button there. What are you actually trying to do? And so deciphering all of that feedback has been, it's been a lot of fun, truly.

Kent C. Dodds (06:54.744)
Hmm.

Kent C. Dodds (07:04.843)
Yeah, that is a really tricky thing. it's come up time and time again in these conversations is really sessing out what the actual need is. I have an example when I was really active in building open source libraries that people would use in the React ecosystem. And I had somebody ask me for a specific prop on a React component to control whether a certain thing was rendered.

Aaron (07:30.236)
Mm-hmm.

Kent C. Dodds (07:34.286)
or how to like, it was basically add an F statement to updating state, right? Like, no, it's just another F statement. You you get many, many such cases. And in those situations, it's just really good for the person who understands the system to step back and think, like, look at the system holistically and what is something that we could do to change the way that it works foundationally.

to eliminate that problem from the first place. Like make it so that didn't even have to open up the issue. And I ended up creating what I called the state reducer pattern in the React ecosystem. We don't need to get into it, but it worked out super well. So that's the key in that particular scenario is figuring out ways that you can create a simpler solution than what they asked for in the first place.

that completely eliminates the problem that they brought to you.

Aaron (08:33.436)
Yeah, it's the same as like, you know, back in ye olden days when we would write code with our fingers. It's the same kind of deal where you're like, okay, well, I need to introduce a new affordance here. I could just bolt it on. Or is there like a data structure that unifies all of these channels or all of these ingress points or surfaces or whatever? It's the same thing we used to do and...

and still instruct the agents to do in the code, which is like, hang on, backup. We are like, we're littering state all over the place. What if we introduce a state machine and we just have one place where those transitions happen? It's the same thing when the user comes to you and they're like, hey, can you throw a button on the top right to do this? And you're like, why? And I got like, I got most of my...

Most of my pre solo like user interaction when I was, I worked in person many years ago for five years at a local services firm. It's a property tax protesting firm. And I was building internal software and I was the only software developer and there were like 15 or 20 people there. And my users were like sitting right there. I would build the software and they would be like, hey, we need to add this. And I would.

Kent C. Dodds (09:47.82)
Nice.

Aaron (09:52.998)
say like, are you trying to do was always my question. You know, I'm trying to be kind to these people and not say like your solutions suck. What are you actually trying to do? But in my head, I'm like, what do you like, tell me why this even came into your mind? And like, I need to export. I'm like, okay, we need an exports concept. We don't just need to tack buttons onto every screen.

Kent C. Dodds (09:56.589)
Yeah.

Aaron (10:16.956)
we need like an idea or like a container in which we can put all of our export shaped things. And that was just like super valuable experience for me because if something was not clear or bad or needed tuning up, I would like, they would say, hey, Aaron, why can't or how come or why does this work? And I'd be like, oh, that's a good point. So I learned a ton in that experience that I'm hopefully carrying on till today.

Kent C. Dodds (10:44.236)
Yeah, this is another thing that just keeps on coming up is being really tight with the user is super valuable. And it does change if you've got a million users, that's a lot harder to do. Surprisingly, like you've got so many of them, but it's still kind of harder to do because you need to find some sort of representative user to really understand their problems.

Aaron (10:58.042)
Mm-hmm.

Kent C. Dodds (11:10.894)
I talked with Dylan earlier today, so folks listen to that episode too. We talked about that a lot with his work on the Vercel domains API and all the monitoring and everything he put in place. But I want to ask you, Aaron, about when you're talking with the users, what are the sorts of questions that you can ask them to really get clarity on the problem that they're presenting to you? Like in that...

Aaron (11:19.427)
Mm-hmm.

Kent C. Dodds (11:37.346)
I mean, you're literally sitting right next to them and they say, I need button here. But like, how do you extract from them the clarity around the problem so that you can build the right solution?

Aaron (11:40.976)
Mm-hmm.

Aaron (11:50.171)
Yeah, think, you know, think trying to get as much information about like what is in their head. And so like right now people will DM me and be like, hey, in solo XYZ. And one of my first questions is usually like either what are you trying to do? Because if you're trying to do agent to agent communication and you want me to build this whole thing, well, I like agent to agent communication.

But in my head, I kind of have this other channel like mapped out for that and maybe that's better. And so I think part of it is you need to extract the underlying intent. You also, you have to have a vision for your product, which I think you have to square that circle somehow. And then the other thing is like, I will often ask, what did you expect to happen? Because no matter what kind of vision I have, if all the users are expecting something else, I kind of just need to conform to that.

Kent C. Dodds (12:30.925)
Yeah.

Aaron (12:47.736)
in one way or another, or at least like honor what they expected somehow. Because something I'm like constantly trying to relearn is as much as I think I'm a very smart boy, if everyone thinks that it should work one way, it's possible that it might maybe should work that way. And that's something that I'm constantly having to tell myself, because I thought, what a clever solution.

Kent C. Dodds (12:49.666)
Hmm.

Kent C. Dodds (13:08.429)
Mm-hmm.

Aaron (13:13.936)
But we've done this with code for a thousand years. We wrote our clever solution and then came back six months later and to ourselves, we're like, that guy was an idiot. And so now I'm trying to like, I'm trying to close that loop where everybody is saying, hey, when I click this, I thought that was gonna happen. I don't wanna go into the pattern of, well, you know, actually the reason this is better, it's like, okay, what is the fundamental mismatch? And if I'm really set on that path,

Kent C. Dodds (13:21.454)
You

Aaron (13:42.609)
well then I need to change something about how it presents itself so that they expect that rather than have this like, well actually it should work that way versus I don't care man, I want it to work that way and trying to close that gap. So it's a lot of like, what did you think was gonna happen? What does it do in your other tools that you use? Like what are you trying to do? Why are you trying to do that? Those kinds of things to hopefully get below like.

And we can't blame the user for having a bad solution. They know nothing about the architecture underneath, but if we can find out what they're trying to do, we might find a nice neat home in the existing architecture to satisfy their need rather than bolting on another button.

Kent C. Dodds (14:23.586)
Yeah, yeah, absolutely. And sometimes even like outside of the existing architecture too, that's when you take a step back and think, okay, maybe the decision that I took way back when was the wrong one. I actually need to go this way. And luckily with agents, it's pretty easy to, well, relatively easy to explore those different things. What you said reminded me of the design of everyday things. This is a book by Don Norman, I think.

Aaron (14:36.55)
Mm-hmm.

Mm-hmm.

Aaron (14:44.111)
Easier, yeah.

Aaron (14:50.14)
Mm.

Kent C. Dodds (14:52.654)
where he talks about how door handles are designed and different things like, does it suggest pull or push? Simple things like that. And sometimes we have our own intuition for how things are to work, but we can't pay ourselves. And so you really do have to listen to the users. You said earlier, you were talking about how you have this product division.

Aaron (15:01.85)
Mm-hmm

Aaron (15:21.286)
Mm-hmm.

Kent C. Dodds (15:21.294)
And it sounds like there's a little bit of contention between product vision and what everybody is telling you. Like they want this thing to be. I'm curious how you deal with that friction. And maybe before that, like what is, what does a product division mean? Like what is the vision for a product?

Aaron (15:26.48)
Mm-hmm

Aaron (15:39.301)
Yeah, I think like having a point of view on how something should work, not necessarily like at the feature level, but like at the product level. And so like going back to the property tax days, I had a vision for like how this, it was like this CRM process automation, invoicing, land valuation, this whole thing.

just having a vision for like, okay, all of this stuff needs to work together such that, kind of like my North Star was, the computers can do literally everything that is computable and then surface information to the human. That was kind of like, this is what I want. I want, and this was pre-AI, so now the computers can do a lot more. But I wanted the system to automate as much as possible. And then when it could not,

Kent C. Dodds (16:30.488)
Hmm.

Aaron (16:36.719)
automate anything further, it's surface relevant, what we would call context now to the human. So it would be like, hey, this person has not signed their contract, it's due on this day, click this button if you wanna send an email, otherwise here's their phone number and you can call them right now. So that is kind of like, that's less of a, no, it needs to have a left side bar instead of like top nav and more of a here's where I want to go with this thing. And so for solo,

Kent C. Dodds (17:04.83)
Mm.

Aaron (17:05.753)
It's less like, want this to be, it's less, I want this to be the place where people come and they spin up 15 different work trees and fire off a bunch of agents and they never look at it. And that informs the actual features that get built. And so when someone comes to me and says, I would like to see a Git diff in Solo, that fits with what I want it to be.

Now, how I implement that and how they want it implemented is still an open question. But what I want solo to be that fits like the vision that's in my head. And if somebody comes to me and they're like, I want you to recreate cursor. I'm like, well, that's not what I want to do. Like, I don't want to do that. Cursor's great. Just go use cursor. And so kind of having some North Star of like what you're building towards and then

Kent C. Dodds (17:48.567)
Hmm.

Aaron (17:59.409)
the actual implementation paths then become somewhat flexible. Like you're just trying to get to the top of the hill, whether you go up the left side or the right side is more of an open question. But if you start just taking everybody's feedback and implementing it as if it's gospel truth, then you end up with something that's bloated and doesn't do anything the way that anybody wants. It's much better to have a point of view that excludes a lot of people.

but really includes the narrow slice that you're going after instead of something that's so broad that everybody's like, well, this is about 40 % of what I need. Because then nobody uses it. And so trying to square my vision with what people want and separating that slightly from specific feature implementations.

Kent C. Dodds (18:49.262)
I think that is really smart because like, okay, so we've got x.com the everything app. Well, I mean, it's not actually the everything app. Maybe they want it to be eventually, but like, I'm not gonna use the everything app to like, I don't know, write my software, run my terminal commands or like, yeah. So I think, especially when you're getting started too, and with you, I imagine,

Aaron (18:56.923)
the everything up.

No! No!

Aaron (19:09.157)
or pay your friends. Like we've got apps for that.

Kent C. Dodds (19:19.026)
I mean, maybe in the future you want to hire people to help you with Solo and like it just continues to grow. But certainly right now you want to maintain that, that vision. And you mentioned like, you want to get to the top of the hill, whether you go left or right to get there, it's fine. But like, if you just go ahead and implement every feature, you're not going to get to the top of hill. You just go and doing circles around it the whole time. And, and on top of that, if you do just implement every possible feature, then

Aaron (19:28.305)
Mm-hmm.

Aaron (19:38.161)
Nope. Yep. Yep. Exactly.

Kent C. Dodds (19:48.982)
like, yeah, sure, you're gonna slow down, but it's the agents, okay, whatever, maybe you don't slow down, maybe you're just as fast, but the onboarding experience and the usability of this thing, it just becomes so cognitively difficult for humans to use, and agents as well, with that context does bloat. so, yeah, so when the users come to you and say, hey, I want this, I want that,

I want you to build cursor. Having that North Star just really helps you to say, that doesn't quite fit, but like, let me try and get to the core of why you want this to be cursor. And is there something that I can do that is still in line with my vision that would address the challenges you're having? And maybe there's not, and that they're outside of that slice you're talking about.

Aaron (20:29.063)
Right. Yep.

Aaron (20:41.041)
Yeah, there's like, people have come to me and said, I need you to build in work trees. That's like a very clear, discreet request. And my answer is like, one, I don't use work trees, right? don't like, I am still a single human and I find it hard to even like reason about the same app in six different slices.

Kent C. Dodds (20:54.744)
Same.

Aaron (21:07.877)
Like I can much more easily be like, I'm gonna work on this app and while it's cooking, I'm gonna work on that little side project and then my personal website. That's fine for me. And so first of all, I don't use the thing that the people want me to build, which is already like a red flag to me of, hey man, don't like, you're not gonna have the touch, right? You're not gonna have the, I know which parts are prickly and which parts aren't, cause you don't use it. And so that already raises a red flag to me. But then you go like, you go further into the process and you say,

Hey, I don't use them. What are you trying to do with it? It's like, well, I just want to be able to have changes not stomp on each other. You're like, OK. Well, that's different. And so what about like discrete checkouts? Like what if you just checked it out again? How does that work for you? like, well, then I have this problem with node modules bloating. And I'm like, OK, well, that's interesting. What else have you tried? And then finally, we can get to somewhere where it's like,

The nugget of the problem is you want to be running multiple agents on one project. Now, is that something that I need to figure out how to let you do? I don't know, kind of an open question. But the request was, I need work trees. And the reality is, I just want to run multiple agents safely without them stomping on each other. And those are different things. One is a solution and one is a problem. And so I'm always trying to get to, what's the real problem here?

Kent C. Dodds (22:24.718)
Yeah.

Kent C. Dodds (22:30.206)
Yes, that's a really big takeaway for everybody listening right now. Users will often just naturally come at you with solutions. At least this is true of technical users and maybe in some cases non-technical users. I think, speaking for myself, I just have this natural tendency to be like, if they would just do it this way, then it would be so much better. without all the context of the bigger solution,

Aaron (22:42.193)
Mm-hmm.

Aaron (22:51.281)
Mm-hmm. Yep.

Kent C. Dodds (22:58.062)
then I'm as just hallucinogenic as the AI that I'm using to help me with this stuff. So yeah, that's a really, really good point. Try to...

Aaron (23:03.268)
Mm-hmm. Yep.

Aaron (23:08.315)
And it holds for non-technical users. mean, at the property tax firm, that was the export button. It was like, can you just put an export button here? And I'm like, we don't even have exports. Like, I don't even know what you're trying to do. And in reality, it was just like, I just need to download, you know, these five properties. I was like, okay, well, maybe exports fits there, but maybe there's just like a better way to do that. So everyone comes with, can you just do this? And that's when you're like,

Kent C. Dodds (23:37.836)
Yeah, yeah. Well, and maybe like I need to export this so I can do that. And you're like, actually I can make that way easier than an export button.

Aaron (23:42.301)
Mm-hmm

Aaron (23:45.977)
And we did. I got to tell you this. We totally did. So I did build CSV exports, but I also built live Google Sheet exports. So they could do the equals import data and then give it this signed URL, and all the data would show up in Google Sheets, which is what they actually wanted. And so if you dig far enough, you'll find something that is maybe even way better than what their proposed solution is. It was actually really cool.

Kent C. Dodds (24:12.81)
That is a great story. Yeah, I appreciate that. I really liked what you said about when somebody came, like they came to you asking for work trees and you're like, I don't know, man. I'm not the right person to build that. I don't use that. Like that's not part of my workflow. And I had situations like this all the time as I was working on open source libraries too. especially when I built this library, I was using it actively and then I move on. I'm not doing an AngularJS anymore.

Aaron (24:26.14)
Mm-hmm.

Kent C. Dodds (24:42.358)
or whatever and people are asking me for features and stuff and I'm like, am the least, like I'm the worst person to solve this problem. Would you like to maintain this library now? Like you are way better because you have the problems and handed off a lot of libraries.

Aaron (24:51.313)
Mm-hmm.

Aaron (24:59.366)
Yep, there's just something that like, you just don't get if you're not in the scene, right? Like you, everybody has a brother or cousin or an uncle or somebody that knows a guy who knows a thing or something. And like, whenever you're, when you're like, hey man, I wanna like, I need to, I need to get a new car. And he's like, I got, I got a car guy. That's kind of how it is. Like I'm not a work tree guy. I'm not in the scene. I don't know the like,

definitely do this. Don't do that. this is going to bite you hard or this is going to lock up your your get index or whatever. Like, I just don't know it. And so not being in the scene is really hard, which is not to say that, like, you can only build things that you use. But I do think if I were to go out and try to build something for dentists, I would have a really hard time because that's just not my world. I don't know the language they speak. I don't know the problems they run into. I don't know why they're furious with their software. I'm sure they are.

but I don't know why and I don't know how to fix it. I've never worked in a dentist's office. And so I think there's some portion of like, you kind of have to be embedded. And this goes back to like having a point of view. I can't have a point of view on how dentist scheduling software should work because I've never been a front desk worker at a dentist's office. And so I think that can be great news because if you're embedded somewhere weird, like I was in a property tax firm and I'm...

Kent C. Dodds (26:09.411)
Yeah.

Aaron (26:24.389)
you know, we made that property tax firm incredibly profitable because there was there were no software engineers embedded in property tax firms. And so like if you're listening and you're thinking, well, my, you know, my aunt and uncle run a window washing, you know, company that makes a million dollars a year and they do it all on paper. Well, go talk to your aunt and uncle. Like there's a huge opportunity, I think, for bespoke SaaS for people that are embedded in

Kent C. Dodds (26:32.877)
Hmm.

Aaron (26:53.789)
places that have not traditionally been worth touching from a SAS perspective.

Kent C. Dodds (26:59.692)
Yeah, and I'm glad that you called this out because what I think some people might mistakenly take away from this is, okay, well, I just have to work at a developer company, like a company building for developers because that's all I know is I'm a developer. But I think that if there was an opportunity to go and handle scheduling for dentist's office, that's not just a, well, definitely not, because I don't know anything.

Aaron (27:15.431)
Mm-hmm.

Kent C. Dodds (27:28.588)
That's a, here's an opportunity to go learn about that. And what's, what I find really interesting about all this. I said that, think on every episode so far, nothing has really changed. Like 50 years ago, the software developer who really understood the domain and the problem space and the users and the problems, they were way more valuable than the one who could just take a JIRA ticket and turn it into code. And that has just,

Aaron (27:30.332)
Mm-hmm.

Aaron (27:52.593)
Mm-hmm. Yep.

Kent C. Dodds (27:58.19)
accelerated or increased now that taking a Jiraic ticket and turning it into code is so much less valuable because we've got tools for that now. And so, and of course, like there's the architect and like, you know, guiding and all of that stuff, but really I am of the opinion that we have not seen the end of models improving. I think that models would continue to improve.

Aaron (28:06.524)
Mm-hmm.

Aaron (28:23.901)
Sounds like a safe bet.

Kent C. Dodds (28:24.91)
Agents will continue to get better, harnesses will get better. Maybe one day they'll be able to do the architecture stuff. Maybe they won't. Either way, being product focused and understanding the user's problems was really valuable 50 years ago. It will continue to be valuable. And as I said at the beginning, it will be the last valuable skill that a software developer has before the industry just goes away, if it does.

Aaron (28:49.917)
Mm-hmm. Yep. No, I agree. and I think that that speaks to hopefully a proliferation of, you know, micro SAS is if you can be the engineer that can speak to the people. Well, then you just wield these tools that have made everything easier. I mean, I think a big reason we've had.

Kent C. Dodds (29:11.042)
Mm-hmm.

Aaron (29:13.837)
monolithic SaaS for so long is, you know, people say code is not the bottleneck. I don't know, man. It's taken a long time to write a lot of this code historically, and now it doesn't. And so I think, you know, Salesforce is never going to come down to the level that would make, you know, a two or five person company a lot of money. They're just not going to do it. But now with all these tools, you can do everything a lot faster, which is a double edged sword. You can do the wrong thing incredibly fast.

Kent C. Dodds (29:22.915)
Mm-hmm.

Kent C. Dodds (29:34.766)
Mm.

Aaron (29:43.517)
and feel like you're making a ton of progress. And so I think that is the skill that a lot of us are learning right now is how do I do the right thing incredibly fast or at least directionally correct rather than do 10,000 lines of code a day on the wrong freaking thing. so talking to like figuring out painful problems that human beings have, hopefully human beings with money.

Kent C. Dodds (29:44.077)
Yep.

Aaron (30:12.037)
and then using these new superpowers that we have to hopefully solve people's problems, they get a lot of value, you get a lot of money, and then everybody, like the whole world becomes more efficient. I know that that's an optimistic take on the impending doom, but I think it could be true, right? It could possibly come to fruition.

Kent C. Dodds (30:30.936)
Well, it's certainly not gonna be true if we don't believe that it's possible. So we gotta manifest that. And I completely agree with you that I think that the big players will continue to be big players. But I do think that bespoke software and smaller teams are a big part of that future. And so if you're listening to this and you're like, you know what?

Aaron (30:35.015)
Correct. Exactly. Yes.

Aaron (30:46.642)
Mm-hmm.

Kent C. Dodds (31:00.398)
I actually do have this really strange obsession with dentistry. Then like there's a really big opportunity for you to go and AI-ify the dentist office or whatever, you know, don't just go AI-ify it, go and ask them questions, interview them and say, listen, I just want to understand your problem. What is your problem?

Aaron (31:05.137)
Mm-hmm.

Aaron (31:16.967)
Mm-hmm.

Aaron (31:21.309)
Mm-hmm.

Yep, whole world runs on executive assistants and secretaries that have been at the business for 25 years. That's how the majority of small businesses work. Like you go to a plumber, you go to a title company, you go to a real estate office, and nine times out of 10, there is one person who's probably underpaid keeping the whole thing in their head, right? I have my favorite HVAC company, which is

Kent C. Dodds (31:34.126)
Hmm.

Kent C. Dodds (31:50.83)
Hmm.

Aaron (31:53.729)
horrible to say because my HVAC keeps breaking so much that I have a favorite HVAC company. The whole thing, the whole thing is literally run by this woman who is the owner's assistant and she's truly been there for 30 years and everything is in her head. And those companies are in every single town across every single country. And you go in there and it's just like files stacked up on their desk and they know where every single one is. But you can't

Kent C. Dodds (31:58.158)
Hahaha

Kent C. Dodds (32:08.238)
Hmm.

Aaron (32:23.419)
You can't argue that that's more efficient than some dinky little piece of cred software built specifically for them that could make them super efficient. And you could probably rip out in two or three months with the back and forth of actually understanding what they're doing. And that is just a huge opportunity that has historically not existed. I think the question is, how do developers get into those spaces? And that's still hard. If you don't have an in, like if

Kent C. Dodds (32:50.83)
Mm.

Aaron (32:52.433)
Maybe you come from a long line of dentists and you're the black sheep that's a software developer. Well, let's rely on that. Go talk to all your siblings and parents or whatever that are dentists. But I do think the softwarefication of the world will continue. It's just finally gonna start bleeding into these little micro niches, which is an opportunity. Don't go out and try to build, for example, cursor. When everybody's trying to build cursor,

Go find some one to $5 million company locally and be like, hey, I think I worked here in high school. Can I just like come shadow y'all for a week and see what's going on and see what happens.

Kent C. Dodds (33:33.72)
All right, Aaron, but what about all the introverts who don't wanna talk to people? What do they do?

Aaron (33:39.037)
that is me, first of all. So I feel, I feel your pain. I think you have a couple of options. One is, one is you, you partner up with a friend. You know, there are, there are people that like to talk to other people. Those people do exist. And so I still think the, you know, the sales, sales guy or girl developer guy or girl as a team, that's awesome. And frankly,

Kent C. Dodds (34:08.526)
Mm-hmm.

Aaron (34:08.945)
That can work super even better now, now that the developer half of that team is basically like 10 people if you get the right tokens. So I think that's still totally viable. And in fact, you could probably find your domain expert on the non-technical side of the house. Like who's your best friend that you went to high school with? Where does he or she work? What do they do?

Kent C. Dodds (34:16.45)
Yeah.

Kent C. Dodds (34:28.929)
Yeah.

Aaron (34:34.557)
Call them up. Maybe now is the time for you to finally start that business together that you've talked about since high school or whatever. I think another option is you just kind of treat it like an engineering problem. Like you treat it as a fact-finding mission and not like a networking mission. And I think reframing it slightly in your head to there is a pot of gold out there somewhere.

Kent C. Dodds (34:51.854)
Hmm.

Aaron (35:00.165)
And my job is to systematically eliminate and find, you know, the right options. And I'm going to treat this like, I'm going to treat this like a spreadsheet. I'm going to, you know, talk to all these people that I know and reach out on LinkedIn and get lunch with. I mean, there's nothing that old people on LinkedIn want more than somebody that is younger than them to say, like, I just want to learn about your industry. people on LinkedIn love that crap. so, especially if they're like,

Kent C. Dodds (35:22.792)
Hahaha

Aaron (35:27.577)
above 60 and you're below 40, they're going to think, the next generation. so just treat it as like a, I don't know, like an optimization mission of there's something out there for me and my job is to go uncover it. And then just face reality that you're going to have to talk to a few people, but on the way to some mission that you actually want. think

Kent C. Dodds (35:31.671)
You

Aaron (35:48.529)
that framing could be helpful, finding somebody that's super outgoing and good at sales that you implicitly trust, that's the real move. If you can pull that one off, that one seems a lot easier.

Kent C. Dodds (35:59.022)
Yeah, I completely agree. actually, I had an opportunity to do exactly that, not for dentists, but for cosmetology schools of all things. And I didn't pursue that because I just love being an educator and I decided to go this direction instead. I recommended a bunch of my friends to pursue this idea because it is like,

Aaron (36:08.261)
Yeah, there you go.

Aaron (36:14.941)
Mm-hmm.

Kent C. Dodds (36:27.912)
Yes, okay, agents are going to be able to build everything. But this guy has so much experience and knowledge in this like really tight niche that, yeah, of course, like we can build a company. We will be the AI that puts this, you know, this industry on its head. And because we have all of this knowledge and experience, we can encode that into the AI that we build. And that's going to be better than whatever some Joe Schmo throws together on a replet.

Aaron (36:33.231)
Mm-hmm.

Aaron (36:42.597)
Yes, exactly.

Aaron (36:50.022)
Mm-hmm.

Aaron (36:55.171)
Mm-hmm. Mm-hmm. Exactly. And the connections that your friend has. He can walk in any door and be like, hey, I've been in this industry for 20 years. You know me, we did this, we did that. Hey, what's up? And that kind of stuff, like when open clause are sending a billion emails a second, having a human that knows another human is gonna be pretty powerful. And so even that is like, if you're embedded in an industry or you've got a friend that is, that is becoming increasingly valuable.

Kent C. Dodds (36:59.681)
Yeah.

Kent C. Dodds (37:25.144)
Yeah, absolutely. So working with developers or building a product for developers, relatively straightforward if you're a developer, like you kind of have a good idea and you've got connections, you've got people who are willing to use it. Developers often are willing to put up with stuff as long as we are aware, like this is alpha software. Okay, great, I expect bugs. Working with non-technical people,

Aaron (37:34.428)
Mm-hmm.

Kent C. Dodds (37:50.592)
is a little bit different. You were really fortunate to be in the room with the people as they were using the software. What would you say to somebody who is not? they are building, like if they're building internal software, then they can go do that. But if they're building something for millions of users that are non-technical or technical, do you have any advice or ideas of how somebody can develop a product focused mind in a setting like that?

Aaron (37:54.043)
Mm-hmm.

Aaron (38:05.937)
Mm-hmm. Mm-hmm.

Aaron (38:17.469)
I don't have any advice for anybody that's building something for millions of users. So I'll just say that upfront. Never done it wouldn't be fair to opine on it. think generally speaking, having, I find that it's nice when like the right thing to do and the strategic thing to do are the same thing. And I think this is a case where being like empathetic towards the user is incredibly,

valuable because you have to imagine that like, truly like imagine somebody is trying to do their job and go home and they're as stressed out as you are about the world, the economy, the kids, baseball practice, whatever. And your tool is the surface that they spend most of their day in. And so when they send you an email, it's like, this thing freaking and you're like,

Kent C. Dodds (39:06.894)
Mm-hmm.

Aaron (39:10.479)
Okay, well, that hurts my feelings. First of all, like you can say that I'm frustrated. And then after you calm down, think about like, okay, this person is just like me, they just want to do their job and go home at the end of the day. And like, how can I put myself in their shoes where I was trying to do this workflow. And then I hit the back button and you didn't have like an exit intent and I lost all my work. Yeah. Yeah.

Kent C. Dodds (39:36.29)
That happened to me like an hour ago. It was very irritating.

Aaron (39:38.973)
It's frustrating, super frustrating. And then you just kind of like, you have to develop that empathy for the other humans that are actually using the thing. And that can be like proactive empathy. You can think, okay, well, if they're like at the end of this form, and they hit back, they should know they shouldn't hit back. But out of love and care for the user, I'm gonna give them a little warning here instead of something that I think engineers

can fall victim to is, well, you should have known. That's how it works. That's technically correct. And I think you kind of have to start to let technically correct go out of your mind as you move into product and away from pure implementation. A unit test that is technically correct, that's great. That sounds awesome. A product that is technically correct but makes everyone furious doesn't matter. You lose. Game over. And so I think moving more towards the product side, you have to think

Kent C. Dodds (40:12.354)
Yeah.

Kent C. Dodds (40:19.736)
Yeah.

Aaron (40:38.139)
All right, well, it's not technically pure, but it is way more usable if I surface this thing in two places, even though it's still just one model entity or whatever. If they're looking for it here, yeah, maybe I should put it there as well. And so having that sort of like human to human interaction, even if you're not sitting right next to them, like I had the benefit of.

Kent C. Dodds (40:59.404)
Yeah, yeah, it does require a significant amount of empathy for the user. actually it makes me think of that Design of Everyday Things book again where he says that it's just really easy for us to say, well, like just read the manual or human error sort of thing. And actually even the human who made the error kind of assumes that they were.

in the wrong and they admit like, yeah, I shouldn't have done that. Like I know it's, you you're supposed to right click, not left click, whatever. But a product engineer sees things like that and they assume fault. They assume responsibility and they say, I'm gonna make it so it's impossible for the dumbest user to use this wrong.

Aaron (41:33.137)
Mm-hmm.

Aaron (41:45.873)
Yep. And I don't know if it's true or if it's apocryphal, but there's a story, and I'm going to say it as if it's true. There's a story about Disneyland or Disney World, and people kept cutting across the grass. And so the maintenance person came to the big boss and was like, hey, can we put up a fence here? Because people keep cutting across the grass here. And the big boss is like, no, we need to put a sidewalk there. We need to pave it. Like, that is what the people are expecting to be a reality. They think to get from A to B, I walk this way.

And I think those are maybe called cow paths where it's like, this is where the cows walk. This is where the people go. And so instead of like erecting these barriers because it's technically correct that the sidewalk goes that way, we should give them an affordance to do the thing that everyone is naturally trying to do. Let's make it easier instead of saying, no, there's a fence here. Technically you gotta go that

Kent C. Dodds (42:17.89)
Hmm.

Kent C. Dodds (42:38.986)
Yeah, that's very good. Aaron, as we wrap up here, I'm going to ask you here in a second for one practical thing that people can do to improve their product sense. But before we get to that, is there anything else that we didn't really touch on that you were kind of hoping we would?

Aaron (42:55.613)
No, not really. I mean, I think between the two of us, we're as optimistic as they come and we've both had our doom days, but I really do believe that like the industry is changing, but it's not dying. We just have to adapt, but that's okay. That's what we've been doing since you mentioned Angular, which is a thousand years ago. Like we've just been doing this for forever. And it is a little...

Kent C. Dodds (43:17.751)
Yeah.

Aaron (43:22.501)
It's a little hard to be like, guess I'm not a software crafts person anymore, but maybe I could be a product crafts person. And that feels pretty good to me. And so I'm sympathetic to the people that are dooming and are like, love to code. And I think there are other things that we will grow to love as time progresses on, but it's definitely topsy turvy, but I feel a little bit optimistic.

Kent C. Dodds (43:31.116)
Mm-hmm.

Kent C. Dodds (43:50.102)
Yeah, I think that's good. And I think that the thing we should fall in love with is the problem. Fall in love with that problem. That was very clear from your, like how you created Solo is you loved the problem. Well, you actually hated the problem, but in such a way that you decided to produce a solution that is actually making you money right now. And you've got customers who actually care. And that is a really special thing.

Aaron (43:55.697)
Mm-hmm.

Aaron (44:04.517)
Mm-hmm. Mm-hmm.

Aaron (44:14.127)
Mm-hmm.

Mm-hmm.

Kent C. Dodds (44:19.278)
And I think you only get customers who care when you care for the customers. so, yeah, thank you for sharing some of your insights and wisdom with us, Aaron, today. What's the best place for people to keep up with what you're doing? yeah, if they have any follow-up questions or anything.

Aaron (44:28.358)
Mm-hmm.

Aaron (44:35.357)
x.com, the everything app. And as we mentioned at the top of the show, Aaron D. Francis is my handle there. So you can find me on Twitter at Aaron D. Francis.

Kent C. Dodds (44:46.562)
Fabulous. Thanks so much, Aaron D. Francis, and thanks everybody for watching. We'll see you in the next one.

Aaron (44:51.623)
See ya.