Kent C. Dodds (00:01.198)
Hey everybody, it's Kent C. Dodds. We're talking about product engineering today with Dylan. How are you doing Dylan?

Dillon (00:07.144)
I'm doing well. Thanks for having me on. Excited to be here.

Kent C. Dodds (00:09.678)
I'm excited to have you. You were one of the folks that was recommended to me when I opened up the idea of starting this season of the Chats with Kent podcast, all about product engineering. And I was not surprised. The stuff that you work on over at Cloudflare and generally Cloudflare in general seems very...

product focused rather than just like, we've got this cool technology, let's talk about the technology. You're always looking at ways that you can make that a practical and usable thing from the user's perspective. anyway, what is it that you do over at Cloudflare and what are the things that you're into?

Dillon (00:53.251)
Yeah. So I have actually recently joined cloud flare. I joined in, late November. and I joined as a principal engineer in ETI, is emerging technology and innovation or incubation, but basically the org where, the workers platform is built or ball objects, cues or AI stuff, all that stuff. I am currently working on one of our AI and agents teams.

I'm currently overseeing improving our dashboard agent, some of our other agent infrastructure, and then another exciting project that will hopefully be announced in a couple of weeks.

Kent C. Dodds (01:37.076)
Okay, okay, gonna stay mysterious. Cloudflare seems to always be shipping something. It's like every day there's something else that's going on. So working on the agent side of things and specifically the dashboard for agents, there like, are you talking about the workers AI? Is that kind of where you're focused on or are you working with the agents package with Sunil and that crew too?

Dillon (02:04.921)
So the team I'm on specifically is a relatively newly formed team called Agent Experience. We're essentially a sister team to both like the AI platform team, which is workers AI, AI gateway, AI search and vectorized stuff. And like all the replicate folks that got acquired are over in that area. And then the other sister team is the agents SDK team. So it's no Kate, I carry. Really the purpose of our team is

One, to prepare Cloudflare in general for being consumed primarily by agents as a primary mechanism of interacting with all of our APIs and stuff. And then also being customer zero for dogfooding both of the sister teams' products before they get released to free tier the public.

Kent C. Dodds (02:38.733)
Mmm.

Kent C. Dodds (02:55.98)
Lucky.

Dillon (02:57.779)
Is it, it is a, it's a nice spot to be in a lot of, get to get a lot of early feedback and help contribute back to that stuff. So, and working with all of those people is amazing. Like you can work with Snow and Corey from replicate and like all those people are just incredible. Michelle and workers AI just, yeah. Very, very blessed to be in this position.

Kent C. Dodds (03:01.111)
Yeah, that is.

Kent C. Dodds (03:15.446)
Yeah, yep. I definitely love working with each one of the people that you mentioned on the outside. so, yeah, working so closely with them sounds really awesome. for those guys, their users include you. Like I imagine that you are very actively talking with them and telling them the thing or complaining about things in a nice way and that sort of thing. What is that experience like?

being the customer for them.

Dillon (03:47.519)
well, I like it a lot one because like, I don't know, I'm at the point in my career where like, feel very comfortable, contributing to like other code bases or, you know, stepping in, like, I mean, everyone is stretched. I want to say stretched thin. It's not like we're overworked or like, you know, working like 10, 12 hour days, like, you know, everyone's busy. so like, I like getting to kind of step across, different problem spaces.

Kent C. Dodds (04:07.63)
Hmm.

Dillon (04:17.077)
And just also getting to be involved, sometimes so early in the design process, but getting early feedback and helping drive what ends up landing in people's hands is a ton of fun.

Kent C. Dodds (04:33.068)
Yeah, yeah, that would be fun. And then on the opposite side, you have people like me, I'm your customer and other customers. How do you know what to build? as far as the way that Cloudflare operates, how do you identify the right things that you should be working on? Is it just intuition or do you have a formal process?

Dillon (04:59.305)
that's a good question. I don't think we necessarily have like some, you know, blessed, path to like bringing a product to market or nailing the right experience. a lot of our products, think like a lot of this might be unique to, you know, dev tooling, dev product space, but like a lot of this stuff we've built over the years and releases products came out of us having to build solutions for ourselves.

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

Dillon (05:29.655)
And I think intuition comes with experience. I think there might be just, I don't know, it's such a complicated thing to like, what makes a good product, what makes a good experience, but like,

I think like my, the end all be all is like, do you want to use what you're building? And if the answer is no, then it's probably not good enough.

Kent C. Dodds (05:53.048)
Hmm.

Kent C. Dodds (05:58.188)
Yeah, you know, I found that it's easiest for me to build things that I use myself, like where I am the primary user. Right now I'm building a coding agent, or not a coding agent, just a general purpose agent that's only accessible through MCP. I like to add these odd constraints to myself because I think it actually is oddly freeing and just makes things really interesting. But because I'm...

the primary user or the only user, I feel the pain very personally and it's very obvious what I should be working on next. And for you at Cloudflare, like you're using the stuff that you're building as well. I wonder what thoughts you have on like, or for people who are not building things, like let's say I'm building an app that helps grandparents connect with their grandkids.

I mean, I know how to connect with my grandparents or I did before they all passed. So there's like some relation there, but I'm not actively using the product I'm building. How do you connect the dots within that situation?

Dillon (07:09.423)
That's a great question because like, actually most of my career, well, maybe like half my career has not been in the dev tooling space. So I've been doing this professionally for 12 or 13 years now. And like, I started working at State Farm and like insurance, and I was working with like a back office team that like an internal tool that was used for modeling, like insurance products, right? Or like financial products on a state by state basis. And like,

That wasn't an exciting or flashy product or tool, but like there's just something that's always just like, scratch my brain the right way about like, I don't know, like I would sit down with the people that use this tool and see just like the mind numbing process they had to go through every day and all the just paper cuts with the existing product or the stuff we were shipping. it's just like, I want to make this better for them. Like I want to deliver on behalf of my users and I don't know, build something I'm proud of and like.

Being able to connect with users is really important and something that's always been consistently there in my career. Before I ever got to Formidable or Vercell or Cloudflare, I built a ton of back office admin tooling. And that's always been just as rewarding, if not more rewarding than the really high profile projects I've worked on, like Vercell domains or some of the AI stuff at Cloudflare.

just being able to like, I don't know, improve people's lives. Like take it, take a workflow that goes, might take them four hours of doing a day down to a couple of minutes. Like, I don't know. I, when you can see that change somebody's day to day, like that feels really, really good. And yeah, I love stuff like that.

Kent C. Dodds (08:47.063)
Hmm.

Kent C. Dodds (08:55.749)
That is very cool. And I appreciate this perspective because we often hear about product from people who are building products for developers. Those are the products that we use. so I really, the vast majority of us are not building products for developers. And so I appreciate that perspective. One thing that came to mind is there is this,

I mean, there's a pretty obvious value add to take a four hour workflow down to a couple of minutes or something. That's very obviously something that we should do and a project that probably is not a quick, simple thing and involves all the stakeholders and the product manager is very involved in that. In your experience, did you ever have some pushback from

the higher apps are from your boss to like ship fast and maybe cut corners on that user experience. And how do you navigate that sort of frustrating experience?

Dillon (10:03.455)
It's definitely frustrating.

I feel like I've been stubborn throughout my career to push back as much as I can on those conversations. And I've fortunately always worked with people and teams that, for the most part, there are exceptions. But if we do have to cut a corner, like,

we've always been pretty diligent, or at least the teams I've been on diligent at like coming back around and cleaning up and doing it right. so I think a lot of it is like discipline and caring. and honestly, sometimes being stubborn and sticking up for what you think is right. and like, I think maybe that, that is like what ends up building taste.

Kent C. Dodds (10:43.96)
Mm.

Dillon (11:01.165)
famous word on Twitter right now, and intuition over a career. It's like, where are the times that I've pushed back and it was worth it and it did make the product better or maybe it wasn't worth it? some of that just has to come from experience and failing or succeeding. I lost track of the question. I was rambling, but.

Kent C. Dodds (11:22.732)
No, no, my question was about like feeling pressure from your boss to ship. But I think discipline and pushing back makes a lot of sense. Sometimes you really do just have to push the thing out the door and like get something out there that you can iterate on. But remembering.

Dillon (11:37.945)
which I think is equally as important. I think I've definitely been, I probably even just like nationally have a tendency to want to sit on something and bake it longer than it needs to be. Like getting stuff out there, even if it's not polished or perfect and into a user's hand and like getting feedback is way more valuable than sitting in like a metaphorical crystal palace or whatever and imagining. Yeah, I think, I think like,

Kent C. Dodds (11:50.798)
Hmm.

Dillon (12:07.535)
One of the most important things you can do is like, be where your users are, like have a way to get feedback from your users. Like a lot of roles, even roles that I've been in, like there has sometimes, or in a lot of roles, guess in organizations, like there is like a product owner or a product manager or like a design and org or something like that, that sits between like an engineering team and eliciting.

Kent C. Dodds (12:11.789)
Hmm.

Dillon (12:35.993)
direct feedback from users, like, budge your way into those conversations or like, the more you can even just like check forum posts or I don't know what it, whatever it might be, wherever you can get real feedback from your users, the better. Like one thing that was like, we did a Vercell that I think was insanely, insanely powerful and like is part of why Vercell does insanely good products.

Kent C. Dodds (12:50.231)
Hmm.

Dillon (13:04.341)
Every single team has a fire hose channel and teams are kind of organized around products. If we're sell, there's not a ton of like specific product people, like generally teams and engineers are like product engineers. but these fire hose channels are a basically straight feed from Twitter, from Reddit, from, you know, stack overflow, all the places, discord, just streaming in.

Kent C. Dodds (13:20.6)
Hmm.

Dillon (13:33.783)
to this channel that the product engineers can see like all day long, what's coming in, where pain points are, patterns. I love that. That was insanely, one powerful because like you can see like something you just shipped, like you can see the feedback like pretty quickly. If you're using a, if you have like a lot of users or whatever, but like, yeah, just forcing your way into getting feedback directly from users. And I think something very,

powerful that I don't think enough developers do is like sit down and watch your users use your product. Like you will learn so much about like the one in a million edge case that you were like, no one's ever going to do that. Probably being used pretty often. Like

Kent C. Dodds (14:22.048)
Yeah, my brother once, he works at Microsoft on Azure. And one time he said, at scale, even edge cases are common. Yeah, so that was one thing that I wanted to ask about you. At the beginning of our conversation, you said you'd sit down, you'd watch them go through mind numbing process and hit paper cuts and all of that.

Dillon (14:34.307)
Yep, yeah, 100%.

Kent C. Dodds (14:51.724)
Like how do you typically go about doing that? Especially with your earlier companies that were not dev tooling. Like did you ever have a formal mechanism for sitting down with users or was it mostly relying on the product manager to just kind of relay those paper cuts to you?

Dillon (15:13.135)
So a few of those roles were building like internal tools. So like I could just, you know, use back then Skype or whatever it was to find the people that were using the tools or walk down the hallway and sit down with them. And that was really useful. And then other times it would just be asking the product team, like, can I sit in with you guys? Can we get?

you know, some user interviews scheduled, like you go out and find users that we can talk to and schedule meetings. just like that proactiveness, has always been made the difference. Like I, when I did consulting to like actually working in formidable and like consulting was like the best thing I ever did for my career. like I've said it a couple of times in my conference talks last year and a couple of times on Twitter, but like, I don't think the hardest problems in tech are

Kent C. Dodds (15:56.494)
Mm.

Dillon (16:07.402)
like scaling cash and validation or naming things. I think it's people process and like organization structures and like consulting forces you to like deal with those problems.

Kent C. Dodds (16:13.357)
Hmm.

Dillon (16:19.439)
like immediately in the job, like having to get dropped into various engineering orgs and figure out stakeholders and who cares and stuff like that. And like, that was our job at Formidable. We got dropped into tons of different companies and then, you know, those were a lot of the situations where I had to work with product teams. how, like, can we get time with the users to figure out how to nail this experience, right? I would hope that...

If you're an engineer that isn't super product facing and you have like product partners, if you approach them and asked for help scheduling time with users, that would be something that, that's what a good product org should be doing in my opinion.

Kent C. Dodds (17:00.684)
Yeah, like I imagine that when you went to the PM and you're like, hey, can I be a part of this meeting? They were like, no, no, of course they're like, yes, yes, yes, please, please, And honestly, that seems like a really great way to kind of insert yourself into the mind of potentially like the people who get to help make the decision on whether you get a promotion or a raise. So from a purely like,

Dillon (17:11.789)
Yeah.

Kent C. Dodds (17:29.439)
selfish only care about my career standpoint, it seems like the obvious thing to do as well.

Dillon (17:34.871)
Another piece of advice, and this actually served me incredibly well, ever sell, working on domains and DNS is get, build good relationships with your support org, like your customer support org. They are sitting on a gold mine of customer feedback. They know the worst edge cases, the worst things, the patterns that repeat themselves that cause customer escalations over and over and over again. I think.

Kent C. Dodds (17:48.226)
Mmm.

Dillon (18:04.643)
I think this is actually like something that's led to me building a lot of successful and good products is like that feedback cycle between customer support and engineering. I've always been, I've tried to be incredibly diligent about like making sure that I have like good visibility over what's going on in support for my products, building good tools to help support.

manage your product I think is really important and oftentimes overlooked.

Kent C. Dodds (18:33.654)
Hmm.

So like observability kind of thing, but not quite like the hotel sort of thing, like, sure.

Dillon (18:42.115)
I mean, I think that's important too. It's actually something I wanted to talk about, but yeah, I think good observability over your product and having good metrics and having a good insight into how your product is causing customer escalations to your support org. And then using that as a feedback cycle to...

One, build better tooling for your support org because like there's nothing more frustrating for your coworkers who work in support to just for months on end be getting the same kind of escalations. Like my DNS records aren't showing up once they propagate for eight months on end. Like let's solve this and fix it, you know? And then that's going to very clearly show you where you have like deficiencies in your product and where people are struggling.

Kent C. Dodds (19:33.164)
You know what, what I'm starting to develop a kind of a thought around or something that seems to be clear to me is that your approach for closing that, that feedback loop kind of is a little different depending on the size of the application or the size of the user base. So like it's an internal tool. Okay. You're going to sit down with them in the office and you're going to talk with them.

Dillon (19:53.027)
Yeah.

Kent C. Dodds (19:59.598)
It's used by hundreds of thousands of people. Okay, well, you're gonna, maybe you'll still sit down with some of them, but like getting a representative sample of that is pretty difficult. And so you move more toward, you know, monitoring and support tickets and the Firehose channel and that sort of thing to kind of get more trends. And I don't know, like at the bigger company or the bigger user base,

products that you've worked on, did you ever sit down with users and like have a specific user that you're always just like, I'm trying to please this one. And hopefully it's generally applicable to everybody. does that resonate with you?

Dillon (20:46.339)
There was certainly like at Versel, like we basically rebuilt domains from the ground up. It was like one of Versel's oldest products, like way back, like eight or nine years ago at this point. And it, it always had shared ownership once you, and like, once you get to a certain scale, shared ownership is no ownership. And then ended up having a bunch of customer escalations, like second in the chart next to billing, which is not great.

and like fortunately for Vercel, like Vercel is quite big, well known, likewise with Cloudflare. Like it's easy, it's easy for us to get a lot of high quality feedback, especially because our audience is developers from like Twitter. but I, if like I ever saw people struggling with the product or being upset with domains, like I'd shoot them DMs and be like, what went wrong? How can I reproduce?

you want to jump on a call. there were some people that I grew to have trusting to have good feedback on like domains and stuff in particular that I would always go to and like, we're getting ready to release this feature. Do you want to, can I get your feedback early on it? And that just came from them reliably giving us good feedback consistently.

Kent C. Dodds (21:51.661)
Yeah.

Dillon (22:09.359)
Yeah, I don't know how that's just general relationship building, I guess.

I want to say something else about observability quick before we go back. think having good alerting, regardless of the scale of your product, whether it's just a small back office tool with five to 12 people using it, or you're building a product with millions of users.

Kent C. Dodds (22:21.781)
yeah.

Dillon (22:40.033)
Having good metrics and alerting and even paging is like super important because like, I don't know, like if your users are feeling pain, you should be feeling pain, I guess. Like I've always been like, whenever I started something new, like the first thing I'm doing is I'm setting up structured logging, tracing, alerting and metrics. And if things are going wrong, like I want to know, and I want to curb it as soon as possible. I think linear actually takes a really good approach to this, or at least they did.

Kent C. Dodds (22:50.22)
Yeah, yeah, sure.

Dillon (23:09.205)
a few years ago, they used to not ship features until they had zero bug reports or zero bug tickets. It's like burn down the bugs and the bad experience and then we can ship features. And like, I don't know, I feel like Linear grew a really good reputation for being an amazing product. So I think that definitely contributes.

Kent C. Dodds (23:28.492)
Yeah, yeah, completely agree. In my experience with linear, I can't remember experiencing a bug. So, I mean, that does say something, especially nowadays where it seems like every product is just full of bugs. Like the whole ship fast and break things, I think we took that a little too far in some cases. And now you can ship really fast and break things. yeah, things have changed quite a bit.

Dillon (23:34.851)
Yeah.

Dillon (23:54.275)
That yeah, the, the new age of AI is it makes things so much back to discipline. Probably your biggest asset today is having discipline and slowing down. even before we had AI, like there was a lot of like my team, I'm talking about for so long because I've only been at cloud player for so long. don't have a product launch.

Kent C. Dodds (24:10.926)
Hmm.

Kent C. Dodds (24:20.139)
Yeah, that's fine.

Dillon (24:23.927)
Like we, definitely pushed back against leadership and products throughout the months of building rebuilding because like we wanted to get it right and do it right. And like taking an extra week to nail the primitives and the foundations and get the data indexes correct. Like that stuff compounds over time and really does lead to making a better product over time and lets you in the tail end.

Move faster if you have solid foundations and now like with AI and just being able to spit out so much more code and. The code is not the greatest in the world. Like my approach and it's very, very hard to do is slow down, like scope work tiny and slow down. And I still review every line of code that an agent writes.

Kent C. Dodds (25:10.51)
Mm-mm.

Dillon (25:19.311)
Because like I don't want to lose sense of the system and the stuff I'm pushing because if I get paged at 2 in the morning, like I don't want to have to ask Opus, hey, where is this problem at? Like I want to have that intuition of knowing where to look. But it's hard because the temptation is always there to just like go give the agent a little bit more, let it do a little bit more. And then it's just like, oh, here's a 4,000 line PR.

Kent C. Dodds (25:48.748)
Yeah, yeah, I appreciate that you always set up monitoring and metrics and error reporting like first thing, because even if something slips through that you, I didn't know that you made that migration or whatever, I just missed that, or I didn't consider how that impacted this thing, having that monitoring in place is super crucial. I actually...

I even put Sentry on my personal projects where I'm literally the only user. like it just, it's so good to be able to just tell my agent, Hey, this broke. maybe I know what it is. Maybe I don't, but I don't want to work on it either way. Like I want the agent to do it. And so say check Sentry, here's the ticket, whatever. And, and go and get that fixed. And to be clear, this is not a Sentry sponsored podcast, even though Dylan is wearing a syntax sweater and I'm.

Dillon (26:43.029)
I didn't realize.

Kent C. Dodds (26:44.75)
I actually have a one wheel on my wall that's Sentry branded and I promise they have not given me money. yeah.

Dillon (26:52.857)
Well, we'll give data to love. I, one thing I've started doing, is setting up a agent to get web hooks from either century data, dog, or whatever. And like, if a 500 happens or whatever it might be, having that take like a first pass at trying to figure out what caused that error and where the gap is in the code. And then like, just waking up to a PR.

like a first try at like an error that happened overnight. Like that, that is like one of my favorite use cases for AI right now. It's just like first shot at errors that occur in prod, whether that's for like cloud flare or my personal stuff. Cause like you, like, even on my stuff that I'm just like running for like my wife and I, whether it's like a budgeting agent or like a thing syncing our Gmail calendars, like. I like if I have to go fix something, I just want the data to trace it.

Kent C. Dodds (27:33.938)
That is good.

Dillon (27:52.367)
Um, like I really do think observability and metrics and tracing does play an important role in building good products because it gives you, it informs you of what's happening where you'd otherwise be blind or you'd have to be doing like ad hoc queries against probably either sample data or on the libel data sources. And, um, yeah, that's always been like something I don't even know where I've learned.

Kent C. Dodds (27:53.229)
Yeah.

Dillon (28:21.987)
to value that so much. Like I can't think of like any one place. I feel like it's just like always been a thing that I've done. But yeah, good observability. Do it everybody.

Kent C. Dodds (28:32.79)
Yeah, that is good. And the alternative is a user comes to you and says, hey, I experienced this bug and I've been experiencing it for months. And apparently so have 500 of your other users that you didn't know. And now you're asking them like reproducibility steps and all of this stuff where you could have gotten all of that from having good monitoring in place. like that, you need to consider that as part of the user experience.

My user experience is crummy because anytime there's a problem, I don't want to report it because it's just this whole thing. Now I need to reproduce and whatever. yeah, it really does feed back into that product and user experience.

Dillon (29:01.006)
Yeah.

Dillon (29:16.077)
I think that's like, feel like the trend is just like getting good feedback cycles and like, it's like a combination of like good feedback cycles and just like, I don't know, taking pride in your work. And like, I don't know, that's something like, even when I was working on tiny stuff, like, I don't want people to think of this stuff I build as like lazy or sloppy or like, I want to give my users the

It's a representation of me, right? Like it is my work, it is my name on it. I don't know.

Kent C. Dodds (29:48.418)
Yeah, yeah, 100%. Earlier you said something that I thought was really good and that is if the user is having pain, you should have pain too. And that like is, comes back to aligning incentives. Are you incentivized to fix things? The developer that's gonna get replaced by AI is the one that takes the...

Dillon (30:06.553)
Mm-hmm.

Kent C. Dodds (30:15.85)
ideas from the product manager and goes and builds them. And that's all they do. They're not internalizing the use cases and caring about that user experience. The ones that will be able to continue to be valuable are actually the ones that have been the most valuable all along. Everything's changed, but nothing's changed. The most valuable software engineers are the ones who can really appreciate and serve

Dillon (30:37.72)
Yeah.

Kent C. Dodds (30:45.474)
the users can, and when I say appreciate the users, it's like appreciate what their life is like using your software and taking on themselves that pain so that they can be the ones to fix it.

Dillon (31:00.473)
I think, yeah, I think having like, I hate to use the word agency, but having like high agency and like being proactive about the problems with your application or even thinking of like new, new experiences or things that would make it just like so much better. That was like, so one of my favorite things about working with, I had a bunch of young guys on my team at Bricell, like Reese Sullivan, Ethan, Elliot, like very young 20 year olds.

But like they had such great product taste and like every day we'd just be working through things, things that suck. Cause they're like, you know, we're dogfruiting it. And then we'd like come up with like random ideas. Like you can like copy a Vercel domain and it will give you like an OG image of like that domain on Twitter. So like you can share your domain searches and it gets like a really good experience on Twitter. Like just like, I don't know, like that's cool. It's exciting. Like no one else is doing it. Like it's just stuff like that.

Kent C. Dodds (31:51.191)
Hmm.

Dillon (31:59.107)
Yeah, just wanting to go above and beyond. I know there's not always time for that or the liberty to do that with deadlines and stuff, but where you can, yeah, just make, like, I think that just goes into like making the product you want to use, right? Like, would you enjoy using your product? And like, we built the features into Vercell domains that we wanted out of a domain search and provider.

Kent C. Dodds (32:25.11)
Yeah, for those listening, you should listen to the episode with Wayne where he talked about delighters. This is a great example of a delighter where it's not necessary. You don't have to have it. But when you stumble upon it, you're like, that was kind of cool. I kind of like that. And it does a couple of things. For the users, it's like, wow, these people really care about this.

Dillon (32:42.895)
Yeah.

Kent C. Dodds (32:51.822)
Like they put effort into that experience, which is a good positive thing for you and your perception. I think it also does something for yourself to actually care. And it makes you care about that. And like you said, there are conflicts with time and whatever. The nice thing is that implementation of something like that actually doesn't take all that much time anymore anyway.

while we're slowing down and being very thoughtful about the way that we structure things, it's okay to send off a prompt to make a little delighter here and there.

Dillon (33:35.631)
Yep. And like, I am not the world's greatest front end dev or UX. Uh, but like, even then, like, I don't know. I feel like just over the years of just like using things like, you know, linear and just apps that have been known to have, you just learn what is good. You'll symbol, like you said, symbol upon, so you're like, Oh, that was

That was nice. I didn't need to do this thing or it just automatically happened for me. Like picking up on those things over the years, think also, leads to building like that intuition or taste for building these kinds of things. and like, think you see this too, like with, like cloud players invested a ton in revamping our dashboard over the past eight months or so. like our design team. Yeah. Our design engine team is so good at.

Kent C. Dodds (34:23.094)
I've noticed.

Dillon (34:27.981)
these type of things. It's just like.

One, just like their taste for design, think is really, really phenomenal, but there are just like little subtle experiences, whether it's like with workflows and the AST graphs or, you know, getting into like, uh, some of the querying stuff or the analytic, whatever it is, there's just like subtle little things. It's like the next step up, which is like, you can always have a nice, beautiful design system that design engine design worked on and it makes it look good, but it's like the features that.

cut steps out of the way or just enhance the experience in some way, just really take it above and beyond. like to be able to build those things, need, like, I believe you need like the solid foundations. Like if you're not building the solid foundations that, you know, are built on good error handling, good alerting, good observability, good code patterns, and having knowledge of your code base and patterns, like you're not going to be able to move.

as fastly or ship those things when you want to when the opportunities come up.

Kent C. Dodds (35:35.668)
I kind of have a question about some of those those sorts of features and especially delighters. When you implemented the like social sharing of a domain search, what was there any temptation to like, probably not this, that's pretty small thing, but like you can probably relate to implementing something that you're really excited about. we've got to somehow communicate to new users or like users who show up here.

this has got to be part of the onboarding flow or something like, I want to make sure that they don't miss this because it's a really, really cool feature. How do you balance that? And like the opposite where users are like, don't give me a tour of your thing. Just let me use the thing. how do you make sure that they, that the right user knows the right features that are going to be most helpful to them versus like for some people that would be a really useful feature. And for others, they don't even care at all. And it's like, that's, that's a tricky thing.

Dillon (36:06.639)
Yeah.

Dillon (36:34.659)
What is the, there's like a phrase around this. It's like simple as easy, but easy as in simple or something like that. we'll go with it, but like, I think this is a really hard thing to balance. And I think this is something both cloud flare and herself both struggle with despite having like good. Like DX teams, like a lot of stuff in a dashboard can overwhelm you or like when you're like onboarding, imagine like.

Kent C. Dodds (36:42.2)
That sounds good.

Dillon (37:04.354)
I have to go through six steps on board to JIRA when it's like two for linear. I think.

Dillon (37:15.215)
Giving, yeah, this like, it's hard. Like I don't even know like the right way to answer it. It's like, it just goes back to like knowing your users, empathizing with your users and understanding like, what is this tool or this app's core purpose? And like, are we fulfilling that need? Are we fulfilling it right? And do we have that foundation right? Because like until that core thing is met and successful and...

Kent C. Dodds (37:23.778)
Hmm.

Dillon (37:44.223)
going well, like you can't waste your time on doing delightful stuff, like back to getting the foundations right. And I think...

Yeah, it's just listening to users. I'm trying to think about like, worked when I first started at Versailles, I worked on a part of the, like the onboarding signup team and like, we had feedback all the time that it was like, there's too many steps between going from like new account to deploying a repo. like, we only found that through like going through customer triages and talking with, you know,

Kent C. Dodds (38:20.279)
Hmm.

Dillon (38:28.715)
a new user that just onboarded, like what was not good about this? Like where did it fall off? Or like if you have like, you know, like an honest metric tracking of people, how did they go through your app? Like you can see where people fall off. And I think that's, good feedback cycles and yeah, empathizing. This is all really coming back to just like caring and trying hard at the bottom of it.

Kent C. Dodds (38:52.002)
Yeah, yeah. And talking with users, I think that kind of leads me back to another thing I wanted to ask you about. And that was, like, we talked about how, depending on the application, you're going to have a handful of users, or you could have hundreds of thousands or millions of users. And with those bigger user bases, you've got a lot of different personas or jobs to be done for those users.

and it can be kind of noisy. And lots of the time, the problem isn't necessarily that they're struggling or your application doesn't support what they're trying to do. It's just that it's not intuitive for them, but maybe it's intuitive for these other people. And so you like say, okay, I'm gonna go fix it for this person. Well, that breaks it for this person. you, okay, well, let's just make sure it works both ways. Well, now you got two ways to do the same thing and it makes it more complicated. And so you're just playing this game of whack-a-mole.

all the time and eventually you all decided, okay, let's just rewrite domains, know, like start from scratch, fresh slate, whatever. And sometimes that makes sense. Sometimes it doesn't. And I actually call that problem elimination where you're looking at the problem tree, you solve the problem, that creates a bunch of other problems. That solution comes with its own problems. Then you solve each one of those and then you turn into this big tree structure. And so sometimes you can just.

go backwards up that problem tree and say, what if we didn't solve it that way? What if we solved this problem this other way? And now your problem tree goes this way. and that's basically just like a fancy way of saying trade-offs, like, you know, of different solutions. But anyway, going to a rewrite is like going all the way back to the beginning of the problem tree.

Dillon (40:29.667)
Yeah.

Dillon (40:36.365)
Yeah, I will say that like.

The rewrite of domains was a distinctly unique situation. Rewrites of systems like that very rarely succeed. I think it was a combination of the right expertise, the right people, the right time, and a good bit of luck. And quite honestly, leadership believing in us. I think.

a lot of times, most of my career has not been rewrites. It's been, especially through consulting for six years. It's like, most of the time when consultants get hired, you're not, things aren't unicorns and rainbows. It's normally like a dumpster fire. And just figuring out, what is like the most important high impact thing I could do to start reducing the most amount of pain points. And like a lot of times that comes from

Kent C. Dodds (41:21.87)
Hahaha

Dillon (41:38.081)
either customer escalation reports or like internal data. Like this tool is consistently crashing at 2.30 PM every day. Why is this happening? Like go find the data, investigate. All right, we can fix this thing. I think.

It also takes failing and making bad decisions here and also succeeding sometimes and like knowing.

Kent C. Dodds (42:01.238)
Mm.

Dillon (42:06.559)
when to make those judgment calls on like what the right thing to fix is or if a refrite will be successful or has a high chance of succeeding or failing. That yeah, you just have to botch it enough times to know what works and what doesn't work.

Kent C. Dodds (42:24.022)
Yeah, sure. And sometimes it's not necessarily a full rewrite, but it's like looking at the landscape of all these issues and saying, they're saying this is a problem and they're saying this is a problem. They're not really related, but they could be if we go back up the problem tree and we go a totally different direction and we've completely eliminated both of those problems and a handful of others. there's just a different way to do it that we didn't. And this is why I keep on telling people that you don't solve problems you don't understand.

Because when you do that, then you solve it wrong.

Dillon (42:54.019)
Yes, 100%.

That, yeah, this like goes back to like, yeah, I think just like really having to understand the problems and the pain points is like the most important thing because like, if you have the knowledge of your system, how it works end to end, every nook and cranny and every terrible code path you've committed, every missed place on observability or every corner cut. And then you also have good visibility into where.

all the errors are happening where customer escalations are happening, where customers are falling off on UI journeys. Like it gives you so much more, I don't know, valuable information for making smart decisions. And like, once you have like the experience of having built systems over five, 10 years, like you start to see a lot of the same patterns over and over again, right?

Kent C. Dodds (43:40.675)
Yeah.

Dillon (43:51.399)
And it just gets easier to be able to make judgment calls on what's going to be high impact and worth it and where to start on tackling those things.

Kent C. Dodds (44:02.69)
Yeah, I think the difference between a really great product engineer and a software developer is of course like how much they care about the user experience, but also how much information they have about the problem to be solved or the job to be done.

Dillon (44:20.953)
Yep. A hundred percent. That like, it's like also like, that's why I think like making like cross or relationships is super valuable too, because like your, the users of your application are not your only users. Like your product trickles into finance and into legal and into customer support and into product and like getting to know how every single one of those people interacts with.

Kent C. Dodds (44:41.713)
Hmm.

Dillon (44:51.063)
the downstream consequences, positive or negative, of your system. Just, again, another good feedback loop of information into how your system works holistically.

Kent C. Dodds (45:04.034)
This is interesting. This is the second time that I thought like a good way to level up as a software developer is to go to lunch with support sales, finance, like hang out with those people. We don't have to just be the software developer crew over here doing our thing, but actually being really integrated in the business is how you distinguish yourself and provide actual value in the company.

Dillon (45:30.615)
A couple of things, I've done this a couple of times throughout my career, but like, if you work in a, in a company where your product is big enough and you have like a customer support org, sit down for a day with the support team and triage cases with them, it will be so eye opening. And this like goes back to why I said, like customer support orgs are sitting on a gold mine of product information. Like if.

Like people talk about products and design and engineering, not talking enough, but like really it's like product and engineering should be talking to support way more than they are anywhere. Because like, I think that's where so much low hanging fruit and valuable information is. like, honestly, just good outcomes for the business. Because like, if you can save customer support, you know, hours and hours and hours every week on some reoccurring problem.

Kent C. Dodds (46:07.757)
Hmm.

Dillon (46:23.917)
That's hugely valuable to your company. Freeze them up to take on more important things. Yeah. Yeah. Get to know your support org and empathize with them as much as you need to empathize with your users.

Kent C. Dodds (46:38.318)
I just think that's fabulous. And as we get toward the end here, I always ask for one specific thing that you could tell people to do to improve their product engineering or their product sense. It sounds like just sitting down with support could be it, but is there anything else that you want to tell people they should do to improve their product sense?

Dillon (47:01.199)
I would say my hand wavy holistic advice is try hard and care a lot. And then like more practically focus on foundations and primitives. Make sure you have good feedback systems to know what's going on with your products, where the product doesn't feel good. And that could be alerting and metrics or customer journey stuff or customer interviews.

And like if you work in an org that has like a customer support team, like sit down with them and watch them triage cases for your product.

Kent C. Dodds (47:38.094)
I think, how's this for a sum up? Make pain painful.

Dillon (47:43.501)
Yeah, it's a good one.

Kent C. Dodds (47:45.986)
Yeah, that's good. Yeah. All right. Hey, Dylan, this has just been a fabulous talk. You clearly care a lot about users and that user experience. And so I appreciate the insights that you were able to share with everybody. What's the best way for people to reach out if they have questions or want to keep up with what you're doing?

Dillon (48:04.143)
Hit me up on x.com, the everything app. My DMs are open and I'm down to chat about stuff like this literally whenever.

Kent C. Dodds (48:14.648)
Very cool. Thanks so much, Dylan. Thanks everybody for watching. We'll see you in the next one.

Dillon (48:18.755)
Thanks so much.