Kent C. Dodds (00:01)
What's up everybody? It's Kent C. Dodds again. I want to talk with you all about becoming product engineers and with me is my friend, Jaiman Holmgren. How are you Jaiman?

Jamon Holmgren (00:11)
I'm doing well, thanks for having me on Kent.

Kent C. Dodds (00:13)
I'm thrilled to have you. We go way back. Goodness, we probably met back, was it maybe React Rally 2015 or something?

Jamon Holmgren (00:16)
Yeah.

It was in that I wasn't at React Rally, but I know that we had you at my conference, Chain React in 2017. that's, wow, that's almost a decade ago. That's crazy.

Kent C. Dodds (00:31)
I

know, time flies, man. And so it's been such a pleasure to know you and I feel like you're a very down to earth practical person. And ⁓ with the amount of experience that you've got, I think you have a lot to share with folks about being excellent product engineers. So why don't you give yourself or our audience a little bit of an intro to you to fill up their context window a little bit.

Jamon Holmgren (00:35)
Yeah.

I like how that works for AI agents as well as people. So I'm Jamin Holmgren. I'm one of the founders of Infinite Red. We are a 30 person consultancy. All we've done is React Native. I go way back to coding. I'm 44 now. I've been coding since I was like 11 or 12. Started with BASIC on Commodore 64 and Apple IIEs in our

in our elementary computer lab. And, you know, kind of always, I just loved it from the very beginning. And I, and I've been writing code ever since, mostly made little games and stuff as I was a kid. And then, but didn't really, you know, think that I was going to do it as a career until, until I was, I was 23. You know, the websites were becoming more of a thing. was

2005 ish and people were shifting like small businesses were shifting from advertising and like the yellow pages to like I guess we need to have a website and so I would I started building websites for for various you know people that I knew that my dad knew you know people like that and Doing them for just a little nothing, but to me I just felt like wow people are paying me to do this thing that I do for free. That's crazy and

Kent C. Dodds (02:18)
Yeah, it really

is. love this.

Jamon Holmgren (02:22)
I know, right? Like we got a good gig and it was just a lot of fun. So ended up building a business, a consultancy. Started obviously with web, doing a lot of PHP and technology like that. Switched over to Ruby on Rails. Eventually started doing some iOS programming, native programming. And then from there, when we started Infinite Red 10 years ago now, ⁓ it was all in on React Native.

Kent C. Dodds (02:52)
Yeah.

Jamon Holmgren (02:52)
So

I have four kids. My oldest is 21 and he has, he's also a programmer and he has a little family himself. He's married and has a kid. I'm a grandpa as well. And she's almost a year and a half, which is, she's just amazing. ⁓ Every time that she comes over, she just lights everything up. So that's, that's kind of me. I live in the Pacific Northwest. I play some rec hockey as a goalie. ⁓

Kent C. Dodds (03:04)
Wow.

Jamon Holmgren (03:18)
I'm making a game right now. It's a combat helicopter game called Gunship Origins. It's published by MicroProse, the legendary company from way back, which is a dream come true. And trying to keep up with everything. It's a lot. Yeah, yeah, yeah. It's a little too busy right now trying to scale back on some things.

Kent C. Dodds (03:28)
That's cool.

⁓ yeah, you're busy.

So ⁓ with Infinite Red, like over a decade now, ⁓ let's dive into that a little bit. So what is Infinite Red? What do you do ⁓ as a company? And the reason I wanna dive into this, I'm not just advertising for my buddy's company here, ⁓ but there's a specific reason that I thought that you could provide a lot of ⁓ value on how to be a good product engineer because of what you do at Infinite Red.

Jamon Holmgren (03:46)
Mm-hmm. Yeah.

I appreciate that. Yeah.

it

Yeah, it really goes back to my first company when I was 23, uh, cause I ran that for 10 years and that was a consultancy and we were building products for people. And, I really felt like in the very early days, I was doing a lot more product because people didn't know what was even possible with web. Like they didn't know that you could build web apps. You know, that wasn't really a thing or you built a website, right? Like that was it. And then it's like, Oh no, you can actually build the web web app. Um, that's when like base camp started coming in and

Kent C. Dodds (04:27)
Mm.

Jamon Holmgren (04:40)
these types of ⁓ SaaS type ⁓ applications. so, one of my earliest projects that I did, I think it started in like 2007 or so was a, ⁓ actually I play hockey hockey with this guy still to this day, ⁓ you know, 20 years later. ⁓ but he, ⁓ he wanted like a dashboard to manage his sales and stuff like that. And so he was doing a lot of the product work, ⁓ kind of thinking what he wanted and everything, but I would add.

A lot of details myself. I added this really cool chat feature and notes feature and stuff. And they still use this to this day, which is pretty cool. I'll come back to that because he's rebuilding it now himself with AI, which is very cool. He's not a programmer. ⁓ yeah, it's just a really cool idea. ⁓ but then, you know, bring it forward to infinite red. I'd run it, my company and by myself, it was like 14 people ish, something like that. ⁓ and it was, it was very stressful as a lot, to try to.

Kent C. Dodds (05:17)
Nice.

Yeah, that's interesting.

Jamon Holmgren (05:39)
run everything myself. And so I ended up merging with another company that was a competitor at the time. ⁓ And so Todd Worth and Gantt Labord are my business partners. And we decided to really specialize in React Native and mobile in particular. it's interesting because, yeah, I've worked with many different companies over the years. ⁓ With the new Infinite Red, we really moved up market and started working with bigger companies, more enterprise, more, ⁓ you know, like

mid-cap to enterprise type of companies. And the bottleneck often for us in particular, lot of, in a lot of projects, you know, the bottleneck is the programming. It's like, want to really optimize for reducing the amount of time, at least this was true up until recently, where you reduce the amount of time that the programmer has to spend coding because it's so costly to tear things out and redo them and everything. so.

Kent C. Dodds (06:25)
Yeah.

Jamon Holmgren (06:35)
⁓ what we, what I've noticed over the years is that there are plenty of companies that don't really devote enough resources or talent to the product side of things. And as a programmer, you do end up having to do that a lot, but it's really tough to balance that with being highly technical because that's its own full time job to try to be good at programming.

Kent C. Dodds (06:49)
Mm-hmm.

Jamon Holmgren (07:01)
is and to be productive at programming. Even if you're doing stuff that you've done many, many, many times, I mean, there's tons of things that we've done over the years building project generators or things like component generators or a lot of open source libraries are attempts to just like, we've solved this problem many times. Like, why can't we just have something prepackaged out there? Let's pull it in and not have to solve this problem.

Kent C. Dodds (07:04)
Mm.

Jamon Holmgren (07:29)
once again and spend a bunch of engineering time on it because engineering time is expensive and it's really tough. so product a lot of times was under invested in relative to that. ⁓ And I'm sure we'll get to it, but it feels like now people are kind of waking up to that. Like it's now just so obvious that that product is the bottleneck and often the difference between doing things well and not doing things well. In fact, this brings to mind

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

Yeah.

Jamon Holmgren (07:59)
prior to being in tech, actually did home design. And I would often lament to my wife that ⁓ people will kind of cheap out on home design ⁓ before building like a many hundreds of thousands of dollar house, you know? They're like spending all this time and you can't just change it. Like it's not easy to change a house. And I'm like,

Kent C. Dodds (08:18)
Yikes.

Yeah.

Jamon Holmgren (08:25)
Why aren't they spending more time on design? Like sit there and actually figure out where all of your electrical outlets should go. It's hard to do afterwards. So just figure it out, like spend the time, but people won't do it. And it's a lot, that's, that's kind of product, you know, design product engineering as well.

Kent C. Dodds (08:31)
Mm.

Yeah, wow. So many things I wanna dig into that. ⁓ But I actually really appreciate the ⁓ relation to home design because I think that this is a very similar thing, despite the fact that in software, you really can just rip down the wall and do something again and it's little less expensive. ⁓ But when you're doing that, you can't be doing other things. And so like it does matter. ⁓ One thing that...

Jamon Holmgren (08:43)
Yeah.

Kent C. Dodds (09:07)
or specifically stood out to me or thought that I had as you were talking, it seems like ⁓ with implementation becoming so much easier, cheaper, faster, ⁓ developers of all shapes and sizes or in companies of all shapes and sizes are ⁓ kind of becoming a little bit more like the consulting company where ⁓ that

that bottleneck of getting the product right becomes a lot more important. Yeah, what are your thoughts on that?

Jamon Holmgren (09:46)
Yeah. Yeah, that's true. It, you know, for us, like,

We're definitely putting a lot of thought into how we make this transition as well ⁓ as consultants. ⁓ Because what we've really built the company on is, engineering, selling engineering time and expertise and in a particular vertical. And ⁓ while I think we have some level of, of protection against that, just by the nature of React Native's hard and mobile's hard and it's not as maybe well known. ⁓

Kent C. Dodds (10:20)
Mm.

Jamon Holmgren (10:23)
It still is going to be a transition for us, but there are definitely parallels here where you're, you're almost looking at the agents as consultants in some ways, and you have to be thinking about how you're managing their time or managing their, ⁓ you know, their productivity, I guess, not so much time and, and how do you interact with them and how do you ensure quality and all of these things? There's a lot of similar aspects to consulting there. and, and there's some,

consulting companies that will have internal resources for this. Like they'll have, ⁓ you know, business analysts and ⁓ product people and design and all of that. In fact, that's what my first company had a little more of. We were still pretty programming heavy, but we did have some of that. ⁓ Where...

Infinite Red is really, it's like all programmers pretty much except for some support staff. So there's definitely a transition happening here and I'm seeing some parallels, like you said. I'm actually really curious what you think about this too, because I'm, I'm trying to, I mean, we had a phone call like, I don't know, a month or two ago or something where, where we chatted a little bit. Cause I was just like, I want to, I want to know what you're seeing, you know,

Kent C. Dodds (11:44)
Yeah, like this transition, of course, is changing things for everybody. ⁓ I think, though, that I think everybody's going to be OK. ⁓ For the experienced engineer, ⁓ there are elements of our technical expertise that really just don't, they're not valuable at all, not even a little bit. ⁓ Like knowing

Jamon Holmgren (12:06)
Yeah.

Kent C. Dodds (12:09)
the right kind of variable name for a variable. I've invested a lot of time in deciding, okay, how do we communicate through the code, the intent and all of that? And I'm sure that there are people yelling at their ⁓ speakers right now like, no, it still matters. It hasn't mattered to me for a little bit, but okay. ⁓ But yeah, so there are those kinds of things that used to matter, but we've always had stuff like that. Like I have a lot of knowledge,

Jamon Holmgren (12:15)
Mm-hmm.

Yeah. Yeah.

Mm-hmm.

Kent C. Dodds (12:39)
that I used to have on AngularJS version one and on Webpack and like all of these things, like we're always ⁓ losing relevance ⁓ in things that we know. ⁓ I don't think that AI is completely eliminating the human element at all. And so ⁓ in this industry, we've always been learning and acquiring new skills. And often those skills are built on top of the skills we had before. ⁓ For a product engineer,

Jamon Holmgren (12:41)
Mm-hmm.

Kent C. Dodds (13:08)
having deeply technical ⁓ understanding ⁓ helps you ⁓ kind of ask the right questions to get clarity to a problem. ⁓ And so like if you've spent your entire career as just a like, take this JIRA ticket and I turned it into an implementation and that's all you know how to do. There are like some things like the foundational things that you're still going to be able to leverage in this future.

Jamon Holmgren (13:33)
Yeah.

Kent C. Dodds (13:34)
⁓ Maybe agents and harnesses and AI LLMs get better so much that those skills don't matter quite as much anymore, but I wouldn't bank on that anytime soon, ⁓ but maybe. But there is a skill that I do think ⁓ you get even as a ticket converter ⁓ in being able to ⁓ convert the incomplete thoughts from the stakeholders.

Jamon Holmgren (14:03)
Yeah.

Kent C. Dodds (14:03)
into

an actual product.

Jamon Holmgren (14:05)
Yes, exactly. Cause you know what a good ticket is and what it, what it isn't because you've had to navigate that from the other side. And so you can kind of look at it and say, would this be enough information for me? ⁓ would this be enough information? I spent a lot of time writing specifications actually, like, ⁓ I published a thing called night shift on my, on my website. ⁓ which basically is kind of how I like to work. And a big part of it is that I'm not.

Kent C. Dodds (14:12)
and

You

Jamon Holmgren (14:34)
Like I'm, I'm, I'm writing a lot of the specs myself, like to where I would be able to implement. Like I, I know enough about it. Now it's not, everybody wants to go that deep and it depends on the type of software too. Cause there's some stuff I just never look at the code. could barely even tell you what stack it is. and then, and then there's things like, I mean, you know, my game and then certainly client projects where the quality of the code still matters to me. And.

Kent C. Dodds (14:46)
Mm-hmm.

haha

Mm-hmm.

Jamon Holmgren (15:03)
long-term maintainability and even

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

Jamon Holmgren (15:06)
just making sure I've covered my bases, you know, as fully as I can. so knowing what, knowing the implementation side has been very, very helpful there, but it is hard though, because I think, I don't think I've ever been just a person that takes a ticket and turns it into, like I've always had some input to give and that's what my clients have liked. Like they've liked the fact that I'll be...

Kent C. Dodds (15:30)
Yeah, that's what they pay you

for.

Jamon Holmgren (15:31)
Yeah, exactly. It'll be like, did you think of this? Did you think of that? What's hilarious is now I find myself. Appreciating that about the agent when the agent says there's a good plan, but you're missing these parts, you know, because I still run an agent on it. And even if I've spent like four hours on a specification, which I do, it always finds holes. It always finds things that I'm missing. So I appreciate that about, about it. It is kind of, I don't know, like nobody really knows the future right now. Like how far these things will go or.

Kent C. Dodds (16:01)
Mm-hmm.

Jamon Holmgren (16:01)
or,

or how fast really, cause it's maybe, maybe it's inevitable that it's heading a certain direction, but it's, it's more about how fast it's happening. ⁓ and then the skills are definitely changing. even think about for my own game, like would I hire a programmer if I had the budget to just hire a programmer for my game? ⁓ I would hire a programmer, but not to program. Like I would love to hire my son to come help me with the game, but I want his like,

Kent C. Dodds (16:09)
Mm.

Hmm. Hmm. What do mean?

Jamon Holmgren (16:31)
game design, I want his product knowledge. I want his ability to maybe just test things and even just look at the code and see if it's good. It's that cross-section between, I love that he has coding experience and knows good code from bad code, but I don't really need him to code. That's not the bottleneck right now. I'm not coding a lot. I'm doing some, it's usually where the fact that I'm using Godot and it's not as, LLMs aren't as good as.

as they are at TypeScript or Python. ⁓ That's really where the only place that I'm really applying a lot of the direct coding knowledge. But yeah, I it's not like I still do things like, I will sometimes rename variables or things like that, but that's really just with an eye toward the future of like, okay, I know that this variable, if it conveys intent properly, ⁓

Kent C. Dodds (17:10)
Hmm.

Jamon Holmgren (17:28)
The LLM is less likely to just do the wrong thing. And that's really the only thing I care about. What's hilarious is I would never name them that for myself. My coding style and my preferences are actually different than what I do for an LLM. Yeah, I'm really short and cryptic with variable names and people hate it, but it's just how I I optimize code for scanning, like for vertical scanning. I like wide lines that go really far to the right that do one thing.

Kent C. Dodds (17:38)
Mm.

That's interesting. ⁓

Hmm.

Jamon Holmgren (17:58)
So I can just scan and find one thing. And then if I need to drill deeper, go to the right. So many programmers hate this, but this is just how I do things.

Kent C. Dodds (17:59)
Mmm.

That's interesting.

Yeah, I think I would hate that too. But good thing we don't have to look at the code as much anymore.

Jamon Holmgren (18:09)
No, we don't have to. Yeah, it's fine.

Like let the LLM put, you know, 400 short lines in there. That's fine.

Kent C. Dodds (18:17)
Yeah. So you mentioned you'd be interested in hiring your son and that made me wonder, I mean, of course he's your son and you'd love that too. ⁓ But ⁓ as far as like hiring a developer to help you on your game for their like product and testing and stuff, it made me wonder, is that kind of just a stop gap? Like will agents, and you mentioned earlier also, like you like it when the agent asks you, hey, did you think about this and that? And that's like,

Jamon Holmgren (18:22)
Mm-hmm.

Yeah, yeah.

Mm-hmm.

Mm-hmm.

Kent C. Dodds (18:44)
kind of a product engineer skills to like forecast into the future what problems there could be. And I've definitely noticed this myself as well. So do you think that there is something uniquely human ⁓ that agents will never be able to replace or will agents eventually be able to just be product engineers?

Jamon Holmgren (18:48)
Yeah.

I think there's something uniquely human that agents can't fully reproduce. ⁓ and we see this when we, give the agents the happiest path we can, where it's like the thing that they're the most trained on the most, the best possible solution, you know, they know this stuff. It's not, you don't have to provide a lot of guardrails. do it in the happiest possible path.

And, but if you don't provide the right kind of guidance, you end up with something that is just not that compelling, not that good. ⁓ maybe there's some things that they'll do that like is cooler than maybe you would have come up with. So it's probably a little bit of a dance between the two. ⁓ but as an example, right now, so I actually, ⁓ tried, Matt Pocock has this thing where you can do this, like,

Kent C. Dodds (19:52)
Hmm.

Jamon Holmgren (20:03)
I forget what it's called. I think it's a skill where like ask you a bunch of questions. yeah, it's that, that grill meat. Yeah. And, and, and I used it to, see, you know, like how far I could go with this. I found that I'm sitting here making all these product decisions, just one right after, and now, know, just, it's asking me these questions finer and finer grained. I got very exhausted doing it. It was all good. It was like good, but it was exhausting work. And it was stuff that I

Kent C. Dodds (20:07)
Grill me.

Yeah.

Hmm.

Jamon Holmgren (20:32)
I think there were some times where I would just say, what do you think? And it would, could make a decision, right? And maybe there's some of those things that could. Um, but a lot of times it wouldn't make the right decision. And maybe there's a point where it would, but I don't understand where it would get that information from, because this isn't stuff that's like common training data. You'd have to really find some way to extract that from the human experience. And I think there's like us, like we're, we're, we have the advantage of being human.

Kent C. Dodds (20:37)
Uh-huh.

Jamon Holmgren (21:01)
The AI does not and never will. It can be trained on human stuff, but it's always a window into what a human is and what a human likes. And I think that our, ⁓ the fact that not, of course, not every human has great taste. ⁓ You know, that would maybe apply to everybody. Maybe it's great taste for themselves, but not to everybody. ⁓ And so, so there's, there's that aspect as well. But we do have an, you know, like this sort of intuition that we can apply to this stuff. And so when I think about it, like,

Kent C. Dodds (21:03)
Mm-hmm.

Hmm.

Jamon Holmgren (21:31)
If I hired Cedric, my son, said like, go make ⁓ the dynamic campaign really, really good. And we just had just an amazing AI that could just take these grill me questions and just kind of like roll forward with it. ⁓ I'd need him to do that. I don't have the energy to sit there and answer all of those questions. And I don't think the AI is going to answer those questions the right way or the way that I want it to all the time. ⁓ So that's, that's my.

Kent C. Dodds (21:52)
Hmm.

Jamon Holmgren (22:00)
conjecture where I'm at, don't think it's, I think it's actually going to get more important because ultimately there's a lot more software that should exist in the world. Weirdly people like, you know, it sounds weird, like, wow, there's too much already. No, that's not true. There's we, we in the programming world are over-served by far. We have the coolest toys and we always make the coolest stuff for ourselves. when programmers come up with, with business ideas, it's always something to do with better programming or better, you know,

Kent C. Dodds (22:10)
Okay.

Yeah

Jamon Holmgren (22:29)
All those types of things. And I'm no different. mean, I have a consultancy. That's what it is. We do programming. ⁓ but, ⁓ but you just go ask your brother in law who works at a car dealer or something and say, how good's your software? And just watch them go. It's so bad. Everybody, everybody in every industry is like, this software is so bad. It just has the dumb. I mean, my brother works at a home builder and he said that his software like two.

Kent C. Dodds (22:45)
Yeah.

Jamon Holmgren (22:59)
To maximize the screen, you have to click a button, watch it grow a little bit and refresh. It's slow. You have to click the button again. And it's just like, you can't just hit a button and maximize the screen. That's how bad this software is. And they pay a lot of money for this. like, yeah, there's a lot of work to be done.

Kent C. Dodds (23:15)
Yeah, there's a lot of opportunities there for sure. ⁓ I think that actually ⁓ being exhausted with those grill me me questions is very relatable. And even if we were to say, you know what, the LLM is gonna get really good at this, it's gonna make the right, make the right decisions and stuff. When you get to the final product, it's probably not gonna be exactly what.

Jamon Holmgren (23:25)
Mm-hmm.

Kent C. Dodds (23:41)
the user wanted, so let's just say, okay, our industry doesn't exist anymore, people are making their own custom software, it probably isn't gonna be the right thing, and so then they're gonna say, hey, here's some more feedback, here's some more feedback, and that process is exhausting, I already do that with things that I'm byte coding, I ⁓ just like, okay, build it, then we can iterate, and that part is exhausting too, and so even if the agents get so good that they're making all the right decisions ⁓ for a,

a given set of assumptions, ⁓ think finding what the right assumptions are is ⁓ maybe something that's uniquely human. ⁓ Maybe not, but at least something that I can say is that that skill was useful 50 years ago, and it's probably the last skill that will continue to be useful as long as our industry is still a thing.

Jamon Holmgren (24:31)
Yeah.

You know, it's, I could not agree more. and, ⁓ so my game is based on a game that was published in 1991. So it's 35 years old, ⁓ called gunship 2000 and, ⁓ it, so the original game designer, Jim Day, I actually, ⁓ have become friends with him and he's, ⁓ so before that he was a board game designer. He had like a regular career as well.

Then he did a few games. He did Gunship 2000. He did like Strike Eagle 3. I think he worked on a couple other things that are really well known. mean, I think he only worked on really successful stuff and he was the principal ⁓ game designer, which is very much like a product designer or product manager type of thing. And so he and I have had multiple phone calls. He just emailed me yesterday. He's going to be sending me the like,

Kent C. Dodds (25:14)
Hmm.

Jamon Holmgren (25:30)
an early, ⁓ manual that they had and stuff. It's very cool. But what's really cool about it is like, I'm very impressed with the programming that was done. is 19, this is the eighties and nineties that they were, that were, they were building this stuff and, and the, programming that they were able to do with very limited hardware and everything is unbelievable. But I'm much more interested in what Jim has to say than the programmer, just cause his.

Kent C. Dodds (25:35)
that's

Mmm.

Jamon Holmgren (25:59)
The way he thinks about things is still so relevant to today. 35 years later, to have such relevancy in, mean, it just underscores your point. It's like, that's really what matters. There's so much taste that has to be put into what the game should be. ⁓ He has very strong opinions about things. ⁓ He would very much like...

stand on like there's a little bit of like a programmer versus game designer back back in those days especially where maybe you know it's probably still today where it was like the programmers would say we don't need a game designer i know how to make a game type of thing but he would be like no we have to have this in the game and it ended up being i mean i think one of the greatest games of all time back in the day it was very very popular it's uh it's kind of a little more forgotten today but

Kent C. Dodds (26:42)
Hmm.

Jamon Holmgren (26:56)
But this is, this is stuff where we're having that taste and having that. ⁓ it's just, yeah, it's very relevant.

Kent C. Dodds (27:03)
Yeah, yeah, I think that we've done a pretty good job establishing how valuable product engineering is as a skill, but I would like to get into like some specific things that product manager or product engineering skills, like what they are, what makes a good product engineer. And so ⁓ one thing that I think is interesting about what you do at Infinite Red and your previous consulting company,

Jamon Holmgren (27:10)
Mm-hmm.

Kent C. Dodds (27:32)
is just the amount of time you spend gathering requirements and communicating with the stakeholders. So can you tell us a little bit about what those meetings are like and ⁓ how you ⁓ manage bringing clarity to this amorphous problem space when often maybe the client doesn't exactly know what they want either.

Jamon Holmgren (27:54)
I'll start with a major failure that I had ⁓ with my previous company. I built this very large MRP, like a manufacturing ⁓ system for, it was cabinets. was like, they had three production lines. It's this local company ⁓ and they would get orders in from home builders as well as just people doing remodels or whatever.

And if you've ever built a house or done a kitchen remodel, you know that kitchens are full of decisions everywhere and you can make a lot of wrong decisions very easily and you can have a bunch of assumptions that are wrong. ⁓ and so there was sort of the sales part of it, which, which I had done previously, but this was the manufacturing part. And I worked with one guy, ⁓ who was fun to work with and he had a lot of great ideas and everything, but.

Kent C. Dodds (28:29)
Yep. Yep.

Jamon Holmgren (28:53)
I kind of just leaned on him to do a lot of the stakeholder gathering, you know, and everything. And that ended up being a pretty big mistake because ultimately a lot of these systems that you build, they fail because of lack of adoption, because people get what you've built and they're like, this isn't what I need. Like my old system's better. And you're like,

Kent C. Dodds (29:01)
Hmm.

Hmm.

Jamon Holmgren (29:17)
this one's so slick and whatever. And they're like, yeah, but you don't have this button that I need, or you don't have this way of doing things that I need, or you've thought about this whole problem the wrong way. And they did end up using the system, but it was only like certain departments. they were the ones that were closest to this guy, the ones that he knew really well. The departments that it was supposed to run all of this stuff and the departments that were not directly involved with providing feedback and you

Kent C. Dodds (29:22)
Uhhh

Hmm.

Jamon Holmgren (29:46)
kind of like getting some ownership, they just refused to use it. And it was like, I can't use this. It's not even though I thought I did a good job. ⁓ and I had a lot of great ideas in there. There's this amazing scheduler, automatic automated scheduler that could optimize the three, like, you know, manufacturing lines, super, super well. it turns out that there were a bunch of wrong assumptions that, that I and the other guy had made. so that pain.

Kent C. Dodds (30:10)
Hmm.

Jamon Holmgren (30:16)
Was was like, okay. you have to go talk to people. You have to get them invested in it. You have to get their feedback and their feedback's not going to feel good because you were like, I, I worked hard on this and now they're telling me that it sucks, you know, and I have to go change it. ⁓ but you have to kind of get, you have to get immersed in that and feel, I mean, honestly, the, product designers and just designers in general that I've worked with that are the.

Kent C. Dodds (30:31)
Hahaha

Jamon Holmgren (30:43)
best are the ones that can really take feedback and incorporate it. It's not necessarily that the ideas that people have are what you just do by rote. It's more that you're hearing the underlying problems that they're having with it. And so the successful projects that we've had ⁓ since that time really involve us like kind of insisting on, know, who are the stakeholders? Let's get this in front of them. ⁓

let's get their feedback and let's also kind of explain the overall vision of, so they can get on board with like why we're doing this. ⁓ And also kind of, you know, it's a lot of human stuff because you have to explain that there's going to be trade-offs. Like maybe in some cases, some departments are going to take a step back. ⁓ Like we just don't have the time to make something better for you, but we're not going to.

take too big of a step back. Like it's going to be as good as we can make it. And the overall vision we're going to move forward with this. then, you know, it can be a little hard sell, but those are the types of things that I think really, really are important. And then just having a broad exposure and some opinions about things like making sure that, you know, I mean, there's, so many little interactions you've seen this kind of like over your career where

There'll be things like tool tips when you hover over a tool tip and you go to the next one, that delay before it shows the next one. It should only be on the first one. Like the next one should show right away type of thing. That's just a little programming thing you have to do. ⁓ there's the, have this one, I have an opinion around a lot of buttons where you click a button and a lot of times there'll be a confirm that pops up in the middle of screen. I like to just change the button into a confirm question mark for like five seconds. Like click again. Right. And.

Kent C. Dodds (32:16)
Yeah, yeah.

Yeah. Yep.

Yeah,

I've got a react hook called use double click or use double check. Yeah.

Jamon Holmgren (32:36)
Yeah. Yeah, exactly.

Like I love that. And I don't see it enough. Like it should exist in more things. I think instead people lazily just throw a confirm up and, and, and, you know, kind of go from there. ⁓ but it's not that much more work to do the double click thing, especially with, with tools like what you've got. ⁓ so, you know, opinions like that, like just shave off the, you know, sand off the sharp edges here and there, make it pleasant, delightful. ⁓

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

Jamon Holmgren (33:03)
Don't like overuse animations, use it sparingly where it needs to happen. A lot of this stuff is, you have to learn design, you have to learn UX, all that stuff. But yeah, so I think it can be from either kind of that, it should sort of be the whole package of like getting people on board, getting all the feedback, being open to feedback, being able to change. And then also, yeah, just having some opinions about how the software should look and feel and spending the time to make it feel great.

Kent C. Dodds (33:32)
Yeah, there's a lot that resonates with me in that ⁓ one thing you were talking about how like kitchens are just so many decisions in there. And I did ⁓ recently build a kitchen. And ⁓ one of the things that I really liked about my builder is that they ⁓ gave us a designer. Like we had an architect and like the general manager liked all that, but we had a designer who was with us at literally every meeting. And so

Jamon Holmgren (33:44)
Yeah.

Hmm.

Kent C. Dodds (34:02)
she was able to ⁓ just gather all of this context into herself of what our preferences were. And so instead of giving us, okay, now we're gonna talk about the position of the microwave. Like instead of giving us 3000 different options, ⁓ which that is how many options you have, not just the position, but like which microwave, all that. And she said, like based on what she knows about us, here are three options, which ones of these do you like?

She knows with the breadth of experience that she has, like if we do it here, then she can tell us, now, if you do it that way, then this is gonna be a problem for this or whatever. And I think that that is the sort of thing that an experienced software developer can offer in that kind of a relationship. We are the liaison between the stakeholder who doesn't have the technical know-how and the agent that is going to ultimately be building this. And of course, like we're gonna be ⁓

taking part in that process as well. But that gap, think, ⁓ it's not closed now, that's for sure. And I think that that will remain open and valuable going forward.

Jamon Holmgren (35:15)
Yeah.

Yeah, I agree. I see it as like our workflow. To me, I feel like our workflow is changing to something that looks more in the order of going in and talking to stakeholders, demoing stuff, testing things, really kind of writing out specifications and feedback and things like that. And then

going to implementation and making sure that we've thought through how the implementation should work because of our engineering knowledge. That's where we can bring a lot of value to the table. Obviously there are ⁓ existing designers, UX designers, UI designers, and product people who can do a lot of this stuff and are already good at it, right? Like they can already do these things. The unique thing that we bring ⁓ as more kind of product engineers is that we have done implementation by hand.

at least so far, ⁓ maybe there'll be a generation where that's just not true. But for us gray beards, we have that. And so we can come in and translate that between what the stakeholders have and the implementation side of things. And then our workflow then, okay, it goes into implements. ⁓ I'm a big fan of...

Kent C. Dodds (36:14)
Mm-hmm.

Jamon Holmgren (36:36)
writing out, having good enough docs, having good enough validations and tests and, linting and all of these things, ⁓ MCP servers, like you've been working on some cool stuff. you know, whatever we can do to make the agent's job or agents turn around better work, putting our time into that and making that really, really, really good. ⁓ and then, ⁓ kicking off the agent, making sure that it,

has what it needs and then coming back afterward and doing a bunch of, ⁓ rather than kind of the interactive stuff, which is kind of exhausting in its own way. then come back, review it, you know, do our own tweaks and then go back to stakeholders demo again, get feedback again. And so there's a cycle there and, ⁓ however long that cycle is, whether it's weekly, probably more like daily because of the speed that we can go now. and, ⁓ but also not too fast. Like I think there's a temptation.

Kent C. Dodds (37:27)
Mm-hmm.

Jamon Holmgren (37:32)
because of how intoxicating the speed is to skip steps and just be like, I'm going to skip this step. I'm going to skip that step. ⁓ I wouldn't skip steps. It's okay to be five times as fast. You don't need to be 10 times fast.

Kent C. Dodds (37:34)
haha

Yeah, definitely is intoxicating. That's for sure. I Pulled a couple all-nighters and I have not done that in a long time and it's not because like I'm under the gun or anything like that It's just it's so fun

Jamon Holmgren (37:52)
Right?

No,

it's so much fun. Yeah. I not to not to like shill my way of doing things too much because I do think everybody has to find their own way. But I the sort of night shift way of doing it is the only thing that's allowed me to just have a moment that's fun leaving because that's when I kick off the agent. It's actually fun to leave work. And so I've got everything lined up and I'm like

Kent C. Dodds (38:18)
Hmm.

Jamon Holmgren (38:24)
I'm going to kick it off. It's fun. It's I've got 25 things for it to do. I've got 10 things for it to do. And then in the morning I get in and it's fun because now I'm opening the present of like, what did it do? You know, and maybe it did it bad, but a lot of times it does good stuff. And then I'm reviewing. So there's, that was the thing I had to do for my personality because otherwise I'd stay up all night. I was exactly the same as you. Like I, I got to keep these going. I'm, met dinner with my, with my kids, my wife or whatever. And then I'm like running upstairs to like, Claude's not working right now. It's like, on, you know, like I don't like that.

Kent C. Dodds (38:33)
Haha.

Yeah.

Yeah, my problem is cursor cloud agents make it so that I can do this from my phone. so wherever I am, just like pull out my phone and let me see how this agent do.

Jamon Holmgren (39:05)
Yeah, I have,

I've mostly resisted that. There's a couple of times where I've had some things going like that, but I actually intentionally was like, if I put this on my phone, I'm never putting my phone down. I gotta stop. I gotta have some place to stop. I know my personality.

Kent C. Dodds (39:15)
Bye!

Yeah, yeah. Well, it is fun. And I think also like we talk about us experienced engineers having a lot of value to offer. I think like there are people in the last even just a few months. That's a lot of people who've started in the industry who don't know a different world. I think that there is still a place for juniors in this industry. ⁓

And in the same way that when we were juniors, we accumulated knowledge and began to deliver actual value, they will also accumulate knowledge. Now the challenge is they may not know ⁓ how bad the decisions they're making are. And it's much easier with AI agents for those decisions to actually result in some very seriously bad outcomes because you can just get so much further now. ⁓ But I think that... ⁓

⁓ that is going to improve. I'm not terribly concerned about that. So if you are new in this industry, ⁓ is just fine. And actually I should say you can be new and be gray haired too, so welcome. If you're a career switcher. ⁓ One thing that I thought was really interesting about the story you mentioned earlier was that you had this guy who was very in touch with a handful of departments and then

Jamon Holmgren (40:30)
Sure. Yeah, absolutely. Yeah. Yeah.

Mm-hmm.

Kent C. Dodds (40:46)
kind of use that knowledge as a proxy for these other departments ⁓ and that didn't work out very well. And so ⁓ one thing that you called out specifically is that you have to ⁓ talk with them and engage with them in such a way that they are bought into this thing that you're building. And I think that's an important thing to call out that depending on the product that you're building, sometimes ⁓ you're selling to the...

the boss and then they're gonna make all their underlings use the software. And your goal really should be to help those underlings be successful, even though the one you have to sell to is the boss. ⁓ And so like, how do you make sure that when you're having these conversations, you're inviting all of the stakeholders rather than just the person who's gonna be buying it from

Jamon Holmgren (41:25)
Mm-hmm.

Yeah, that's a great question. the way that I've done it is to tell the boss that many of the, the, the ones that I've been a part of that have, either failed or just kind of had a rough, rough go of it, ⁓ are the ones where I'm not allowed to talk to people and where I'm not allowed to go talk to people that I need to talk to it is to get their feedback.

Kent C. Dodds (41:55)
Hmm.

Jamon Holmgren (42:00)
The ones that go really well are when I can involve people. That doesn't mean that the boss's opinions don't matter. They obviously will matter and they will be the key stakeholder and that's totally fine. But if you want your people to adopt this software and to feel like they have some ownership there and actually use it, ⁓ then I have to be able to talk to them. And that goes really well because it ties it to sort of like, it's not that I don't trust their judgment.

but I want this project to succeed, do they. mean, ultimately with consulting at least, a lot of times this is just them wanting to feel like they made the right decision in hiring us and feel like we're gonna make them look good, you know, in front of their bosses, in front of their stakeholders, in front of their team, whatever, that they brought in this really amazing team. ⁓ And now obviously,

We're not a huge company. We're a little over 30 people, but at this point I can't be that involved with every project. and, and it's not even really my role anymore. ⁓ that's, that's really more my, my business partner, Todd and, ⁓ Gantt does sales and I'm more on the tech side and, kind of working with that. ⁓ but this is what I try to try to, you know, like teach our team that what they need to be doing. ⁓ it's, know, no matter what though, you can't change.

Kent C. Dodds (43:03)
Mm.

Jamon Holmgren (43:26)
company culture from the outside. ⁓ It's even hard to do from the inside, especially if you don't have, you know, that sort of agency. And so I always say it starts at top. You have to have good leadership. You have to have, you know, good communication, good culture. Those things start at the top, like what will the leader tolerate versus what do they not? And so you can only do what you can do. But this is how I've approached it as a consultant and it's typically worked pretty well.

Kent C. Dodds (43:28)
Hmm.

Jamon Holmgren (43:55)
There have been some projects where we're just simply not allowed to talk to people we need to talk to. And it's like, they're willing to pay us for months and months and months to do less effective work because they just won't let us talk to people. well, you know, as long as they're making that decision, knowing the trade-offs that they're making, then I guess that's on them. But that's how I approach it.

Kent C. Dodds (44:01)
Mm-hmm.

Yeah, that makes a lot of sense. ⁓ That leads me to another thing I was wondering. ⁓ How do you deal with bad requirements? ⁓ Like you're in meetings with stakeholders, maybe they're really enthusiastic and we're talking about building an MVP and they have all of these huge ideas that they wanna do and you're like, man, adding that integration is going to add a lot of time to this and a lot of complexity and we're not even sure if we understand this problem space quite right. you're ⁓ often ⁓ in my experience,

Jamon Holmgren (44:41)
Yeah.

Kent C. Dodds (44:51)
people will just throw a bunch of solutions at you without actually really you understanding the problem and knowing that that like, so what do you do? How do you deal with bad requirements?

Jamon Holmgren (45:03)
So the thought that came to me as you were asking this is as a dad and you're a dad as well, I have one daughter who really loves stuffed animals and if it was up to her, she'd have 200 of them. And so when she wants a new one, what I tell her is, okay, which one are you going to donate to someone else? So now it's not so much like a decision about do I want this or not?

Kent C. Dodds (45:27)
Nice.

Jamon Holmgren (45:33)
Cause obviously she does. It's relatively, you know, it's balancing against the trade off of what else has to go. Cause there's only so much room in her room. And, um, and so they'd be similar for like a backlog or something like that. It's like, I mean, I'm okay to be in like, it's a great idea. You know, your users, you know what you want. Like that's awesome. That's a really cool thing. Where does this rank? What does this push below the line? What won't get shipped? That usually gets them thinking like,

Kent C. Dodds (45:41)
Hmm. Hmm.

Jamon Holmgren (46:03)
Wait a minute here. Let's put that in phase two. Ends up being phase five, but you know, let's put it in phase two. ⁓ that's within the constraints. Now, you know, I think it'll still be a thing even with, you know, faster velocity with agents. We can't just have it all because it's not just the agent. It's obviously it's QA, it's product, it's design, it's all the...

Kent C. Dodds (46:06)
Hmm.

Mm-hmm.

Yeah, well, and I think

a really important piece to that too is that ⁓ if you just try to build it all upfront, you'll get to the end and realize you built the wrong thing. And so by doing kind of a phased rollout, once you get there, you're like, ⁓ actually we should be doing it this way instead.

Jamon Holmgren (46:33)
Yeah.

Yeah, yeah, with my game, I ran into that even with all my experience. You know, the game is really the first product where I have spent multiple years now thinking about and working on and owning 100%. And there were early things that I spent a lot of time on that when I eventually got to where I knew what I wanted, the early stuff didn't really, it was kind of a waste of time. Like I should have focused on.

the stuff that I knew needed to happen and not like future proofing or building out this big system for various things. Cause I ended up removing a lot of it. I've rewritten the lobby system. ⁓ I think it's 11 times now and I'm not, that's not an exaggeration. It's actually 11 times. I'm pretty sure. And that's crazy, but I started too early. I did it way too many times. And then now I've only maybe rewritten it twice in the last six months. So that's good. And I'm pretty happy with what I have.

Kent C. Dodds (47:34)
Yeah, making progress.

Yeah, that makes me think it's a very similar sort of thing as premature optimization, right? So like, we're going to build out the infrastructure of Facebook or something like you're not Facebook scale, right? ⁓ I think that there's this concept of premature ideas where like this idea, maybe it's a great idea. like often I think we're like, no, I know.

Jamon Holmgren (47:46)
Yeah, right. No.

Mm-hmm.

Kent C. Dodds (48:01)
these users, I know this situation or whatever, but maybe this other thing that you're working on that is totally unrelated ends up being a better primitive to solve that particular problem than the solution that you thought of in the first place. ⁓ focusing and iterating, ⁓ tightening the feedback loop, all of that, I think can help you avoid going down ⁓ a path of a premature idea.

Jamon Holmgren (48:27)
Yeah, I have an example of that in my game. So I have ⁓ AI pilots, NPC pilots, because AI is overloaded now. But when you're flying in Apache, you'd have two pilots, pilot and co-pilot. And either one of them can be an NPC, MCP, an NPC that ⁓

that, ⁓ or both of them can be. And in, depending on what seat they're in and like what the responsibilities are, they actually coordinate with each other or they coordinate with you, the human pilot, ⁓ or you can have two pilots, two human pilots. ⁓ so there's a lot of different kinds of ways that this could be structured. And, and I had all these ideas around how I was going to make them more or less effective based on maybe stress, ⁓ maybe their

health, you know, or, ⁓ or their experience level or, some hidden attributes sort of like Madden or NBA 2k or something. There's like these attributes of like, how good are you at shooting the gun or whatever? and ultimately a lot of that, like what you said about like, there's a better primitive. I had built this distraction thing that would kind of like, they have this like decisions decision loop that they're running.

Kent C. Dodds (49:29)
Hmm.

Jamon Holmgren (49:53)
And there's a percentage chance that they'll get distracted and do nothing. Like they won't make a decision, right? They're supposed to shoot and they don't. They're supposed to make, you know, target something new. They don't. They're supposed to punch out some flares to try to confuse an incoming missile. They don't. They got distracted. got whatever. And it wasn't just distraction though, because I found out that like, wait a minute, this can just work for any of these things. Like if they're less experienced, then they get distracted more often. If they're

Kent C. Dodds (49:57)
Hmm.

Hmm.

Jamon Holmgren (50:19)
injured

or they're tired, they get distracted more often. I can just use the same thing over and over and it gets the job done. they react sort of like they're slower to react. ⁓ And so I didn't figure that out until well into the process. And that was, I'm glad I didn't actually go down the route of building out all these other things. That was actually one of the first things I built. And I was like, this can be used for everything. So I totally agree. I think that's exactly, yeah, you, you have to defer these quite, I tell, tell clients like, let's not make decisions.

that we don't have to right now when we know the least. Like we're gonna know more later. So let's make decisions later when we know more.

Kent C. Dodds (50:53)
Hmm. Hmm.

Yeah, I really like that. And this is actually why I often say do it the hard way first. For that exact same reason, the version of you today knows a lot less about this problem than the version of you in the future when you've been wrestling with it manually ⁓ for a while. So I've had a lot of ⁓ family members come to me and there's a neighbor that I've got who came to me and said, hey, I have this app idea, I'm sure.

Jamon Holmgren (51:05)
Mm-hmm.

Kent C. Dodds (51:27)
everybody listening can relate to that. And most of the time I just say, how can you do this without building software? ⁓ Just like cobble together Google calendar and Zoom and whatever else that you need and like a Google form for people to sign up and a Venmo, like just put all those pieces together manually. And once you've confirmed that you have people who are interested in paying customers, whatever, ⁓

Jamon Holmgren (51:29)
yeah.

Mm-hmm.

Kent C. Dodds (51:55)
then you understand the problem and can write software to solve the actual problems that you're experiencing.

Jamon Holmgren (52:01)
Yep, exactly. Yeah, I couldn't agree more. And these are all things that us as engineers are going to have to learn to to make this transition. And there's no doubt there's a transition coming. You can drag your feet all you want and you can maybe try finding companies that will, you know, hang on to low AI or no AI for a while. ⁓ But the market demands are going to change. And and we do need to make this transition. That's why I was

Kent C. Dodds (52:14)
Mm.

Jamon Holmgren (52:31)
actually really excited about the direction you were going Kent. Cause when you were talking about, like you were thinking about, like I could teach like specifics of Claude code or I could teach specifics of cursor or something. And those are important to know, but they changed so often where like, just like Jim Day 35 years ago, doing the game design for this game, still relevant today. He's still giving me good advice today. This is something that feels more durable.

Kent C. Dodds (52:48)
Mm-hmm.

Mm-hmm.

Jamon Holmgren (53:01)
We, nobody knows the future, you know, who knows, maybe there'll be a product designer AI that comes out that just kind of shocks us all or whatever. But, but right now that's really what it feels like. ⁓ there's, there's going to be a lot of value there. And it's not like our engineering knowledge is completely useless, just like all the other transitions we've made in our, in our lives. feel like it's still, still a useful thing, but, but we do need, we definitely need to be making ourselves.

Kent C. Dodds (53:18)
Mm-hmm.

Jamon Holmgren (53:30)
more aware of and more capable of making more product, even if it's at a mini level, maybe you're not doing the full product, but you're taking more high level instructions and again, making decisions at a lower level.

Kent C. Dodds (53:42)
Yep, 100%. Well, Jamie, this has been a super fun and interesting conversation. I want to ask you if there is anything that we didn't talk about that you really wanna talk about. And I'll also wanna wrap up with on the page for this episode, there's a homework section with a little check boxes. So what should go in that homework section? What's something active, like specific that somebody could do? It doesn't have to be big, just a specific action that they can take.

to improve their product sense.

Jamon Holmgren (54:16)
That's a tough one for me because it's still, it's something that I've learned kind of the hard way over my career. ⁓ But I will say, I think the thing that has been the best for me is to actually sit and watch someone who's non-technical try to use a feature that you built. ⁓ And you'll learn a lot. ⁓ Or even if it's not a feature that you built, like watching someone, I watched my wife who is

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

Jamon Holmgren (54:45)
non-technical, she's smart, but she's not like in tech all the time. Try to use some of these apps and the way that she'll tap on something three times before it stops animating or something. And it won't do anything because it's animating and it's not actually ready to like tap on. And, but she just, you know, tap, tap, tap. Okay. Now it went, you know, that's the sort of thing that, that I think you're going to start getting a sense for the user experience and you're going to, you're going to notice things that.

Kent C. Dodds (54:58)
Mm-hmm.

Jamon Holmgren (55:14)
just drive you nuts and it's going to make you better at like, okay, I'm going to make better decisions. I'm going to prioritize things better.

Kent C. Dodds (55:21)
Very good. Yeah, that's awesome homework ⁓ piece of advice there. Jaiman, what's a good way for people to follow along with you and keep up with what you're working on?

Jamon Holmgren (55:31)
Yeah, I'm still active on Twitter at Jamin Holmgren and and you can also ⁓ Follow along with my game development journey at Jammin games ⁓ But also if you're not a Twitter person ⁓ You can go to my website I do post updates there or or steam if you go to steam Jammin games for my for my helicopter game

And then of course, Infinite Red, we're still doing React Native, we're still building mobile apps, all those things. So you can follow along in all of our socials there ⁓ as we navigate this transition as well.

Kent C. Dodds (56:12)
Perfect. Thank you so much, Jamin. Really appreciate all of the awesome insights that you've got and shared with us. And yeah, we'll see you everybody in the next one. See ya. Thank you.

Jamon Holmgren (56:21)
Thanks for having me on Kent. Bye.