Write it down: process, benchmarking, and product judgment with Ronan Berder

Kent C. Dodds (00:00.949)
What's up everybody? It's Ken C Dodds here again, talking about product engineering with my new friend Ronan. How are you doing, Ronan?
Ronan Berder (00:08.248)
Very good. Thank you for having me.
Kent C. Dodds (00:10.325)
Yeah, thank you. And I a couple of weeks ago I was posting on the internet just asking about people's past experience building products for users and and the issues that they've had with that. and you replied we went back and forth quite a bit. ultimately I said, you know what, I want to just have you on the podcast to talk about how you think about product engineering and building products for users. and so to kind of set
the the framing for our conversation. Can you tell us a little bit about yourself and your background?
Ronan Berder (00:41.432)
Right, well, I'm an engineer, but well I'm an I'm I'm an engineer that actually ended up moving to China in two thousand and five. a few years later I ended up creating my own consultancy and yeah we we ended up selling the business in twenty twenty two. right after I moved back to well, right after I moved to Singapore.
and yeah, I mean through through those years in in China, we built a lot of products for companies like Nike and Dululeman and Burberry and Hilton and there was a lot of like obviously very very local stuff on WeChat and and other social networks in China. But yeah, I mean a lot of e-commerce, a lot of like a lot of consumer facing applications, I would say. And a lot of it was you know at scale. So we had usually
you know, tens of millions of users right from day one when we actually released. So it was always like a little bit a little bit tricky to get to the finish line and a little bit stressful. but yeah. so so yeah, that's that's probably where my quote unquote experience came from.
Kent C. Dodds (01:45.109)
Yeah, wow.
Kent C. Dodds (01:53.811)
Yeah, that's a that's a scale that most entrepreneurs would would just dream of, or maybe even wouldn't be able to dream of, having that level of scale so quickly.
Ronan Berder (02:06.102)
Yeah. well China was always a very differentiated market, a very very odd and specific in many ways. And yeah, we got good opportunities to actually do what you wouldn't do in other markets, right? Because you China is so differentiated that they actually had to all those brands had to gradually actually launch applications that were really localized and built in the market for the market, which in most other markets they don't do. they usually do just like, you know, global launch and it's very kind of like more of an iterative process.
as a as as opposed to China where like at least for the years that we actually were running the consultancy, a lot of it was you know, from the ground up, usually kind of a fork away from from from the global app. And it gave gave us that opportunity to really rethink entirely the experience, build something that was very different from what the rest of the the rest of the the the brand was doing in in in other markets and and yeah we we we we had the opportunity to to launch like you know to go from zero to
millions to tens of millions of users really, really quickly. So yeah, that was that was kind of fun. But as I said, I was mostly running the business. And while I was, you know, trying as an engineer and always had an interest in design, I I was mostly doing people management and finance and sales and all those kind of things that you have to do when you're running a business. none of the cool stuff, right? but I did I did, you know, work pretty closely with our engineering and design teams and I would
you know, on on many occasions actually try and help them build mostly playbooks and better processes and sometimes spare hair like, you know, specific projects.
Kent C. Dodds (03:42.741)
Yeah, cool. you you say that like you didn't do any of the cool stuff, but but like I think that in the in the context of our conversation about product engineering, one one of the things that you have to do as a product engineer is really understand the domain really well and go deep on what the customer's problems really are and what their life is like and and how your how you can solve the jobs that they have that they need done.
and so it with your experience in sales and that sort of thing, you you had to convert what the customers actually needed into either like expanding the product offering to satisfy those needs or or fit that into what your existing product offering is. Can you tell us a little bit about that experience?
Ronan Berder (04:33.666)
Yeah, I mean a a lot of had I mean we we were kind of more of a a partner than you know rather than a vendor with our customers. Like a lot of what we did was actually pretty unique. i for example with Adidas and you know like is a good example where the product we actually launched was was a first globally. I think that was when they were selling all those Yeezy
Yeezy shoes and you know, we we did like a a pretty unique take on like how to actually go and approach selling that in the Chinese market. so we didn't really have a lot of prior art. and but oftentimes like even if it was a brand that had been running for a while, they they definitely just didn't perform and they ended up coming to us to not just to go and execute on like, hey, we we want to build like, you know, a a a mobile app or a website or or whatnot, but
Hey, we don't really know what's actually going on. we don't really know how we should approach the the Chinese market. can you help us kind of figure it out? And so our our discussions were always like, you know, with VPs and and and and C suite and you know, really with like middle management, at least at the beginning, very much focused on how we can actually help the business. And so a lot of a lot of the time that we spent initially was on what we would call like the strategy bit.
it's just understanding like where they are in the market, you know, what does it look like actually currently, who who they actually selling to, who's the audience, benchmarking, which I always love doing, like benchmarking against their competition, and trying to go and size up like what what's what's even like the business looking like and what your competitors are doing and what what should we actually go and start with? you know, like when we worked with Stux, for example, we had a lot of
Like we could have started with iOS, so Android, or the website, or a ton of the work that we actually had to do in the background, or we could have started with do we start with loyalty, do we start with with with delivery? Do we start with something else? so you really have to go and size up and kind of figure out like, okay, what's what's even gonna go and get us the the best result, which is not necessarily the you know, the the the best kind of
Ronan Berder (06:51.916)
volume from the from the audience in the first place. You also have to go and consider the dynamic of the client and sell themselves, right? Like see you if you move too fast in some cases, you you're just not gonna go and succeed. You have to go and deal with the fact that you're dealing with like a very large organization that has a lot of bureaucracy and a lot of a lot of politics involved in it. And so so yeah, that's that's usually where we started. we we ended up, as I mentioned, I was pretty anal about it, pushing for
pretty structured process for doing everything from you know the very initial stages of like even situating the client, figuring out where they at, to then you know, like which we call usually the discovery, like collecting at assets, auditing the brand, auditing what they've actually done so far, starting to go and benchmark them against their competitors. and then moving on to strategy where we did more work around like, you know, trying to go and get a brief, which sounds kind of ridiculous, but getting the client to sit down in a room
and then or or your team even and and agreeing on like a common vision of like what what what is it that we're even trying to go and address and and things that sound even sillier that I always insisted on which is can we define the terms and defining actual words so that we don't kind of talk past each other without understanding really what we actually trying to go and address. And then we would just like from there start to go and map out like a happy path. and then moving on
Beyond that, then we would start to go and do like preparation work. You know, it was like getting into epics or user flows or, you know, depending on like the teams that were actually involved, information architecture, mood boards, and all the kind of like the prep work for starting to go and work on the actual execution, including planning. And then after that, it's you know, your regular kind of execution, execution and delivery cycles where we actually go and obviously
would do that iteratively very often, kind of starting with design and then gradually well, sometimes even just strategy purely and then moving on to design and then moving on to technology and then towards the end, more with the the infrastructure and security bit.
Kent C. Dodds (09:02.815)
Wow, dude, there are so many things in that that I want like different things I want to to pull on. so I on on that last one, since since that was the last thing that you you said, during those execution delivery cycles, do you have a mechanism or or some advice on how to tighten the feedback loop so that as you're building, you're reminded, okay, what was the vision that we discussed earlier?
are we making sure that we're following all of the epics and user flows that we created? And and like sometimes I would imagine that the as the client is seeing what you're building, or hopefully I I suppose you would be sharing that with them, they say, you know what? I actually hadn't thought about this when we talked about this earlier. I want to change this or that or the other. Like, how do you manage that relationship to make sure that by the time you get to the end, you actually built what they really need?
Ronan Berder (09:57.038)
Yeah. So unfortunately in many cases, at least the first release, you don't really have that luxury. You kind of you kind of have to please the stakeholders mostly and then just make sure that you're selling a vision that they can buy into. And that's about it. Like you can't really just we tried that a few times, but it's very hard to actually go and do beta testing when you're actually you're working with Nike and just about to go and release their first weather.
e commerce app, they're they're just not gonna go and even talk about it to
Kent C. Dodds (10:29.469)
interest so so it's not so much that like y there's a technical limitation it it's a interest from the client. Like th they just weren't interested in making sure that you were building the right thing or wh what do you mean?
Ronan Berder (10:41.376)
No, no. I mean, we you discuss it with the clients. What I mean is you're you get the perspective on like whether or not you're building the right thing from them mostly. And and obviously you do you have a very educated guess because you're looking at metrics, you're looking at competitors, you're looking at what what you actually know, the audience. You know, those companies have a massive amount of data. And so as opposed to when you're just an indie hacker or you have a small team, you actually do have the luxury of doing like if you're doing a rollout of even a very simple
Kent C. Dodds (10:48.354)
I see.
Ronan Berder (11:06.914)
Which we've done on occasions, right? Like trying to go and gauge the interest from the public for a certain form of like experience or a certain way to actually go into e-commerce or a certain channel and say, well, but maybe WeChat would actually work well for them. You have the opportunity to go and do a single campaign and then run that single campaign for two days. And you have you have like millions of transactions that went through the system and you can figure out how do they actually use it, do they really like it? Was it viable? So so you can get some validation. But what I mean is if you're
If you're actually running with a small team, you can actually go and invite like you know 10 people, 20 people, 50 people to go and beta test the product and really kind of refine how things actually go well. that doesn't really happen in that in that in in that sense, like it with with large organizations. Usually it's pretty hush hush. I mean it's pretty, you know, they they they don't really share that as as openly as you would with a small team. But then when it comes to then the internal the internal dynamic with the team, I would say that engineers were always the
tough us to really align on the product vision. And I think that's you know something that AI hopefully will change in that sense because it it's it's changing the nature of the role that that the the engineers have on the team. but yeah it was always difficult to really get them to pay attention to what it is that the client is trying to achieve. What is like well not even the client, but like what are we trying to go on and hit in terms of goal with this product? Like and
Kent C. Dodds (12:06.871)
Hmm.
Ronan Berder (12:33.026)
The end goal is not I built an API that just you know kind of has like all the right tests and and checks out against the the open API specs and and you know did what we we agreed on doing. The the goal is to go and launch a product that is successful, secure, scale well, and and performs well in the end for for the end user. And if we don't hit that, then then we have a problem. so
So I think that just you have to go and hammer it over and over and over again in every single session that we do. And obviously, because we're doing those, you know, you're working with very large clients. So we have to do a lot of even prep work on presentation. So for example, on design, when we present a when we present like any sort of like design artifact, whether it's the design system, the mood board, the early early exploration, the benchmarking, or later on, like you know, introducing new components or or or user flows.
This is just a wall presentation that we have to prep for, like, you know, like an hour or two. So you have like designers working with you, putting in the assets in there and doing that. And we did the same kind of the same kind of presentations internally as well with the engineering team to go and make sure that when we actually yeah, we're actually going working on like a sprint and we had like a set of features. There was before we even get into like how we actually go and break down that into epics and user stories and whatnot, that that
Kent C. Dodds (13:33.014)
Yeah.
Ronan Berder (13:56.322)
There's understanding as like that's that's the thing we're trying to build. Like once we're dumb, this should look and feel like that. And this is why we're building it as well. Like that the goal is to go and achieve that. And the reason why we're doing that is because we think that is gonna do X amount of like, you know, that's could potentially upflate the experience in this way, or it's gonna help us like kind of like reduce that part of the flow and just like, you know, improve the numbers, or we would have like kind of
Yeah, and I guess like going back to what I was saying initially, like it it comes from the brief. Like we would have also internally a pretty a pretty structured document that we always used that was like a single one page of brief for what is it that we're building. Right. So but again, as I said, yeah, there were a lot of steps before that came into the hand of an engineers. And I think nerds always wanted to and when I say nerds, by the way, I I mean it like it's an endearing term. I I've I've you know I I would call myself a nerd as well.
Kent C. Dodds (14:26.848)
Mm, mm-hmm.
Ronan Berder (14:52.468)
but it was always hard to convince them to pay a bit more attention to what happened outside of just the the IDE.
Kent C. Dodds (14:59.933)
Yeah. I'll I'll tell you, like that tracks. I think a lot of us nerds, myself included, are just really interested in just getting to building the solution. And I I think that there's a good reason for that. It w as you're building it unc it answers a lot of unanswered questions. I think that like that's that's part of the the logic behind why Elon just launches the rocket and sees what happens. You know, like there's you just learn a lot from just going to do it. But
It can be very expensive, and especially if you end up building the wrong thing, which is why you're talking about communicating the North Star to the engineers you know up front, doing all of that that work up front. so yeah, that's that's a little bit tricky. but I think for software engineers, we actually really need to get good at this because yes, we can build things much faster, but if you're building something faster or going the wrong direction, that's not helpful for anybody.
Ronan Berder (15:56.76)
Yeah, one thing that always got me really because I could even just get and understand how you can get distracted with your because you're basically solving puzzles. And it's really fun to solve puzzles. Like it's really fun to work on something, figuring out how you're gonna build it, end up building it, learn stuff in the process, which you know, learning stuff is really like the part that I prefer about, you know, this craft. And then and then it works. Like it's suddenly it's just it clicks, it works.
Kent C. Dodds (16:19.883)
Mm-hmm.
Ronan Berder (16:24.864)
And it and you can put it in front of people and and it's fun. But one thing that always really just got to me was the the fact that most engineers don't even try to benchmark things, which always you know always seemed to me like, well, you could just go out there, try to figure out who the competitors are, get a sense for how the product actually works out. You can even, in many cases, actually reverse engineer how they build stuff, and you can just get
Kent C. Dodds (16:38.166)
Hmm.
Ronan Berder (16:52.172)
80% of the bullshit out of the way. sorry. I don't know if we're allowed to swear but but you can get that out of the way and get to the interesting problems, right? Like rather than just trying to go and figure out from the get-go, you know, how do you even just go and and and achieve certain things, it's just gonna go and steal ideas from others and really just get more quickly to the interesting parts, which again, going back to then AI, I think just like makes this process even just easier because can get a lot of answers quickly, a lot of bad answers too, but
Kent C. Dodds (16:54.615)
Hmm. That's yeah.
Kent C. Dodds (17:09.9)
Mm-hmm.
Ronan Berder (17:22.082)
You can get a lot of inspiration really quickly and actually go and get to the interesting piece a lot faster. So yeah. I guess benchmarking would be a a thing that I would emphasize for engineers.
Kent C. Dodds (17:24.449)
Mm-hmm.
Kent C. Dodds (17:35.113)
Yeah, it it sounds like data has been a really important part of your career and and in your past experience. I wonder how like most of the data that we've talked about so far has been the quantitative stuff that you can actually measure. And at a scale of tens of millions of users, and that makes a lot of sense. I wonder, though, if you ever sought out qualitative data to kind of guide the directions of like
what you end up building for your clients and whether that ever worked out well for you or or how you saw that as an input into your decisions.
Ronan Berder (18:12.334)
Yeah, I'm not sure how you would define it, but obviously, you know, we went through a process of like because you we we use a lot of benchmarking and data and and this and that. But at the end of the day, you know, you you gotta go and build something that feels right. So there's a lot of stuff that's not necessarily kind of written down on paper. There's sometimes you just feel like, you know what, the solution we came up with, that's fine, but I think it's a local maximum and I think we can do better or it just doesn't feel right.
And you know, I had to do that like a couple of days ago with a piece of software that I wrote and then realizing like nah it just doesn't get it. I have to rewrite the whole thing. 'cause it's obvious there's a better way. but but yeah, I mean and and same for especially when you get into the the design piece, like everybody's got an opinion about it. not a lot of it is like necessarily measured. and and it's fine, like I to that to that extent actually, as long as you have like
As long as you have a process and a structure that just allows you to at least like get the fundamentals right. And by that I mean in design for a lot of what we did was actually just a design system. we did that really early on. was like really working purely with design systems, because it really just helps you kind of lay out the mechanics and you know, you can just then on the on the UI part, kind of like get a little bit more creative or just satisfy the the
Kent C. Dodds (19:25.527)
Mm-hmm.
Ronan Berder (19:39.212)
the the sensitivity of like such or such stakeholder, but at least you can just get the actual mechanic right. and and then the process part is, and I wrote a bunch of times about it online, is you need to have a process. And it's maybe more obvious with engineering, because we we have a lot of process, we have a lot of tools. I think we've we've had to go and collaborate a lot more online with a lot more people a lot earlier.
than design has. I think design has only been doing this like since what? Well, I mean, for probably like a couple of decades now, but like really seriously, I think since Figma really, like from what, like twenty seventeen ish, people have started to really just start to go and have to collaborate on not even just real time, but I mean like you have a canonical source of truth. It's that URL, you go there and it's not just sending a bunch of files around like around around by email.
Kent C. Dodds (20:18.645)
Yeah.
Ronan Berder (20:36.532)
And yeah, I mean, I think I think engineers have developed a great sense of like, you know, processes and collaboration and how you actually go and structure your role process and how you then build upon like the existing process to quite try and make it better. Designer is not so much. and and I was always like really anal about this as well. You know, I worked with the team fairly closely, the design team, multiple times to try and go and iron out the process that made sense because like it is a very creative
Kent C. Dodds (20:52.001)
Mm.
Ronan Berder (21:05.634)
potentially creative department I mean activity. but it doesn't mean you can just go and and and do whatever you want, however you want. And actually it defeats the purpose of really being creative. Like I think number one, you need boundaries. If you don't have boundaries, it's kind of like the blank canvas. You can't really do anything creative if you have like some amount of boundaries. and and then if you want to get better.
which was really my main point was always like if you don't have a process, you will not be able to get better. You you'll get lucky sometimes and do amazing work, but you won't be able to go and consistently deliver at a certain level. And if you can't consistently deliver good, you will never be able to go and consistently deliver great. You'll occasionally maybe you'll do one great thing, but it's it's it's not gonna be consistent. And if you can
Kent C. Dodds (21:47.775)
Hmm.
Ronan Berder (21:54.574)
Just if it's inconsistent, then it people are not really gonna look at you as being talented or reliable. It's it's it's it's just useless. It's like, well you know, you roll the dice and maybe you get like, you know, great results, but yeah, anyway. so yeah. I guess that's my rant about designers.
Kent C. Dodds (22:10.101)
Yeah, it's no, I I think that's so interesting. the the statement that if you don't have a process, it's I actually I can't remember exactly what you said, but like you fail effectively without a a a good process. clearly you have strong feelings about a good process leading to good outcomes. my question is, how do you develop a process? Like what are the elements of a a process and a good one that will actually
create those good outcomes.
Ronan Berder (22:42.06)
Yeah, I mean listen, I can I can give you my version of it, but I think again, like a the most important thing is that you need a process. And then you need to work on that process as you go. so I I again I can give pointers and even writing a book about it. that's that's called write the fucking manual. Because if you're gonna read the fucking manual, then and again, sorry for swearing, but this time it's actually that's the official kind of
Kent C. Dodds (22:52.321)
Yeah.
Kent C. Dodds (23:05.808)
That's the title of the book, yeah.
Ronan Berder (23:07.692)
Yeah, I mean it's RTFM. I think any engineer out there will know it. but yeah, you need you need to write the damn thing before you actually go and ask people to write to read the f the the manual. and and yeah, so I I I I believe strongly that like, you know, especially if you're running a business if you're running a team, you gotta go and write things down. it it's not only for for three reasons. obviously people are gonna go and look at it and say, well, yeah, if you have a process you can delegate.
Yeah, that's great. That's kind of like the more actually the third item, the kind of later stage. If you have a process, you can actually go and delegate. But most important are two things. Number one is if you write things down, you'll probably actually get to a better place in terms of your own understanding of your process. very, you know, very often to go and again look at maybe something not so related to engineering, but you know, I I talk to engineer to entrepreneurs these days, and you know, we're talking about their sales process, and oftentimes like ask them, like
Do you have an actual sales process? Do you understand who you're selling to, how you're selling, why they're buying from you? What are the main kind of like the the sticky points for them? Why do they not go to your competitors, who your competitors are, et cetera, et cetera? And the usual tell yeah, yeah, I have a process. And I well, okay, well, show it to me. It's like, well, I don't have it written down, but I understand things well. Right. And and the problem is like you it could be any process, it doesn't really matter, but you don't have a process if it's not written down. And so
Kent C. Dodds (24:09.376)
Yeah.
Kent C. Dodds (24:24.971)
Yeah, it's just in my head.
Kent C. Dodds (24:33.505)
Hmm.
Ronan Berder (24:33.568)
it then just force them to write it down. And then they realize like there's parts of that that are not exactly clear for themselves. And then the second thing is like usually almost every single time, there's a lot of it that is not actually clear for their direct team. So even to go and create alignment with your direct colleagues, it's it's incredibly hard to do that if you haven't written things down. And then once you actually go and get that also firmed up, the main thing is
Kent C. Dodds (24:57.452)
Mm. Yeah.
Ronan Berder (25:02.282)
You're not building on quick stands anymore. you actually gonna have a foundation that could be wrong. It may not be the right process, it may not be a good process, but at least you have a starting point that you can then start iterating upon, right? Like you actually have a a code for your process and you can start saying like, okay, I'll disagree with that part. And then we can have an argument as to why we should change it. We have a common vision of what it is called and and and how it works, and and then we can just have the have the debate, change the process, and then
Once again, like then you have the communication aspect of it, just making sure people understand what what the new process is like, but but yeah. so I really believe that you should write things down. and again, not because you can delegate more easily. That's that's more of a later stage thing. as to how you structure it, I actually have like usually the same layout over and over again. but I think I think you should I think there's like of there's a few things in it. Well the first thing is
you gotta go and map out obviously the process at a high level, even if it's just bullet points. like how do you go from A to Z? pretty important, obviously. Prior to this, though, usually what I do is I try and define the terms. As I mentioned earlier, I was kind of annoying my team often with this. but if you say release, like what do you what do you mean by release? and you don't have to be overly anal about it either, but
Kent C. Dodds (26:26.22)
Hmm.
Ronan Berder (26:29.618)
if a term is not really fully understood, or if people just don't use exactly the the same terms on a team, it's gonna get tricky quite quickly. and then and then you have to go and make the distinction between the different levels of of of knowledge, right? So in large organizations and and larger processes, obviously you kind of have like kind of a pyramid of of knowledge.
You have the stuff that's absolutely almost never changing, that's kind of like maybe changes once a year. And you have the stuff that's like pretty sudden, but like may actually change, like, you know, from one quarter to another. And then there's the stuff that is a little bit more chaotic, that's not necessarily super reliable, may actually go and you know, be already kind of dead or not not not so up to date anymore, or may actually go and change on the day today. And then you have that role cycle of also how you actually go and
and and and and create and and and migrate the content like up that pyramid so but again we're talking about much larger organizations i think paramount to anything you're doing is even if it's you know 10 lines on a on a on a note on your on your laptop you should understand how you actually go and do things whatever it is that you're doing like how do you go you want to go and launch a new product from from the get-go do you at least like put a tutor list together
With like, okay, this is how I'm gonna go and start. This is what I'm gonna do after, even if it's wrong, because at least it will force you to go and think about. I don't know how you do that, right? Like, but oftentimes I'll I I'll end up just when I when I can tell that I'm starting to enjoy a little bit too much the craft of like building the product and not so much the craft of like the the art of actually launching it. I'll realize like, okay, I'm gonna do a list of the things that are actually kind of like left that I think are left.
And the things I still have to do to be able to go and launch it, the things I have to do after the launch. And then and then I start to also kind of prune the stuff that doesn't go in there and start to organize it in buckets that actually go and make sense. And so so yeah, more important that what goes into the process is like just have a process and it works.
Kent C. Dodds (28:40.213)
Yeah. So the as far as like the scope of of processes, it sounds like you're suggesting these can be really granular or they can be really high level. So you can have like a a process on specifically how we create a new component in Figma and like get that over to the implementers and then get that into the application. Or it could be like whole product process of like what what phases we're going to get to.
through to release and then beyond that for like getting feedback and and like that feedback loop. But am I understanding that right?
Ronan Berder (29:15.042)
Yeah, more or less. I I would say that the more people you have on your team, the more granular you have to be. Right. I mean, w we had a hundred and sixty people on my team. And so when you have it's not necessarily a very large company, but it's not a team of seven anymore. And when you are that size, like you definitely need like, you know, you you need processes for a lot of things. And that goes down all the way to like SOPs for we had an SOP for how we actually prepared
Kent C. Dodds (29:20.095)
Mm.
Kent C. Dodds (29:29.868)
Yeah.
Ronan Berder (29:45.016)
Design decks. Like when you present to a client, there's a template, there's a way you fill it in, there's a way you actually go and present to the client. So there's do's and don'ts. And this is something that you can actually go and work your team on. Like whenever somebody graduates into leading a team and has to go and do the presentation to the client, you know, you can train them through that process and you have some sort of consistency. Because again, you go back to it's not so much about is this the best process or not, but does it allow you to go and reach a certain level of consistency in your hours?
Kent C. Dodds (30:14.977)
Mm, mm-hmm.
Ronan Berder (30:15.348)
And if you're very much like a much smaller team, you don't really need that much structure. If you have five people sitting in a room coordinating like the long it like a to do list is fine. Just to put a to do list together, agree on what the big like, you know, the big items are, and then just get on with your your day, right? Like as long as you've kind of, you know, you can just trust that on the team of like five to seven, like you you handle your stuff, you're the designer, you know how to do this, you're the head of like whatever the
you know, you're the lead developer, you know what you're doing. Like just make sure it's actually done on that timeline and these are the big items that we have to go and ship with the product. And I think that's good enough.
Kent C. Dodds (30:52.747)
Yeah. And and those individual players can have their own processes that they've like written down and and it it sounds like you you said earlier if you don't if the process isn't written down, then you don't have a process. And I think that I was going to ask you, okay, well, so why is it so important to have it written down? But you kinda answered that it's it's important because it helps you come to grips with the fact that you actually don't really have a well thought through process or there are gaps in your thinking and yeah.
Ronan Berder (31:18.766)
you you may as well, but there's value in articulating it. Like I still think that writing is vastly superior to to like talking about things or thinking about things. You can think about it, but as soon as you start to put it on paper, you start realizing the gaps in your process or you know, your gap in your understanding, or you know, you realize like, it doesn't make sense or it doesn't feel right. that's not something that you can come up to as easily when you're just thinking about it or talking about it.
Kent C. Dodds (31:29.173)
Hmm.
Ronan Berder (31:48.236)
Now you may actually go and have some I mean talking is great you also have like so I mean obviously like you can have conversation with somebody else and then you know they they bounce out an idea and you realize like, yeah, of course we should do that. That's so much better or it doesn't necessarily come out of you just sitting down and writing things. but but again, like especially if you have a team, I think having an actual artifact that you can point at with the rest of your team and then just say, that's how we do it. Does somebody disagree or do you not understand what it means?
just seeking alignment through through through through read and communication rather than you know trying to go and do it through just a just a casual meeting i is is much better. Yeah.
Kent C. Dodds (32:18.679)
Mm.
Kent C. Dodds (32:29.407)
Yeah. Yeah, that that makes a lot of sense. I I was going to ask earlier about how you communicate the North Star to engineers, 'cause like we talked about a little earlier that, you know, it's engineers just kind of want to get into building the thing. and it sounds like having a written process actually is a an effective way to keep engineers on the rails and and not not that like I I don't want people coming away from this thinking that we think
engineers are always going off the rails. But like I I think as as an engineer, it is easy to do that. To and it's always a concern. Like, am I building what I'm supposed to be? Like is this the the right direction that I should be going in? And as an engineer, being very tuned into the process makes me more valuable at the company as well.
Ronan Berder (33:00.586)
Ha ha.
Ronan Berder (33:21.74)
Definitely. Yeah. I mean, with AI coming in especially, I think you should you should seek to yeah, you should you should try and get like perspective on the product and design part of things. And the the and that means as well the business, right? When I said product, to understand like who you're actually doing it with, how does it work? And and if you can actually go and get interested as well in things like marketing and whatnot and sales and and you know, I think having more perspective on
Kent C. Dodds (33:37.516)
Yeah.
Ronan Berder (33:51.276)
Other aspects of the the entire machine is always is always good. and as you know, we had a quick chat before, but I think I think AI is definitely gonna be particularly challenging for engineers, at least for now. That seems to be the obvious target of of pretty much every single AI lab out there. so yeah.
Kent C. Dodds (33:56.033)
Yeah.
Kent C. Dodds (34:15.243)
Yeah. Yeah. It it seems like converting a ticket into an implementation is pretty replaceable. and the the higher level system thinking is a lot harder to replace. Maybe one day it'll get replaced, but right now, understanding the whole system and and the the boundaries. Like actually ten years ago, I w was just kind of well
longer it's been over 10 years now, but like as I was just getting into the industry, something that people kept telling me was you need to understand your layer of abstraction and one layer below. So like if you are working in the browser, you're you're writing JavaScript, you should understand what the browser is doing with that JavaScript, right? that helps you use JavaScript more effectively. And it sounds like the same thing applies to the business, the processes, the the the actual goals of the organization.
Ronan Berder (34:54.477)
Yeah.
Kent C. Dodds (35:09.243)
is like, yes, you you are this cog in the machine, but like you gotta understand everything that you interact with and maybe even everything that they interact with as well.
Ronan Berder (35:17.868)
Yeah, I mean that w that works more kind of vertically, kind of like you can go deep and you can go you can go higher. and I think that that always that's a that's always true. Like I if you can actually want to understand the N minus one layer, it's it's always better. You'll you'll just always achieve better. And I think in that sense, current engineers have like a huge I mean if you've been doing this for like five, ten, fifteen, twenty years, you you have a huge advantage over somebody who's just starting their career right now.
Because it's gonna be a lot harder for them to actually go and get like the all the paper cuts and all the scars of of actually building stuff yourself, like pains they it's it was it was. it still is to a certain extent painful, but when you didn't I mean, I don't know, I I'm forty five now. When I started kind of playing with computers in two thousand and one, I I really started to
I mean, I I wanted to do open source pretty quickly, probably in like twenty two two thousand and two, maybe two thousand and three, when I started to do PHP and I started to go and learn how to program on my own. and we didn't have GitHub. Like I didn't even understand half of what was was going on. I barely spoke English back then. and you know, you went online and you tried to figure out how how do you even publish things. People would have mailing lists and would send patches as like zips. I mean, it was just insane. Like you
Kent C. Dodds (36:40.918)
Mm-hmm.
Ronan Berder (36:43.554)
You would just go on those like places where people had been like collaborating for 15 years and you had like all those like you know rules that that you had to go and and pick up. and you know things were not that easy and then it got you know obviously a lot easier. but yeah, I mean I think that now you have the opportunity, if you've been doing it for quite a while, you've been through the actual grind of like writing code yourself and you know like
and now now you understand what the AI is actually doing. so you can spit run a lot of things. You know, you know what's potentially you you know, for example, what code smell is, because you you ask the AI to fix something and then something else blows up and you're like, that's not normal. It shouldn't do this, it shouldn't be that brittle. Or, you know, they tell you what the interface is, you just look at the API or the model and you're like, that doesn't feel right. Like you're you're not getting you're not thinking it right. Or you just ask the AI to go and explain to you like what's the architecture is like, well, but what happens when we do X?
Kent C. Dodds (37:17.153)
Mm.
Ronan Berder (37:43.286)
And so that's that's really the superpower, I think, of of of a current engineer. But then yeah, I mean, I think you you're gonna have to go and and go beyond that. And I would look horizontally across other departments, like, well, okay, what are people doing on the side? I mean, on the design side, on the business side, on marketing side, and how I can actually go and and you know, make myself more useful there too. because go ahead.
Kent C. Dodds (38:04.331)
Yeah, yeah.
I yeah, I was just gonna say you wanna be very aware of what upstream and downstream effects. Like where did this this request come in that like and understand why the customer needs that, what is the actual problem, and then the downstream effects of what you built and make sure that like what you built actually got deployed and is serving customers and is like, you know, you complete that loop, it's solving the original problem.
That was upstream. And the only way you can do that is if you were upstream and you understood what that original problem was. And and then on top of that, all the observability and and the metrics and and keeping track of support tickets and all of that. I yeah, like you you have to go beyond just what the what the vertical slice of implementation is.
Ronan Berder (38:54.476)
Yeah. Unfortunately you can't hide, you know, in in in your corner anymore and just like bang out awesome code. that's just not gonna be enough anymore. not to say that it doesn't exist. Like it it will exist still, I think, for quite a while. If you are top five percent or top one percent or whatever that percentage is, sure, have at it, right? and I think we all know either online or even like in real life, some people that are just amazing at it. And and and definitely you would say, okay, you
Kent C. Dodds (39:01.847)
Yeah.
Ronan Berder (39:23.704)
You can keep on you can keep on on on on on doing that. but for most other people, that includes me by the way, I think I think you'd you'd better go and catch up some additional skills and kind of figure out how you actually yeah, how how you actually navigate the transition with AI. and that's not gonna be easy for a lot of us, right?
Kent C. Dodds (39:44.833)
Yeah, yeah. so earlier you s you said something I really wanted to to dive into and understand a little bit better. you were talking about having conversations with VPs and C suite people about like the the thing that you were gonna build for them. And I I want to know a little bit more about what how those conversations go and w like how you like
Create clarity around the problem space of what they're trying to have you solve for them. And and then also maybe we you can mention this later, but I I want to know about any failures that you experienced where a client came to you, they asked you to build this, you built it, what they wanted, but then ultimately the products ended up failing and what lessons we can learn from that. But first, yeah, what what are conversations like with those C-suite people?
Ronan Berder (40:34.872)
Well, what's interesting is our our little firm was actually kind of premium. we were doing really we were calling ourselves a consultancy more than an agency. And and we always made sure our clients referred to us as a partner and not a vendor. And and yeah, we
Kent C. Dodds (40:48.375)
Mm-hmm.
Ronan Berder (40:58.646)
We had a pretty good relationship with most of our clients, which was unusual, especially in China. I mean, it a lot of the competition had had a much harder time dealing with their clients. but most of our clients came to us. We didn't we didn't we didn't chase them. They came to us, they had heard of us, you know, through, you know, somebody who had worked with us before or like some reputation because we had done like a couple of like pretty well known pretty well known programs in the in in in China.
And and yeah, so they came to us first thing. So that kind of filtered out a lot of the people we ended up working with. And because we were always working with like pretty high ups, it also meant that we had a very different I mean, even things like procurement like were were very different because we were kind of already picked by by somebody high up in the organization. As to then the relationship we had beyond that, again, like pretty much based on trust. And so as long as we actually
kind of kept on delivering, I think we're good, but we really just pushed hard on being very transparent with our with our clients and and very direct and I think it paid off. but I I don't necessarily I don't know if it's like a good strategy. It worked for it worked for us by being very direct. however I would say that like the more tactical advice here that I would have is and again that's that's what worked for me was like being hyper anal about all the details.
So whenever actually go when we went to a meeting, we went prepared. where we actually go and prepared an actual deck for them for presenting the product, we actually were on top of our shit. And again, sorry, I'm I'm swearing. You can blip them. and and and yeah, having like, you know, really, really attention to details in everything that we actually go and send to them. That from you know, the obviously the presentation we did with them all the way down to to you know the
invoice that we sent them had to be branded exactly how it should. and you know, I spending a lot of time with the with the with the team, not only kind of producing for them actual assets and playbooks and processes and kind of fine-tuning it with them, but also just working, like doing reviews. So like I would say, for example, design reviews, any project that were that was actually a little bit difficult, where the client was actually difficult, we would just go and assign a partner to them and he would at the very least kind of like review
Ronan Berder (43:23.05)
every single deck that went out to to them and then potentially actually go and let the presentation especially when the discussion was difficult. and then we had you know we had discussions that were difficult sometimes. We had to tell the client we don't agree. We I will name one of the brands, but we ended up losing them over the course of two years because we we just told them no, they wanted to do a partnership with Alibaba and we said like you should do it with WeChat. And I think what you guys are suggesting is
Silly is gonna also kind of kill the roadmap we have there, and we don't and you know they did they ended up not liking that too much. But I think we were right actually. and I think we got vindicated like a few years later. so yeah, I don't think there's like to close on that first part of the question, I think stake well a few things. I the more important part is
Stakeholders in large companies are just like absolutely regular people. the more the most average people you could meet, really. they're not particularly bright. At least if you look at the large average of people you're gonna go and meet, they're average intelligence, average skills, and and average success in their career. so so you really don't have to go and be intimidated. And that includes like, you know, CEO and I mean C-suite in like Fortune 500 or even Fortune 100 companies.
Kent C. Dodds (44:39.329)
Hmm.
Ronan Berder (44:49.282)
There's nothing really just like you know, amazing. There there are pockets of excellence in a few companies. Like we've worked with Apple, for example, and there are specific teams that we work with that was like, wow. but by and far, most people, especially the executives, like you you don't have to go and be scared. for the second part of your question was like a failure. Yeah, it happened. you know, it happened often mostly because of a disagreement as to
what the relationship really was. I think that's more specific to consulting, but some clients just expected that because they were paying us, they could just like treat us the way they wanted or tell us like when we were done. And that's just not how we actually worked. we were being brought in, and sure we got we got paid fairly, but we were brought in because we could do things they couldn't. And if they could not appreciate that.
Then fine. We don't have to work together. That's fine. we can figure out something else. but but yeah, the failures were mostly coming there from like a usually a gap in expectations as to how the relationship would be handled. and it's I I don't think it was ever about the quality of the work. I think there were sometimes kind of like, you know, some comments being made about this, but
Even the people we ended up losing didn't didn't necessarily say that we did bad work. Actually they they probably would say like they did great work, but they were either too hard to work with or this is not how we wanted to go and get things done and so heh, you know, whatever.
Kent C. Dodds (46:24.629)
Yeah, interesting. And i i it's actually kind of surprising to me to hear you say that. I I mean not necessarily I can I can definitely see how failures could stem from that. but I would expect that like there's just such a a huge stat about the software projects that end up failing. And I wonder if a reason why you didn't experience that as much is because you were so like seriously detail oriented and process oriented.
that you never really ended up building something that the client didn't really want. but I wonder if sometimes what the client wanted was not good. And I guess that's why you you s parted ways with that one client.
Ronan Berder (47:00.961)
Okay.
Ronan Berder (47:07.002)
Yeah, maybe I went on more of a general comment about failed projects. But you're right. Sometimes the tech didn't wasn't there. It happened multiple times. you know, sometimes we had like a rogue engineer who just didn't want to listen and and then just did what they wanted to. sometimes we had a team that just didn't have the right structure and ended up just not implementing that what we think the client should have got in and definitely what they thought they should get.
Sometimes, especially as we're growing faster, you know, at some point we were growing quite fast. I think in 2020, what was that? There were years we grew by 70%, for example. and I mean obviously this is not a massive team, we don't have like thousands of people, but still, like you you can feel the actual you add a lot of people really quickly, you have you have you know way different kind of problems. And in in those kind of places, as we were just like
Kent C. Dodds (47:49.44)
Hmm.
Ronan Berder (48:06.422)
Ramping up a lot of new people really quickly. We had engineers like coming in every single every single week and designers and this. you you obviously don't necessarily do the best job at at training them, or you don't necessarily have enough of the senior resources to frame the discussion or whatever it is, right? Like the process gonna break down. And and then what ends up being delivered is just subbar. It happened a few times. usually
Kent C. Dodds (48:30.367)
Mm.
Ronan Berder (48:32.546)
Then a partner would spend weekends and evenings just like cleaning things up with like a small team of people. and that sucks, but you know, that's what you gotta do. yeah, I think it was it was mostly that. And I think what also happens is as team grow as a team grows, the process changes, right? Like again, as we were talking about earlier, you don't manage a team of five as you manage a team of fifty. And I think we had like, I don't know, at some point seventy engineers on the team, maybe more.
Kent C. Dodds (48:58.401)
Mm-hmm.
Ronan Berder (49:03.014)
and some of the projects were quite large. You know, you had like 20 people doing engineering at the same time on a single project. It's obviously it's not a massive, massive team, but it's enough to actually go and create chaos, especially once you add designers and project managers and everybody else. and yeah, I mean, I think what happens is as as the team expands, as the teams the team grows, then things that used to work just don't work anymore. and you have to go and rethink the process, and it's not always obvious, right? Because like, it's worked so far.
Kent C. Dodds (49:13.259)
Mm-hmm.
Ronan Berder (49:30.86)
why why are things not working that well? then you need again, you need somebody who's got a bit more of a was able to step back and then just you know, I I I did that a few times, like kind of as I mentioned earlier with like the design team, but also the edge the recruitment team and obviously some of the engineering teams and kind of sitting down with them and then just figuring out like what's going on here? Like it's the third project that we have. We're still really massively under delivering on, for example, DevOps or
like we're always late on deliverables for for the releases and we seem to have issues there like on a on passing all the the security scans so this is going on and then you yeah you gotta go and step down and I mean step step away from the problem and just work with some of some of the leaders to go and figure out like okay well where's the prime breaking down now like where's where's the gap? And it's not always obvious to engineers like or they're very close to the process. Like they're not necessarily able to go and have the perspective.
Kent C. Dodds (50:25.077)
Yeah, that that makes sense where there are issues internally where what you end up delivering is not what the the client wanted. I wonder also if there were times where you delivered what the client wanted and then the client launches it, whatever or or you launch it with them and it ends up not being what the users need or doesn't actually solve the problem. or or were there times where you could kind of see that was going to happen and you prevented that from happening.
Ronan Berder (50:48.608)
yeah, plenty of times.
Ronan Berder (50:54.422)
Yeah. I mean both both happens plenty of times. The the disheartening part actually, especially in consulting, is really that is like you don't really fully control the roadmap. So both the failures and the successes, and you don't get to go and say like this is stupid. and when you say that you tend to lose the client, as it happened a few times.
Kent C. Dodds (51:03.756)
Yeah.
Kent C. Dodds (51:12.139)
Well th well as as you said earlier.
Ronan Berder (51:15.916)
And then in other cases, everybody thinks it's gonna work out and it just doesn't. And it and it's sometimes hard. Like we you may be closed. You may actually go and need to go and keep on pushing on a part of maybe the marketing's not working well, maybe maybe the products you're selling in the first place just doesn't is not interesting, or so it's sometimes sometimes hard to tell. and and again that I think that's something that AI is really brilliant at is you can get to
Well, at least if you're a small team, you can get something out in front of actual users way more quickly and way more cheaply. doesn't mean that I'm necessarily following that advice, but
Kent C. Dodds (51:50.751)
Hm.
Kent C. Dodds (51:56.725)
Yeah. Well and and you mentioned earlier with with these bigger clients, they don't really want you to do some sort of beta period or anything. They're just gonna build the thing, launch the thing to their millions of of users and expect it works.
Ronan Berder (52:07.724)
Yeah. And and there's enough volume that it's rare that you really just completely flop on something. and the kind of initiatives that we took didn't really call for we didn't have a lot of room for failure. We also didn't really have a lot of projects that didn't have like, you know, the full weight of the marketing organization and you know, so and the top dollars. So so it was very rare that it would not work. I can't really think of a single program that really just
did not work at all, apart from stuff that we knew in the first place is not something that they should invest in, which by the way, on on new clients, we just tell them right off the bat, like, you know, we we're not gonna do it. It's just it's it's stupid. You're gonna waste your money. and that's not worth it. And it happened multiple times. We actually and with people that ended up being great clients of ours, because we just the first time they interacted with us, we said like you shouldn't do that. And then they ended up doing it and lost the money.
Kent C. Dodds (52:38.827)
Hmm.
Kent C. Dodds (52:52.306)
Ronan Berder (53:05.834)
And then yeah, and then well yeah, but like again you're talking about, you know, Fortune five hundreds it's not it's not the end of the world for them if you're they're losing like, you know, five five hundred grand on on a program.
Kent C. Dodds (53:06.466)
no.
Kent C. Dodds (53:13.879)
Yeah.
Yeah, so how do you develop that intuition to like when they come to you and they say, Hey, we've got a ton of money for you to build out this solution? And I I think it makes sense that you would say no if you think it's a bad idea. You don't want the bad reputation, you don't want to waste your time on something that's not gonna work out. But how do you develop the intuition to know that yeah, this is not a good idea? We're we're not gonna go forward with
Ronan Berder (53:39.662)
Well, I mean, I would say if you're in a more creative space that you can't necessarily know what good ideas are. I remember seeing a very early idea a fairly early prototype of Figma, I think from a friend of mine in San Francisco who showed me a demo. I don't know if it was a video or the actual product, but I remember him that and then explained to me super excited about, you know, those guys are super bright and they're working on that thing. And then they sh he showed me some of the experiments that they had. It was really, really odd. And then he talked about
that that Figma thing and what they were trying to achieve. And I was like, there's no way you're gonna go and rebuild Illustrator in the browser. Like it, you know, it can barely just render a page, let alone like a full blown desktop application. and and then I saw it like maybe two or three years later, around twenty sixteen, twenty seventeen, it was like I was blown away. and if you had, you know, asked me like should you know, do you want to invest in this company? Just a hundred grand, I'd be like,
Kent C. Dodds (54:32.823)
Hm.
Ronan Berder (54:39.114)
No way. It's completely stupid. But it's on the more creative side of things, like smaller teams, you know, bigger bets. When you look at those very large clients, that's that's not what they're doing. They don't have to be super creative. They sometimes are a little bit more creative than their competition, but they're very rarely are like more creative than the they don't really come up with like new concepts usually. it's either smaller brands or kind of individuals or startups that are coming up with that. So so the bets that we made with our clients were obviously
Kent C. Dodds (54:40.193)
Yeah.
Kent C. Dodds (54:49.654)
Mm.
Ronan Berder (55:08.724)
Either obvious or or not obvious, right? Like so when it was a bad idea, it was pretty obvious it was a bad idea. Because you could just benchmark it against everybody else who had tried this in China and be like, it's not gonna work. It's just it makes no sense. Like you you're gonna do the same mistake that 20, you know, 2,000 other brands have already have already made in the market. So yeah, I would say that very large companies are not that creative.
Which is fine, but like you know, that's that's how logical organizations move. And so so it's it's it's easier to actually go and get the intuition on what actually works and what doesn't. yeah.
Kent C. Dodds (55:46.859)
Yeah, yeah. It it actually sounds like it's less intuition, more just data. You you go and benchmark against the competitors and see if anybody's done it before and and see if you can figure out why it failed and and if you're not doing if you're not changing the reason it that it failed, then you're gonna fail too.
Ronan Berder (56:02.606)
Yeah, but it's pretty all it it's pretty shocking when you look at large organization how bad they are at investing in the right thing. Like so many times we were more on the product side. So very often, you know, we worked with the chief product officer, with potentially the CEO or CTO and or the VPs, you know, VP of digital of e commerce or whatever. And those people are pretty business and product oriented, right? They
They've got a vision of like, you know, this is how I want to go and like design the entire kind of experience end to end and whatnot. We did a little bit of work because we our worked overlapped with the marketing. So we oftentimes had to either support the marketing team. Very often we do things like, you know, build customer data platforms or things of that nature, or we kind of have most of the interesting data in our system. And so we had to go and support them because they obviously wanted to go and make campaigns on top of it.
But it it was always surprising to me how reluctant, for example, the marketing teams were to invest in things that was boring, but actually move the needle. it was really, really surprising. Like we had to go and really convince them hard not to blow up another, you know, another 100 grand on some stupid idea that they had about like some cool concept, because like, well, the other brand, you know, the our competitor did that, it was really cool. We should do something that cool. It's like
Kent C. Dodds (57:07.308)
Mm.
Ronan Berder (57:26.784)
Okay, but where's the data supporting that this is actually gonna go and trickle down into actual sales? and could we just take like a portion of this and instead maybe invest into, you know, better better automation or better retargeting or better whatever? And it was a v always like a really hard discussion. So I think we like that as well in terms of the type of clients that we work with because they were always more data oriented, more business oriented, and more product oriented than than the average. yeah.
Kent C. Dodds (57:55.701)
Yeah, yeah, that makes sense. well Ronan, we we're over time. I I still have a bunch of questions, but I I don't know that we have the time for some the rest of these. So well well I I yeah, that fun employed. yeah, I I have to get to other stuff myself. So we'll wrap this up. But Ronan, thank you so much. That you've got just a wealth of of experience and I appreciate your strong opinions about things.
Ronan Berder (58:04.202)
I go ahead. I'm an emplo I'm unemployed after all.
Ronan Berder (58:15.384)
Mm-hmm.
Kent C. Dodds (58:23.375)
as we wrap up though, I wanna ask you for a piece of homework that you can give to folks, something specific that they can do after listening to this conversation to make themselves more valuable in as a software engineer.
Ronan Berder (58:37.966)
А за софтве інженер, а вод
Well, I don't know if it's a I mean definitely if I had if you do one thing, it's just like whatever it is that you're struggling with right now, I would I would really encourage you to write it down. whatever it may be. Just write it down and try and or organize your thoughts. And I think you'll be surprised by how how great how greatly helpful it is to go and and lay things down.
However smart you think you are, I think it it's it's it's a very helpful exercise. And it sounds silly, but it works. I think if you're really and if you're really early in your career and you don't really know what to do and you don't know if it's actually going to go and work out, and you're definitely not that great of an engineer like like me, you know, I'm too old to change. But if you were really early in your career, you don't think you can hack it as a, you know, let's say a top 20% engineer.
Maybe you want to consider sales. honestly. I think I think if you have a really solid technical background, and you can go into like things like enterprise sales, you'll make a lot of money. you'll have like a lot of really interesting conversations, you'll still work to go on interesting problems, you can still hack on things on over the weekend. and yeah, it's it's probably gonna be quite a while before people sign off on like, you know, a 250 grand or two million dollar contract.
you know, just talking to an AI. I don't think we're anywhere near close that. and if you're later in your career, you know, mid to later stages, I think you should just go and you know, just embrace the changes. It's not gonna go away. There's nothing you can do about it. It's unfortunate I love coding as well. You know, I spent years just doing people management and sales and finance. I had hoped that I would just
Kent C. Dodds (01:00:09.143)
Mm.
Ronan Berder (01:00:33.986)
be finally going back to crafting products and writing code and having fun. And it's it's just it's not gonna happen. So you know pay get get more interested into what people do outside of that, whether it's whether like design could be helpful, but I think more things like marketing and marketing and sales and and and and just like really get better at like architecture and
Kent C. Dodds (01:00:40.981)
Yeah, yeah.
Ronan Berder (01:01:00.43)
You know, like you you still have plenty of opportunities to learn, which I think is mostly what engineers love about things, is like solving problems and learning new things. So it's just you have to look at it from a different perspective. It's gonna be different type of
Kent C. Dodds (01:01:14.591)
Yeah. Yeah, I completely agree. It's the landscape's changed, but like the way that we solve problems is different now. but we're still solving problems and fixing fixing things, solving puzzles and it's still fun. So Ronan, what's the best way for people to to follow up with you or or keep up with what you're doing?
Ronan Berder (01:01:34.87)
Well, I mean I've started to use Twitter more regularly recently, so just you can find me on yeah, on well on Twitter, on X. so yeah, H U N V R E U S. it's it's a mouthful. But yeah, that's me.
Kent C. Dodds (01:01:51.809)
Sounds great. Well, thanks again so much and thanks everybody for watching. We'll see you in the next one.
Ronan Berder (01:01:57.454)
Right.