Become an Epic Product Engineer is Kent C. Dodds's interview podcast about skills that stay valuable as AI takes on more implementation: product engineering - blending technical depth with product judgment, user empathy, and problem clarity.
Each episode is a long-form conversation with a guest who has shipped real software and cares about building the right thing before making it right. You get full audio, transcripts, structured show notes, homework (one concrete action to try), and links from the conversation.
Canonical home for the show and every episode page: https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast
New episodes publish on Wednesdays (America/Denver). Video is added on Transistor for supported podcast apps when available.
Complements Better with Kent - Kent's solo series on durable skills for people who ship software.
Kent C. Dodds (00:01.068)
What is up everybody? It's your friend Kent C Dodds here, joined by my friend Mark Texan. How you doing, Mark?
Mark Techson (00:06.8)
I'm doing so good. It's so good to talk with you. I'm always overjoyed when we get to spend some time together.
Kent C. Dodds (00:12.1)
the feeling is mutual, Mark. I'm very excited to talk with you about product engineering today on the Become an Epic Product Engineer podcast, where we're trying to learn the most durable skill for software engineers. And my goal in having guests like you on, who are actual practitioners of building excellent products over the you know years that you've been developing software, is just to give people a view of what it means to be a product engineer, to actually engineer a product.
And some of the the pitfalls and shortcomings and problems that you've faced in the in the past. because we kind of learned this over time. There's n nobody really teaches you this in school or anything. So I'm excited to to hear your perspective on this. So Mark, why don't you give us a little bit of some context on who you are, what you do and and why you care about engineering products.
Mark Techson (00:56.235)
That's right.
Mark Techson (01:08.212)
Absolutely. So I I I'll tell people for context, everything that I say today to get when we as we talk together, it'll be based on a 20 year career. I got my first job back in 2006 when I first finished graduate school. And since then I've worked in a variety of spaces. I've taught at the university level. I've worked as a senior software engineer. And most recently, I spent maybe the last five or six years at Google working as a staff developer relations engineer. Well, I just got promoted to staff, but I've been a senior developer relations engineer.
Until last year and then I got promoted to staff engineer. And and so that's what I've been doing. So I've had a lot of time that just in front of a keyboard, in front of a monitor, building things for other people.
Kent C. Dodds (01:47.444)
Awesome. Yeah. And so in all of that time, so like as an educator, staff engineer, what where were some of the like what what are some of the products that you've actively worked on at all the companies over those last twenty years?
Mark Techson (02:00.539)
sure. So at one of my jobs I worked at American Express and I worked on our an internal, it was actually an external fraud tool that we gave to it was like B2B. That's why I called it internal, but it's more a B2B fraudulent fraud detection tool. Spent a lot of time working on that. That's actually where I spent a lot of time learning how to write Angular code, was working on that application. I've worked in the healthcare space where I've built like healthcare exchange web apps where
You know, users would go in to try to find a plan for themselves, right around we when we got the Affordable Care Act. And then people had to be able to go and find plans themselves on on the exchanges. I worked on apps like that. I even had a startup where I worked on a mobile app that I built that it was targeted at a l at users who wanted to be stronger. And I spent a lot of time building a pr and it was really deeply focused on trying to build the right thing for the people that I was targeting.
So is right in line with what you're talking about, this idea of a product engineer.
Kent C. Dodds (03:00.898)
Yeah, let's let's each one of those I actually want to dive into. And and you're even working on Angular, Angular is a product. it certainly was a product that you used at MX. and and what you're doing now as well. I think one of the misconceptions about product engineering is that people think, well, I'm working on an internal services and stuff, lower level things, our end users don't ever see this. So product engineering, that's not my thing.
Mark Techson (03:08.096)
That's correct.
Kent C. Dodds (03:31.052)
what is your take on that? what like should people who are working on internal tools and services care about product engineering?
Mark Techson (03:38.432)
They should, and I think it's a missed opportunity if they only limit themselves to things that they feel like their customers are only external. Because internally you still have people that you have to care about how they use your product. And if you're missing that idea that there's value in you doing, you know, the best job you can, even though it's internally, then you're missing the growth opportunity for yourself because you may not work on that internal thing forever. Right. So what happens when you go to another product where it actually
may have a different user base. So don't so don't even segment yourself on like, well, internal versus external. Just think about just different user bases. And you may have a different unit user base that may be outside of your organization. You still want to be good at building something that they can use.
Kent C. Dodds (04:23.21)
Absolutely. And so let that's what we're here to talk about is getting good at building something that people can use and actually solves people's problems. so I I wanna hear from you a little bit about what product engineering really means to you. What is the like what are the skills different or let's see. We have been software engineers for a long time, you 20 years. the skills that you develop as a coder.
Mark Techson (04:48.01)
Mm-hmm.
Kent C. Dodds (04:52.118)
maybe a little bit different from the skills that you need to engineer a product. And so I'm curious where where the line is there. What are those skills that are specific to engineering a product?
Mark Techson (04:56.267)
Correct.
Mark Techson (05:02.075)
I think for me, the number one skill that I would tell a person right now is to lead with empathy as they are building. And that's something that has set me apart in my career over the last 20 years. Every time we talk about a product, whether it be something. So I work on an Angular team right now at Google, right? And when we talk about new features, I'm always putting myself in the position of the end user. I'm like, okay, if I had to use this, how would I feel? How would this imp how would this change impact?
my business if I were a, you know, a business person relying on Angular or relying on any product. Like I think people forget about the empathy because they build for themselves a lot of times and what they think is right because they're they're like building for an audience of one a lot of times as an engineer. You're like, yeah, this makes sense to me. So therefore it is correct. And I think that's a natural inclination, but I think there's just more to the picture. So when I have built things, you know
in at Google, at American Express, even teaching teaching and building with empathy as like the core foundation has like really made a big difference for me.
Kent C. Dodds (06:11.394)
Yeah, yeah. I think actually being a teacher, I and I'm biased as a an educator, but I I do think that both communicating and ensuring that you have communicated effectively, so you've been understood, and that requires deep understanding. that's kind of a unfair advantage that people who are good communicators have, right? So I really liked
Mark Techson (06:26.677)
Mm-hmm.
Mark Techson (06:36.659)
That's right. That's right. That's right.
Kent C. Dodds (06:40.096)
How you asked yourself the question, if I had to use this, how would I feel using this? And it makes me think of jobs theory. I don't know if you're familiar with this from Clay Christensen, but a the users hire your product as like they are hiring a person to do a job for them. And in in that world or in that like thinking framework, you can
Mark Techson (06:59.353)
Kent C. Dodds (07:07.38)
split up a job statement into like three different categories. There's the functional, emotional, and the social aspects of like, does it actually do the job? How do I feel when I'm doing the job? And who am I working with as I'm doing the job with your software? And so I I really appreciate the user empathy that you're leading with that as like understanding how do people feel when they use it. and that's not necessarily like, well your product stinks and so I, you know, feeling angry, but like I this is
software I'm using in the healthcare industry, you know, like your exchange you're talking about, finding a plan for yourself is stressful and like it's all of the emotions around it will frame the way that you build that. and so my question for you though is why does it matter that an engineer has that empathy? Like can't the product manager just, you know, think about that part and then create tasks for you as the engineer to just go off and implement? Does it change the way that you implement software?
If you are thinking like whether or not you understand how users are feeling when they use your software, or can't you just say, Well, we'll just let the PM do that and I'll I'll take the tickets and turn into an implementation.
Mark Techson (08:18.739)
Okay, so that's actually I love the question, and I'll put it in a different with a different analogy. So in movies, you have your writers, you have your directors, and then you have your talent that's on screen, your on-screen talent. Some of the best things that happen in movies are when all three of those folks, you know, or the three groups are working together toward the same goal. Right. When me as a let's say I'm on an on-screen talent and Kent, you're the director, I'm like, hey, Kent, I just read the scene. What do you think if I did?
You know, XYZ actually turned a little bit to the left right before I deliver the line. I'm still gonna deliver the line, just like you wrote, just like you you're directing. But I want to turn my shoulder just a little bit because I think it's gonna give this emotion to the audience. And you're like, yeah, look at okay, let's try it. And you shoot it, and you like, look at this brilliant moment that was birthed out of my desire to make the best movie possible, right? And not to be the best actor on in the whole universe.
Or not to be the person who gets all the credit. I want the audience to have the best experience possible. I think this will drive home our whole point. Now imagine applying that same thinking when you're working with your, your, your, your PMs or your team members. Cause one thing that you got to think about as a developer, your life experience goes into your software, whether you know it or not. Right. Like, like what's important to you, what's not important to you, all that goes into your software. And so you're bringing your unique experience, your unique perspective. So is the PM.
Kent C. Dodds (09:32.225)
Yeah.
Mark Techson (09:41.716)
Right. And so is the engineering manager. Everybody's bringing their unique perspective. And so it's not enough just for you to bring or just for them to bring. It's like think about the concert of all those ideas and you all working together. Again, if you have that singular focus of we want our users to have the best experience with this software. Right. And like that's what makes software special, in my opinion, is when you get teams to do that video game software.
Sa even SaaS software, right? Like or even your mobile apps, all of those places, you've used apps that you're like, man, somebody cares about this. And now I'm better because I used it, right?
Kent C. Dodds (10:20.684)
Really like that. that analogy is super. and like we all kind of work together toward this common mission. And yeah, of course, sometimes there's office politics and all that stuff. People are kind of out for themselves. But in in the perfect world, which we should be striving for and acting in that direction, everybody's going to be behind the mission of the company and looking for ways that they can contribute to that mission. And that
Mark Techson (10:31.69)
Mm-hmm.
Mark Techson (10:42.731)
That's right.
Kent C. Dodds (10:48.394)
It's easy to say, well, just stay in your lane and everybody stays in their own lane and and we make the best thing possible. But I think that the experience of everybody involved makes the like can make the experience better. And there are things that engineers understand are possible that a PM is just not going to consider or think about. So that that's super. You also mentioned that sometimes it's easy for us to think that we're building for an audience of one ourselves.
Mark Techson (11:06.091)
Mm-hmm. Mm-hmm.
Mark Techson (11:17.32)
Mm-hmm, mm-hmm.
Kent C. Dodds (11:18.246)
And and so if it makes sense to me, it must be correct. I wonder though, if we're really like to to we have to reconcile that with the fact that we do really only understand ourselves to the very best. And so what are mechanisms that you use to make sure that you understand the problems of the people you're building for? And maybe one example that you can branch off of that is that
startup that you built, the the mobile app, how you were helping people be stronger. I I assume you can correct me or tell me more of the story, but sounds like it's a sort of thing that you just kinda built for yourself and then realized other people could benefit from it too.
Mark Techson (12:01.117)
Yeah, so so let's talk about that. Okay. So before before we talk about the the app, I wanted to kind of address that question about, you know, what are the mechanisms that you use, right? To like figure out what other people need. So one is just listening and listening without defense. Okay, listening without defense. What I mean by that is we've all gotten like tickets in Jira or whatever your ticket system is, and somebody gives you some feedback on something that you made and you're like, you're using it wrong. Like
I did it right the first time. You're using it wrong. And then so when I say listening without defense is to ask yourself, okay, let me hear this feedback. So either one of two things happen. Either A, I made it incorrectly, or B, they don't understand how I made it. Both of those are things that I can act on as a developer, as a product engineer, right? I can act on both of those choices, but it's the heart behind it that I get to decide. Right. Cause if I'm listening with defense like that everything I did was right, then I'm missing opportunities to see that like if
Every not everyone, let's say a large majority of the users are having the same issue in the same place, even if the code is syntactically correct and is functioning per despec. Something ain't right because people are not getting what they need. And if the point is for them to get what they need out of the software, why is our ego in the middle of it and blocking us from like hearing the feedback? Because again, the software isn't for us, it's for the people. Now, here's what that directly ties into one of the hardest lessons I learned.
I spent four years about working on this mobile app and I had launched it within the first year, so maybe six months after ideation. I had this idea that, you know, whenever people are on the internet and they are like on Instagram or Facebook or something, and they see somebody who works out and they're like, I want to work out like that person. People's like, Yeah, screenshot this message. Or sorry, screenshot this workout. And the problem I always felt was that they're that's not actionable.
It's just not actionable. So I'm like, what if you could download a workout like a playlist from your favorite fitness influencers? And then they can get analytics off of like what your workout does or how their workout fares for other people, how people are downloading it, then they know what's happening because screenshots aren't trackable and all this kind of stuff. And the other thing that I was really focused on was I was like, you know, we're so like focused on how we look. And that kind of pushes a lot of people away of getting healthier and like living longer, living stronger.
Mark Techson (14:24.651)
I was like, you know, how you look is your personal business. That was kind of the model. It's like, how you look is your personal business. What I care about is you can like strong is universal. But aesthetically, some people like just being bigger. They like being big, strong people. And some people want to be very thin. Fine. I don't care. I want you to be stronger. So anyway, so I built this app, but I built it for me, how I thought it should go. And nobody liked it. Like
Kent C. Dodds (14:51.957)
Ha ha.
Mark Techson (14:53.597)
Nobody liked this app. And I couldn't figure out even my wife didn't didn't use it. She ended up downloading a different app. And that but that was the moment that I changed my perspective. When she downloaded a different fitness app, I was like, okay, if she doesn't want to use it, I could be like, Well, I'm your husband. You should be using my app. I'm like, why don't you want to use it? What? Right.
Kent C. Dodds (14:59.4)
no.
Kent C. Dodds (15:11.854)
Yeah, that's that's a signal, man. That's a big signal.
Mark Techson (15:17.289)
That's a signal that n her loyalty to our to me and our marriage wasn't strong enough for her to suffer through using my app. Right? So
Kent C. Dodds (15:25.964)
Yeah, wow. Okay. I want to hear what happened next.
Mark Techson (15:28.713)
Yeah. So then I took a step back and I started asking people questions. Right. So I started like doing surveys and user surveys. So I l I somebody like use the app and I'll say, Hey, tell me what you like about it and what do you wish you can do that you can't do right now? And I started getting like a different direction. And the direction wasn't what I thought. I thought everybody wanted to, you know, download workouts, customize their own workouts to have all this freedom. Right. And what people really wanted is for you to tell them what to do.
So they would just want Kent to say, Hey, Kent, you know, hey, friend who's want to work out like me, just do this workout. Just do it. And then they're like, yes, I would do this workout. Nobody wants to be like, I like Kent's workout. I'm gonna remix this workout for myself. Nope, they don't want to do that. People do not want to be in charge of that part of the process, they just want the instructions. And so as I started to pivot toward that solution, I ended up joining Google. And then that was just real money.
Kent C. Dodds (16:24.305)
Mark Techson (16:25.467)
And not like fake startup money that I was like losing money on this app, you know, from all the like things that I was doing for, you know, hiring like QA people and I was hiring social media managers 'cause I was just so sure that with enough like marketing it would like take off and I was just losing money. And my wife was like, Yeah, you should just go to Google. I'm like, You're right. You're right. And so I ended up coming to Google.
Kent C. Dodds (16:43.758)
No, but you you left that experience with some really good experience. and I think that that is valuable that like that's a super good takeaway for people is is talking and listening. And I I wonder how did you find the people that you were talking with? Like did you like you had people who were signing up and using it or or how did you find the right people to talk to?
Mark Techson (17:08.763)
good question. So I f the first thing I did was I just made a list of people who I thought either A completely fit my market demographic or people who I thought could fit it, you know, like if if they had the chance, right? Some people I'm like, you work out. So at the gym that I was going to, I would just walk up to people, like, hey, how are you tracking your workouts? And they were like, I'm using this other app. Okay, cool. Well, I have a free app that I just made. Would you be willing to try it? So I did a lot of that. And then I went to my friends and family who I knew kind of worked out. I went to those people.
Then I went to people who said they wanted to work out but never did. I thought, okay, now you also try it. And just kind of going across those that through that three kind of segments is where I got a lot of information about what was missing or what people wanted. And I did improve the app over time, right? Like I took that feedback and I improved the app. And I think that I just there were more lessons to learn that I hadn't learned yet that probably kept me from at least getting.
you know, to like the ten thousand or fifty thousand download mark. You know what I mean? Like I was stuck in the low hundreds or two hundred downloads. It wasn't really spreading the way I wanted it to. And there's some things I would totally do different if I had to go back and do this again. Hundred percent I would do some things differently.
Kent C. Dodds (18:19.34)
Yeah. Yeah, there's there's a lot with like the way that you ask questions, who you're asking and and when you open the floodgates, like all of that stuff that startups especially really have to worry about. I wonder how this changes when you go over to Google, where it's no longer really a startup, you're working on an established product. do like are you still having conversations with people? How do those conversations change? What are the types of questions you ask to
Mark Techson (18:32.704)
Mm-hmm.
Kent C. Dodds (18:47.928)
Get the kind of feedback that you're is actionable for you.
Mark Techson (18:51.425)
I love that. So we have this idea of Google developer experts, which are people who go through this application process and then they are assessed for their expertise in a product area that Google offers. So for Angular, we have GDEs for short, right? And so we have these people. So those folks we ask a lot of questions of all the time. Like whenever we're thinking about a new feature, we go to them first. So they get to see before anybody else does. And then we ask them, like, okay, does this work for you? Does it not work for you?
What's missing? how does this fit at the company you work for? Because a lot of them work for companies that use Angular, which is how they get a lot of their experience. And so we'll say, hey, okay, how does this could you see this fitting in where you work? You know, does this help you? And so we get a lot of feedback that way, which is incredible because when you find people who are passionate about your products, you get some of the best feedback and some of the most critical. Like people will tell you, like, I don't like this because I love Angular. I actually hate this for Angular.
And so that's hard to hear because you think what you made is a good idea, but you got to take it and you gotta say, okay, tell me why. Tell me more. Like, like that's the best question you can learn, I think, as a product engineer when you get critical feedback is tell me more. And one place I use that a lot is on YouTube. So if you've ever seen like an Angular YouTube video, and then you'll see comments where somebody will say something really like strong about how much they hate what we're doing, and I'll say, tell me more.
Yeah, tell me more. Cause it's either you actually just trolling me or you love the product and we are ignoring something that you think is really important. See, that's another thing. Like there's just so many like layers to this, because they might just be angry that we did A instead of doing B, and they really need B and they wouldn't mind A if we just did B first, right? But we did A first, so now we've totally like set them off.
Kent C. Dodds (20:46.71)
Yeah, yeah. That I love when questions like that totally take people off their guard. Like they're they're like super, super angry and then you say, Well, tell me more, and you're like, you actually care? okay, yeah. Sorry, I I didn't mean to be so angry.
Mark Techson (20:53.823)
Mm-hmm. Mm-hmm.
Mark Techson (21:01.407)
That's right. That's right. And as a popular person online, like like you have a quite a prolific, like, you know, online presence. And I'm sure you experience stuff like this. People will say something very critical and you'll be like, okay, well, what does that mean? Or what happened? You know, you'll inquire inquire. I'm sure you've had those experiences.
Kent C. Dodds (21:18.006)
Yeah, I d I definitely have. And and sometimes or often it's really great feedback and and I take that in and maybe I don't in improve the specific thing that they're talking about for a variety of reasons, but it it goes back in, I fold it back into future decisions that I make and yeah, it's a really good direction. other times the the thing that they're really upset about reveals to me that they may not be my target. that and
Mark Techson (21:45.045)
Mm-hmm.
Kent C. Dodds (21:47.416)
There's some judgment right there, right? Like it's easy to say, okay, no, I like we'll just take whatever feedback we give and we'll feed that into an agent and make the agent make that better. but I think that you would end up with a product that is a product for nobody, because it's trying to be a product for everybody. ha have you experienced that yourself?
Mark Techson (22:03.285)
Mm, mm-hmm.
Mark Techson (22:08.101)
100%. Because some people so I could say this in a lot of different different contexts that I've worked in where people where the acknowledgement that I am not for everybody, whatever my offering is, it's not for everybody. Like coming to that acknowledgement is really difficult for people because they look at the wrong examples. Let's say, well, everybody wears Nikes. How you know they're for everybody. Well, is that true though, right? Like, cause if they were for everybody, you would not have competitors.
Because the market would be completely saturated if everybody was happy with the same thing. But they're but it's not like that. Just some just because someone is large doesn't mean that they are the de facto or like, you know, just the thing that everybody wants. And and that's a a hard lesson to learn no matter where you work or what you're working on, is that it's not for everybody. So when it comes to like Angular, for example, when people are like, you know, why does Angular exist? You know, React is better. And I'm like, Well, there are millions of people who like the way Angular works. But
One thing that I learned from my colleague Jeremy Elborne, he's since left Google, but he was my live stream partner for a long time. And one of the things he said, and I never forgot, he was like, We're making the Angular to be the best tool for people who want to use Angular. And I was like, wow, what what a mindset shift versus like let's capture all of the market, right? Like, we can't, you can't even try it. Like, I mean, of course I've tried, like I tried to be as creative as possible.
Kent C. Dodds (23:21.771)
Hmm.
Mark Techson (23:33.782)
To do these things, but that's not the way the world works. Sometimes, you know, they're just things that you cannot control in terms of how how many people or how many users you can capture in a segment. Like sometimes you just can't control that. So then what do you do? Do you give up or do you say, Okay, how do I make my product for those people who love it? I want to make it the best thing that they've ever used for them. And then some people may come aboard, right? Some people may not, but you you can't really control what those other folks do.
Kent C. Dodds (24:03.83)
You know, that it that is a I I think a really good insight for people to acknowledge that especially like in the startup world you need to niche down and and everything, but even in like working in a big player, the bigger you get, the more you're going to find the people who are not a fit for what you're doing. and so like it there there is some balance and there's some judgment that goes into is this a a person whose opinion
Mark Techson (24:15.605)
Mm-hmm.
Mark Techson (24:19.787)
Mm-hmm, mm-hmm.
Mark Techson (24:24.171)
Yes.
Kent C. Dodds (24:33.602)
we are going to fold into the products or are we gonna just accept that this isn't a right fit. so yeah, that's it's a challenging one. to shift gears a little bit, I wonder what you think, Mark, about how AI has changed the software to engineer's work, obviously very significantly, but the like the day-to-day stuff that coders have done, it seems like a lot of the skills that we used to have
Mark Techson (24:35.946)
Mm-hmm.
Mark Techson (24:39.861)
Mm-hmm.
Kent C. Dodds (25:03.67)
or or that like used to be really important are not as important as they used to be. What are the skills that still remain valuable? And are there s some new skills that engineers should develop that will actually be durable and not changing all the time?
Mark Techson (25:06.635)
Mm-hmm. Mm-hmm.
Mark Techson (25:19.477)
Hot take. This is a real big hot take. And I know there's some people who are so there's this. Okay, what for context disclaimer for everybody listening? I do work for a major frontier model provider. So whatever I say, you gotta take that with a grain of salt because you know where I work. So like let me just be like super clear. But there's this idea that we will approach this like I won't say singularity, but this level where models will be so good.
Kent C. Dodds (25:34.858)
Ha ha.
Mark Techson (25:45.024)
That it just won't matter anymore. Nothing will matter because the model will have all the answers, right? I don't know if we hit that or when we hit that. Like, like you can't predict the future, right? Like, like you can forecast as much as you want, but you can't predict how long that could be. Because if you look at the news right now, there were a lot of voices that were saying that we, like me and you, can't we be out of a job already. Like we should have been out of a job, you know, five, we actually six months past the due expiration date.
Of when we were supposed to be out of a job. So those forecasts were incorrect. Right. Now, with that it with that being, you know, keep that it as a context. What I think that is true that your know-how and expertise will not go out of style anytime soon. And I think that is a durable skill that like developers have to remember. You know what's right and what's wrong. That's the thing that I I always am so surprised when developers like, it doesn't matter if I learn the code. I'm like, but then how will you know if what was given to you is correct?
Right? Like, how will you know? So, one thing's is for me, I'm a I am a musician, right? So I play guitar. And when someone plays a guitar that is out of tune, I know which string is out of tune. But I also have and now this is a true thing. I have this thing called a roadie, which is an electric tuner that can tune the string to perfect pitch by one button press. Does that negate the fact that I can hear which string is out of tune quickly? No.
I know which stream to go to. And I say, okay, do your work. And I see that like with models, we could adopt a similar path where we're like, hey, I know what needs to happen. And my expertise tells me what needs to happen here. Now, model, go ahead and do that thing, but we're kind of like atrophying in a way where we're just like, here's this vague idea of what should happen. And then I'm mad when I don't get what I want. Right. I don't get the output that I want. And I feel like,
Okay, so you're talking about like durable skills that you need to be able to like take forward, communication and like expertise. It's like completely durable. Because the better okay, here's one of my favorite internet experiments right now. There's some guy on the internet, him and some and I guess some of his friends, they're trying to vibe code a GTA caliber game. And I'm like, that is like wild. Now, the ego in a person could say,
Kent C. Dodds (27:59.245)
Hmm.
Mark Techson (28:06.329)
no, don't do that. That's stupid. Because what about all the art and craft of video games? I'm like, yeah, they are art and craft. And he's learning that anyway. So if you look at the the kind of devlog, he's like, wait, we gotta learn Unreal Engine. I'm yeah, I already knew that. I already knew you were gonna run into things where expertise mattered, right? So, like, your expertise just won't go out of style anytime soon until we hit that level, if ever, where models are just like.
Kent C. Dodds (28:13.336)
Yeah.
Mark Techson (28:32.799)
completely infallible in in their ability to generate outputs, whatever whether it be code, whether it be documents. If we get to that point, we got way bigger problems, right? Like there are other things that are already happened. But to then until we get there, your expertise and your communication is like great. Cause he commented, he was like, if I do if I vaguely talk about unreal engine, you know, prompts, I get a a very kind of like wide response. That's not really what I want. So now I gotta learn an unrolled engine. I'm like, see? Yeah.
Kent C. Dodds (28:42.188)
Yeah.
Mark Techson (29:02.109)
I knew that I I have told you that, that like your expertise matters.
Kent C. Dodds (29:05.89)
Yeah. Yeah. I think and a lot of this expertise is latent space in our minds. So we we don't really we never intentionally learned it. It just kind of became learned. And I really like that you brought in this example of the vibe coder who's trying to make a GTA game, level game, because what it demonstrates is that even somebody who doesn't know how to build software, they still are going to be able to learn. even with like the
Mark Techson (29:10.911)
Mm-hmm.
Kent C. Dodds (29:33.678)
AI, like a lot of people are worried, well, juniors are never going to be able to enter this industry anymore. Like it's just not possible anymore. I I take a very opposite thought to that in that juniors are definitely going to continue to to learn and you'll just be able to get so much farther than you used to. honestly like this is the this is what Angular JS did for me when I was using Backbone and I noticed like people were getting into software engineering and and web programming in particular
Mark Techson (29:39.405)
Mm, mm-hmm.
Mark Techson (29:57.407)
Mm-hmm.
Kent C. Dodds (30:03.83)
And Angular.js back then made it so that you could get so much further building a an app without even knowing JavaScript. and like for some re like at the time that kind of bothered me. I'm like, hey, you like you don't belong here. Like, you know, like you haven't gone through the pain. But but I think that's what AI is doing is it's getting it so that people can go so much further before they really need to understand what's going on under the hood, which is dangerous. Like it carries with it its own.
Mark Techson (30:18.933)
Right, sure.
Mark Techson (30:28.979)
Mm.
Kent C. Dodds (30:32.002)
Set of like if if you build something and then a lot of people depend on it and then you realize, like massive security holes and whatever, like yes, it's dangerous in that way. But at some point you get to the spot where the AI is just not gonna do it for you. And now you have to go in and and understand and learn and and like that's just a natural evolution of human understanding and and knowledge acquisition is we use tools that abstract away concepts for us and then
Mark Techson (30:49.161)
Right.
Kent C. Dodds (31:00.106)
If those tools fail at at that point of failure, we now go in and start to understand things better. but let's let's fast forward a little bit into the future and say that models are getting better and better and we can get further and further, almost to the point where like for the vast majority of use cases, you really don't need to understand what's going on under the hood. You just tell the model and it does the thing and and maybe you have to correct a couple of things because you didn't explain yourself well enough or whatever, but it like it it manages.
Mark Techson (31:21.696)
Sure.
Kent C. Dodds (31:29.938)
in that world, like what what do you think is among the the still valuable and human things that software engineers will be able to offer in that world?
Mark Techson (31:42.078)
I I'd actually go back to a little bit of what I talked about with the startup, how I built the wrong thing. I think knowing what to build will still be like really important. this Twitter user's first name is Dax, and he was like software, like code was never the hard part about software. I'm like, yeah, that's totally true, right? Like, and and credit to him for that, just that thought leadership of yes, the code was never the hard part. It was always like knowing what to build.
Who to build for all those things. So as you like have to learn how to orchestrate. So that's the other thing. You gotta learn how to orchestrate with the current tools. You just have to learn this skill. This is a new skill that developers have to learn how to do is how to orchestrate to get the output that you want and to achieve the goals that you want. And and I think the hard part to be honest with you, can't for people is that for a long time
Even though we always said that coding was open for everyone, we knew that not everyone would pursue it, right? Because there was still a barrier to entry. Even if we opened the door wide, they still had to climb over, you know, like a pretty high wall because you have to be able to think like an engineer, right? To like write code by hand. And now that that wall is going lower and lower, and it's like, I don't even need to think like an engineer to be able to build the code, but you still gotta think like an engineer to build the right thing.
Right. And and it's not even about like like like trivial things. Like, for example, I don't care about usage limits in my personal projects because I know how to code. And I don't have to stop when like, you know, if anti-gravity is like, okay, you know, you've reached your your limit for the day. Yeah, I can keep going. Right. Like I don't have to prompt for a color change. But that's not a durable, long lasting thing. You see what I'm saying? Because eventually, like, I have this really wild theory that like like 20 years ago, I had this girlfriend and she would text me.
Kent C. Dodds (33:03.651)
Yeah.
Mark Techson (33:32.938)
And I would hate when she texted me all day because eventually she'd go over my text limit and I would start to get charged. You know what I mean? And I'm just like, man, stop texting me. I don't want to talk right now because I'm gonna run out of text messages. That's how we are with tokens right now, right? Like tokens are everything, and you and people are starting to think, like, I can do token maxing, but then I'm spin maxing at the same time. I I have this wild idea that eventually we'll commoditize token usage to the point where like there'll be enough resources. We'll figure this out. I'm just saying in the future.
Where the same way text messages used to cost 10 cents per message and tokens cost a certain amount, we won't even be thinking about the cost of the tokens. We'll be more thinking about like cost of some other bigger, less granular thing, right? Like some less granular usage cost. When we get there, for example, what I just say it won't even matter about the fact that I can keep coding after the usage limits are up, right? Like that will not matter forever. So, but knowing I still am standing on the fact of like having expertise. So you know what to build, how to build.
Kent C. Dodds (34:15.533)
Yeah.
Kent C. Dodds (34:23.544)
Yeah.
Mark Techson (34:32.499)
And then being able to orchestrate. Like I think that's a thing that people are really hesitant to try to to d you know, to embrace this orchestration idea. They they have to.
Kent C. Dodds (34:41.55)
Yeah. Yeah, you know, what's interesting about orchestration in particular is that it's it's software engineers who are involved in open source, kind of have have a leg up on that because you you're just used to building a system that contributors will be successful in. it's a very similar similar thing. the other thing that w
Mark Techson (35:01.385)
Ooh, that's that I was just gonna give you a lot of props for that. That's very insightful. That is like premium. I love that.
Kent C. Dodds (35:06.222)
Yeah, it's it's good. And it's honestly the the cool thing about all of these skills are let's say that we're wrong and the models don't get better and they stop right now. if you learn the skills of knowing what to build, you're still going to be better off. and so, like, whether we're right or wrong, these are the skills that are going to be really valuable for you going forward. And and what distinguishes these skills from like what the product manager does is that,
Mark Techson (35:17.801)
Mm-hmm.
Mark Techson (35:23.467)
Mm-hmm.
Kent C. Dodds (35:35.5)
These things are like understanding the system and the primitives that you need to build to get the outcome that you're looking for. the other thing, like on that note about tokens becoming much more inexpensive, I agree with you. I do think that in the future they will be a lot less expensive. you know, it used to be that you'd have to go to the university to use a computer, and now we've all got one in our pockets. Like this is just the way that these things go. So in that future.
Mark Techson (35:53.535)
Mm.
Mark Techson (35:59.073)
So hey.
Kent C. Dodds (36:04.072)
you you could say, well, I'll just turn my agent on, say make million million dollars and it'll go off and and you know it'll just iterate whatever. but the the the paper that started like really kickstarted a lot of this stuff was attention is all that matters, right? And it's like talking about how to make the models predict text in an efficient and and reasonable way that it'll actually do something useful. I think that that the title of that paper is really, really good because attention.
Mark Techson (36:18.474)
Mm-hmm.
Mark Techson (36:27.829)
Mm-hmm.
Kent C. Dodds (36:34.072)
For humans is also all that matters. And so if you just say, you know what, tokens are basically free. And so I'm just going to have my agent build everything that could possibly be built, that's it's still not going to work out because the attention of the people who are going to use that software is finite. And so you can't just say, well, I'll build everything and people can pick and choose. No, like you that's not going to work. You do have to pick. You as the builder have to pick what you think is worth.
Mark Techson (36:37.055)
Right.
Kent C. Dodds (37:03.894)
while building for people and worthwhile telling people about so that they come back to you and use it. So attention is all that matters.
Mark Techson (37:14.219)
So think about this. So so so this is the interesting thing where again I think it's going to change the way that we work, but there is still room for all of us to work. So like like that's the thing I want to like let people know. I think there's still many years of room for all of us to work and be successful. Just what you build, how you build is going to change. Think about the grocery store. Kent, you have littles, I have littles. if you were to go to the juice aisle, there is 50 or more products on that on that counter.
Right. Like like just looking. And the one that you pick is the one that has your attention and that has had the right marketing, the right product strategy, the right ingredients, the right everything that you need. But even if you were to say, Well, I only want organic, sugar-free juices, you still niche down, but there's still a ton of options, ton of choice. You go with the one that will like either your, you know, let's let's say your other parent friends recommend, one you saw a commercial that spoke to you, one that had a a good social media campaign. It's just
Because manufacturing went from one small group of people been able to do it to being very wide where manufacturing is available. And you and I don't even need to start our own manufacturing plant. We could come up with an idea to manufacture something as long as we got the money for it. We can have one of these kitchens make our product and distribute it. So it's not even the same cost. That's the same thing with LLMs in a way. It's just that like as people are able to build more and more things, like you said, they can build whatever they want, as much as they want.
Building the right thing and and having the right like target. Because think about how humans are going to receive this. If there are 75 million budgeting apps, how will you get a person to choose you? You're gonna have to be smart. Like you as a person have to be smart. You can ask Claude, you can ask Gemini, you can ask anybody. Like, okay, how do I target these people? And it still may not work. You know why? Because people are weird and unpredictable. You cannot predict human behavior as much as we try. We we can't 100% like deterministically
decide what's going to be a hit. That's the other weird thing, right? Like think about the songs that are like, you know, on the radio. That you like like the song is called Appata, like Meet Me is like Appata Pata. That doesn't make any sense to me. Right? Like how how'd you pick that song over a song that had like, you know, potentially more meaning or potentially more soul to it? How? Because people like what they like and they don't even know why they like it. So this whole time, so going back to your whole point about attention,
Mark Techson (39:40.393)
That is the new like frontier that you're gonna have to think about, you know, like as companies. We all will have to solve for this. How do you gain the attention of people when there's infinite choice? And we've had this problem before, we'll continue to have it now.
Kent C. Dodds (39:53.164)
Yep, yep. This is not a new problem and these are not new skills. and so yeah, it's worthwhile developing them. Mark, this has been such a pleasure to have a conversation with you about product engineering, but we're getting toward the end of our conversation. So is there anything that you're really hoping that we talked about that we didn't really touch on?
Mark Techson (39:56.309)
That's right.
Mark Techson (40:10.943)
Yeah, just as one thing about the narrative that I just that just burns my biscuits, which is that like you're left behind narrative for developers. I just want to send just a hopeful message that like remember this. We have changed the way that we move as an industry. Right. Like it used to be, Kent, like when you and I, if a new library came out, we'd wait six to twelve months before we adopted it. Now we adopt new things as soon as they come out because we are so like on everyone, not everyone, like the loudest voices.
are all living on the bleeding edge, but it doesn't mean that you have to, as a developer out there who may feel a little hopeless, like, I don't even know what a loop is yet. I barely got, you know, claw code installed or I barely got anti-gravity installed. Right? Like you don't have to live on the bleeding edge and you're not left behind. The the only wrong move you can make right now is to ignore it all. That's the wrong move. But everything else, if you're just watching, that just means you have the front row seat for what's next. That's the way I see that story, right? But you're not left behind.
Kent C. Dodds (41:00.771)
Mm.
Mark Techson (41:10.256)
but don't ignore it. That's a mistake, in my opinion.
Kent C. Dodds (41:14.316)
Love that. Thank you for th giving that to us here at the end here. So let's get our homework. Mark, what is a one specific thing somebody could write down and check off when they do it that they can do to get better skills as a product engineer?
Mark Techson (41:20.299)
Mm-hmm.
Mark Techson (41:30.455)
the product engineer. tough. Okay, let me think real quick. What's something they can do right now? sure, sure, sure, sure, sure. Here's what you can do right now. I would love for you to think about a product that you've had in your mind for a long time that you just say either you hadn't had the time or the skill to make. And I want you to just write on, you know, type in your favorite editor, like just text editor, a prompt that describes the first basic version of this product.
And want you to try it out. I don't care if you try it out on the web and AI Studio or Codex or you download Claw Code or Anti-Gravity. I don't care where you try it out, but I want you to find a place to like try out actually building a product and then just see what you get out of it, right? Because what here's what this this exercise is gonna show you that if if you get a perfect like rep like I guess representation of what you were thinking of, then you're like right on the right track and you're doing, you know, you got the right mindset. But if you don't.
Start thinking about what's missing. What didn't you say? What didn't you type to get the first version that you imagined out of the LLM? And then you can iterate and get closer to that first version, not the finished product that's going to make you a million dollars, just that first version that you can say, this is what I was thinking. Try that. That's your homework for me. I want you to do that.
Kent C. Dodds (42:50.956)
Love that. Thank you so much, Mark. It's been a pleasure to chat with you. What is the best way for people to reach out to you if they've got follow up questions?
Mark Techson (42:57.909)
Sure, f you can find me online anywhere, just at Mark Texan, M-A-R-K, T-E-C-H-S-O-N. I am the only person that comes up for it days and days and days. So any place that you find me on the internet, send me a message. I am so happy to answer your questions.
Kent C. Dodds (43:15.058)
and we're so happy to have you here, Mark. Thank you so much, and thanks everybody for watching. We'll take care. See you later.