Soft Skills Engineering - Episode 455: UX designer without a mentor and I get bored too easily and stressed too easily

Episode Date: April 7, 2025

In this episode, Dave and Jamison answer these questions: A listener named Dakota asks, I’m a UX designer, and I’m constantly looking for growth opportunities. I’m having trouble finding mentors to help challenge me, as every time my boss/senior designer leaves the company, I assume their work and we don’t backfill their spot or my old position. This leads me towards podcasts like this as I’m trying up-skill and to learn how to be a better team member and support other roles. I’d love your perspective on working with product/ux designers. What have the challenges been? What makes you love working with a designer? Have there been times where you’re both arguing for the best user experience, but fail to agree on what experience is best? Hey guys! It seems like lately, I only work in two modes: Stressed and tired Bored and disengaged I often get to own large, urgent initiatives. I spend weeks or months on them. This work is fascinating! I end up being stressed, tired, and counting days until my next vacation. When they finish, I go back to regular tickets - ones that take a day or two, maybe a week to complete. And its great! For a few days. Then the boredom sets in. I pick through the tickets, trying to find something interesting. I finish a ticket and realize there are another 4 hours before the end of the day. I start to miss the rush of working on a complex puzzle, even though it’s terrible for my work/life balance. A month or two pass, and a new complex and urgent initiative comes in. The cycle continues. So my question is: Is this a common feeling? Are there ways to find a “easy-work/hard-work” balance? Do you have any advice on not overworking when urgent tasks come in, and not dying from boredom when there is no interesting work?

it takes more than vibe coding your way into a sev one outage to be a great engineer this is soft skills engineering episode 455 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software engineers who just would like to blame ai when the system goes down i think you can vibe code your way out of an outage probably right you just give it yeah just give it the way into it yeah yeah hey fix this although there is that old that old adage that says the mind that created the bugs at the limit of its ability is not equipped to solve the bugs that it created yeah maybe that applies to ai too yeah it's like what is that can god make a rock so heavy that he cannot lift it right i don't know the answer

to that but i do know that i can create a bug so complicated that i cannot debug it yeah how do you know that yeah that's true i just haven't been successful yet but you know and i know from experience at least that i'm capable of creating a bug that someone else has to fix uh should i thank our patrons yes i was hoping you would all right thank you to the folks that support us to the level where we shout them out or actually we should count up how many of these are actually people's names most of them are not names

yeah we say words that you type in yeah the fewer names the better honestly names are fine still we want to thank you or say the thing you want us to say and so we will do it thank you to some may call this junk but me I call them treasures sounds like a movie reference

of some kind thank you to Noah Labhart I began working on my dad jokes cron job but planning and estimating the requirements for it will take me at least one more week then it cuts off a couple of weeks ago a patron said dave laughed now but you didn't why i don't like the tone these are taking alexander kuznetsov nick molyneux attribute error none type has no attribute to string javier gonzalez chewy ted timbrel i quit my job in 2025 and got a way cooler one as a software dev thanks ssc podcast yeah and i do the cha-cha like a sissy girl okay i also don't like that one yeah for the record i do the cha-cha with great

grace and aplomb become a senior engineer.com is a newsletter you should read unsalted french fries are morally objectionable generating side projects with ai so jameson notices my resume dan from drone to play chase w norton never is not just a crater on mars flamingo emoji i like chicken i like liver meow mix meow mix please deliver trash panda get status kyle boss kensi dodds developers developers developers developers developers developers developers developers developers developers develop nicely done i had to count with my mouse yeah you did you did exactly the right number i was i was impressed listen i want them to get their money's worth and not one letter more i can't just be given away words um nivar is not just a planet in the vulcan system

jenny kim the stochastic parrot helicone.ai best observability tool for ai red panda is best panda how much wood could a much woo wood could a woodchuck could is this like a threading joke or did i have a brain aneurysm yeah um jonathan king is an eye beautiful functional user documentation bethany dj tim and sasha due to ai productivity gains williamangel.net no longer sells your data with love ragnar not my chair not my problem that's what i say braden canes john grant britney ellick joe grossberg come to the slash new conference in newcastle australia may 28th and 29th moldy hard skills are safe to eat just cut one inch around the mold moldy soft skills must be discarded in cody sale oh that is genius

that was a good one thank you thank you thank you thank you i i look forward to discovering what you lunatics put in every week you mean you very informed educated highly skilled people yes you type in if you want to join this group or get an invite to our slack team you could go to softskills.audio and click support us on patreon any dollar amount will get you an invite to the Slack group and enough of a dollar amount will get you a one-time or recurring shout out. Thank you. Thank you. Thank you. Do you want to read our first question? Yes, I do. This comes from a listener named Dakota who says, I am a UX designer and I'm constantly looking for growth opportunities. I'm having trouble finding mentors to help challenge me as every time my boss

or senior designer leaves the company, I assume their work and we don't backfill their spot or my old position. This leads me toward podcasts like this as I'm trying to upskill and to learn how to be a better team member and support other roles i'd love your perspective on working with product slash ux designers what have the challenges been what makes you love working with a designer have there been times where you're both arguing for the best user experience but fail to agree on what experience is best hmm have you driven them away sounds like a pattern here every time your boss or senior designer leaves you they flee you they yeah or i mean that's one way to look at it or also you're just so darn effective that when you inherit their position they don't feel the need to

backfill you because you can actually do the job of your boss and your old job that sounds like a better way to put it nice work nice work dakota impressive some developers have a good eye for ux i do not so i love good designers and and appreciate it very deeply i i know you can i i think the the cool thing to say now is design is how it works i guess that's always been a cool thing to say but but like products and ux are different things and and i feel like product is a wider category and encompasses much more than just the the user experience and that i do enjoy and collaborate more with and feel like i have more to contribute than just like i like how you align things and i would not have noticed if you didn't i was gonna ask james and so you you'd feel

like you don't have a great eye for UI design, but are you saying that... Sometimes people say that they mean, I don't know how to design a good UI, but do you feel like you can recognize a good one when you see it? I don't think so, because every time I work with a designer, I just say, this looks great. And surely it can't all look great. But to me, it does. It all looks great. And then a year later, when we come back for the second iteration to whatever, I don't know, we learned all this stuff. We're building a new version of this thing and look how much better it looks. And I say, that looks great too. Wait a minute. I thought the last one looked great. Yeah. Okay. So, I mean, I don't know. I think I recognize it to some degree, but I don't,

I doubt my senses, I guess. I'll put it that way. I'll say that if you want to really have, like if you want to, as a UI designer, if you want to have co-workers who are really appreciative of you and you do great work for them, just work with Jameson. Yeah. He loves everything you do. it's so great all of it incredible excellent no i do have feedback sometimes on on things i definitely feel the i would not be able to design this yeah i don't know maybe i have design blindness do you do you dress well do i dress well i'm just wondering do i shower regularly maybe that's the first step of dressing well no i do not dress well but i feel like i could tell i i could if i wanted to i just don't yes

so it's not so much a matter of taste it's a matter of effort or unwilling yeah i i think so i think that's more of it yeah i don't know well that's interesting i i am i i have always considered you someone with an eye for great design because probably more so than most people you're someone who turns me on to new products and stuff out there like you introduced me to some great note-taking apps over the years and a few other things that are kind of like modern and hip and cool looking and they're definitely pushing the envelope on ui design i feel like and meanwhile i'm in like vim you know and you're like oh check check out notion you know this is like eight years ago or something yeah maybe maybe i just hang out with the right cool kids or

something design hipsters yeah do we still say sitting is that huddled underneath their table listening to the conversations they have. And every once in a while I understand a word and say, oh, affordances. Got it. Affordances. Oh, I love that word. Can I tell you about the best UI designer I've ever worked with and what made him the best? I would love to hear about the best UI designer you've ever worked with. So I am interpreting this question to mean, how do you as an engineer perceive a great product designer or UX designer? And what can they do to make your life easier. And I want to just before I tell you who the greatest one of all time was, for me, I want to tell you first that I appreciate that impressing your engineers and working well with

engineers is not the only priority that a UI designer has. You know, it's an important part of the job, because ultimately, they have to build the thing you want them to build. But there are many other facets to this. So I just wanted to recognize that there's a little bit of humility required when I when I say this, but from my vantage point, the greatest UI designer, And you know what? I think I'll just name this person. I'll just say the name. This was Grant Gordon. And what made Grant so great was that he would not just put pictures on the screen and say, go build this. He would usually build a small prototype proof of concept version. And this was at the time we were at a web application product company. So he would build a small web application

that did what he wanted us to do. And so we now, instead of just working from like Figma or screenshots or Photoshop, you know, images, we were working from a reference implementation. And because he actually made himself implement the full user experience and actually interact with it, they were great. And so when we went to implement it, we had like no questions. It was like, oh, I see what to build now. Whereas like, to me, the number one thing that UI designers come up short with when working with engineers is they don't actually design the full product. And I think a good, a good metaphor for understanding what I mean by that is imagine a designer who, who's in charge of designing a door for a car and they design the interface for

pulling the door open. Like, you know, how do you, where do you put your hand? What levers do you have to activate? What are the buttons involved in opening it? But then they don't design the closing mechanism or the closing like how how the door should work for a user to close it like i feel like that happens all the time in ui ux design and then the engineer is like great but how do you close it and they're like oh a lot of times i feel like they just didn't didn't think about it or they just assume the engineers would fill in the gaps but it's like look we're engineers we are really not good at filling in the gaps like you need to tell us what to build yeah yeah so sort of a a sense for completeness of experience and i assume that includes like error states and

kind of edge cases and it's all the stuff that's outside of the happy path that i feel like the happy path usually gets pretty well covered but what happens if you come here from this other part of the app and and you've got this different context or like what's the focus experience like or that kind of is that is that the level of what you're talking about are you talking more about product features. No, more like within a feature, how does it work? Yeah, right. Like step one inch off the happy path

and suddenly they have nothing for you. Like, how do we show errors? Like what happens when they click this button and the thing that they're trying to do doesn't work? Where do we show that? It's like, oh, I didn't design that part, you know? Yeah, the best designer I ever worked with, I'm noticing some commonalities here.

She could write code. She was pretty good at it and probably could be a great engineer but just leaned onto this design side and it led to some of the same outcomes you're describing where she was aware of what it took to build the thing for real and so considered all those cases yeah she also this this is kind of a i guess you could see this in multiple angles it maybe it was like a weakness of the team or there's always some amount of loss that happens when you translate a design into a product that engineers build and ship. And some of it is hard requirements of, well, this thing is impossible, or we had to

make these trade-offs. Some of it is they missed stuff or didn't sweat the details. And she would just go in and fix stuff in that code base and submit PRs. Yeah, it was incredible. You could also argue maybe the team should be better at not missing those details. But it was so nice to have like like a like a safety net for catching things yeah it was so nice to have a safety net because if you don't have that the the the feedback loop is so much longer where someone yes someone on the design team will notice a thing and say oh this is wrong and then you make a ticket and it goes into your backlog and then it has to get prioritized and then you have to go fix it and and it was just she would just notice the thing and say oh keep going keep going james it goes

into the backlog and then eventually it gets into sprint planning and then a developer picks it up and works on it and then qa validates it and the developer deploys it to production and then it's like oh if you had caught that in the early phase yeah yeah where she would just say like a five minute thing the padding is off here now it's not i exactly i don't have to take a screenshot to point out which part of the app it's on oh yes yeah just think about that yeah think about that process just like a fix that takes longer to communicate about the fix than to do the fix yep if you can do it yourself that is amazing yeah i love that and there's certainly more to being a great designer and great to work with for engineers than knowing how to code and i've i've

worked with designers who are great that didn't contribute technically in that way but my favorite ones to work with have all been technical enough that they could contribute i'm sensing a trend because someone once asked me who my favorite product managers are and i've also told them like former developers who are your favorite people yeah people just like me are all yeah it turns out if you look at things through if code is the most important thing then yeah you and i will work well together can i riff on on your thing jameson so yeah you know not all not all designers are going to have the skills to make code changes and deploy them and get them merged into your code base but you can still all designers can still get early access and the sooner you can spot design

issues in the development life cycle the better and the less frustrated your engineers will be with you. Like Jameson was saying, it's like if I put something out there and I'm working on it right now, but it hasn't been through QA yet, it hasn't been through our CICD pipeline, it hasn't been out to production, that's the best time to get feedback. And I think a proactive UI designer will knock on the door, the metaphorical door knocking of an engineer to say like, how's it going? Can I see what you got so far? And you'll be able to just nudge the ship in the right direction during those little reviews, rather than having to go get out the tugboat and stop the boat and, you know, and push it backwards and back into the port and go dry dock

on it again. So it's just great. The earlier you can get engaged in the process, the better. Yeah. Yeah. And I want to say one thing to clarify there, because when I say earlier in the process, of course, the UI designer is involved early in creating the designs. But then some UI designers, they act as if that's a handoff, a one-time handoff to the engineers to go build and ship. but really you now you need to stay engaged in the early part of that development and once it meets your satisfaction there then you can kind of disengage a little more and wait till it goes actual to you know to production yeah i'm trying to i think this is table stakes but being open to collaborating when when the reality of how long it takes to build your design

hits the beautiful pixels that you've created i don't think i've ever actually worked with a designer that has been bad at that or that's been a struggle um so i'm kind of assuming that's sort of table stakes but like i'll say it out loud for completeness anyways that as part of the work of implementing a thing you run into things that were easy to design that will not be worth the cost it will take to engineer them or maybe you you just aren't aware of how long it'll take so you should be good at talking to engineers and understanding what parts of it will be hard and and not some of it you can kind of estimate and squint out ahead of time while you're designing, but you don't have to know everything. Not the engineer. Yeah, the engineers don't know how long it'll take all the

time. Yeah, true. But you should at least be able to collaborate enough after you've produced a thing to say, what do you think? And then they might say, this piece will take three weeks. And you say, that is the piece I care the least about. Whereas if you didn't have that collaboration, they would just go into a cave and build it. And then you'd say, why is this taking so long? Yes, that is a great call out. I've seen some cases where UI designers, they choose some patterns or styles that engineers know are going to take a very, very long time because maybe they're not part of the standard design components that they have in their library, or maybe they have to do some custom development to get a widget to work just right. and they'll you know the engineers will often dutifully you know they will salute the designer and march off the cliff to make what needs to happen happen even though it's it'll take weeks and like you said the designer might come back and go oh i would have been fine with just standard

tabs there i just did this cool stylistic thing that's like oh my gosh i spent three weeks building those tabs for you that's a true story from my recent history maybe the broader principle is know when it's worth it, right? There's some parts of the UX that are super important. And even if they do take a while, you will still want them done. But you should at least be able to call out, this is a nice to have, this is the core of it, and kind of talk about those time trade-offs. And I think one of the cool things about being pretty technical and having the ability to code up your own prototypes is that you will have an intuition for what's more time consuming, especially if you choose to build in the same kind of tools and framework that your developers

are building the app yeah what have the challenges been i think so this was not a ui designer this is more a product person but the most frustrating product person i ever worked with was basically a an email filter between the customers and the engineering team and they would just say not even a filter just like a pass-through yeah actually a pass-through is a better way to put it they would just say hey the customer wants this and then we'd go build that yeah no distilling into a feature or a core underlying problem or pain that that's solving or whatever and the best product people i worked with were great at identifying this core underlying problem and they would always have a hypothesis for why this is the right thing to build and why this is the

right solution for that problem the hypothesis might not always be true but they should at least be able to articulate, like, why are we doing this? Why is this the right thing to build? Why is this the right problem to solve? Yes. And a great UX designer can take a problem from a customer and turn it into a solution that solves that problem and 15 others, you know, rather than just that one specific problem. Yeah. Yeah. By the way, I have a name, a colloquial name that I use for people in business who pass information along but don't add value. What's that? As an example, they would just forward an email from a customer and say, here's the customer has a problem. Build this. Yeah. I call them very expensive tubes. Yeah. Tubes with, I don't really mean it. It's

a little bit meaner. It probably sounds meaner than I intend, but it's, it's a, it's a metaphor that I, that I use to hopefully evoke a strong reaction to be like, Oh, don't, don't just be a tube. You know, if you find yourself shuttling information back and forth, like my job is to forward emails that come in from the customer yeah like nope that's the email server's job your job your job is the human part because we only pay the email server like you know pennies per hour yeah i want to say one last thing all of this depends on the engineers that you're working with and there's different brands of engineers just like there are of designers i think the best designers i've worked with have made it easier for engineers to get engaged in product decisions

and thinking sometimes that's with engineers who already care about it and are passionate about that and sometimes it's with engineers who are not and just want to go write code but either way kind of pulling them into those discussions earlier and getting feedback and helping them see what's going on behind the curtain i think that helps motivate engineers to build things and helps them make decisions about trade-offs if they kind of have a model to go on of why things are important and how you think about

what the right thing to build for users is. For sure. I have just one more thing, and we're kind of taking a long time on this question. I guess we're pretty opinionated. This is not one we've addressed before, I think. Yeah. Understanding the job of an engineer,

there's something that I think most front-end or most UI designers don't appreciate, which is that in front-end development, especially web application development, it can be up to 70% or more of your time as a developer can be spent on handling edge cases where it's like, okay, I've built the main thing. It's a form.

The user fills out the form, submits it. And there's seven things that can go wrong along the way. I'm going to do input validation on the client side but then the server can also validate it and they come back with an error. There can be different kinds of errors that I need to be aware of where it's like that username is already taken

or you've reached the rate limit for submitting form requests. it's like all these different things that can go wrong in the process all need to be built. And if they need to be built, but you don't design them, then you're not going to have a great product. And the engineer is sitting here thinking, well, thank you, UI designer, you just handed me a design that covers 30% of what I now have to do. And what do I do with the other 70%? And I think that's a common point of misunderstanding between front-end engineers and ui designers i like it yeah i feel like i could keep talking about this for a long time but

we we must proceed onward to other questions this is a good question thank you for asking yeah it's great and actually it really it reflects well on the question asker to say i want to do my job better and they actually ask the people they work with who are in different roles that's great i should probably do this actually more often yeah i was just thinking that too what would my co-workers say if i asked them this yeah you'd have to ask co-workers from a different company because the co-workers with you would be too nice to say anything to you they actually would as they cower in fear my wrath yeah exactly nothing all right everything's fine all right should i read our next question sorry yeah go ahead james thank

you this is from a listener named tired or bored hey guys it seems like lately i only work in two modes one stressed and tired or two bored and disengaged i often get to own large urgent initiatives i spend weeks or months on them this work is fascinating i end up being stressed tired and counting days until my next vacation when they finish i go back to regular tickets ones that take a day or two maybe a week to complete and it's great for a few days then the boredom sets in i pick through the tickets trying to find something interesting i finish a ticket and realize there are another four hours before the end of the day i start to miss the rush of working on a complex puzzle even though it's terrible for my work-life balance a month or two pass

and a new complex and urgent initiative comes in the cycle continues so my question is is this a common feeling are there ways to find an easy work hard work balance easy work hard work nice do you have any advice on not overworking when urgent tasks come in and not dying from boredom when there is no interesting work oh this is very interesting i i definitely fall into this boat as well yeah where i get super obsessive with the work for a period of time an unsustainably high level of investment and then crash i think i do too what do i do i so i like firefighting i identify with this large urgent like yeah i want to i want to jump into the fire that's something's on fire i want to go help put it out it's exciting it's fun it feels nice to feel

important and helpful and stuff so i get that and i do not do a good job with work-life balance when that happens yeah one of the i guess this only applies to things that are actually broken there's often a way you can you can stop the bleeding quickly and then kind of go back and do the the longer term fix kind of more normal working conditions that feels like more of a tactic than a i mean what strategy the alternative to this like super hot super cold uh periods i think you kind of smooth out the peaks and valleys you're sort of yeah slightly stressed and tired or slightly bored and disengaged because you can't always just be 100 on all the time yeah so that's not the answer right you'd eventually burn out or yeah collapse but you also don't want

to be bored 100% of the time. So, I guess I'm questioning whether this is really a problem. I mean, I guess, of course, if you work so hard during the crazy times that you start to have health problems or relationship problems or any number of other problems, of course, you pushed it too far. But I kind of like the cycle of, okay, it's almost like how they say, a crisis brings clarity. It's like no one has any prioritization questions when they're in the middle of a crisis it's like all right let's just get this thing done yeah and i enjoy that period now of course if it goes too long that's a problem so like i i think maybe that's the the short answer here is don't let the stressful times get so wild like learn how to manage your time a little

bit in during those times just to take like a 10 off the top of the effort curve yeah we at work actually lean into this a little bit where we we alternate between periods of the whole team focused on getting a larger initiative out quickly and and we kind of ignore everything else to the extent that we can and then we back off for a week or two and take a breather and pick up all the stuff that is piled up while we're really focused on getting the initiative done and we have more slack time so we can explore things that are not directly being requested or or things that give us more leverage stuff like that and i really like that pattern of like go all in build this thing have kind of a time box and then step back and look around and take a week or two to

clean up your workplace a little bit kind of and then and go back into that that's less responding to urgent initiatives that are that are thrust upon you though that's more like our deliberate decision but you could look at it as time to recharge for the next urgent stuff and and time to make the urgent stuff easier like i don't know you beef up your monitoring so the next fire is easier to detect and fix or something like that i like that i like that maybe that's what you need so so there's like two problems here one is of course too much time in too extreme of a mode and the other one is too little engagement during the boring times and i love that idea of filling the boring times with and with things that will anticipate and reduce the stress of the crazy

times like i love that like beef up your monitoring set up alarming maybe work on like a auto healing project or something to prevent a crisis next time i love that i think that's great maybe you kind of need like a tech debt backlog that you can pull from when you're not being when your demands on your time are not so great. I think you've just hit on a thing that's been tickling my brain for this question, which is, I feel like engineers, if you give them free time, they're always pumped to dive into technical fixes and improvements. And it's sometimes a struggle to say, no, we got to focus on the most important thing for the business. But it feels like this question asker specifically kind of thrives and gets energy off of being

being much more business critical and i'm kind of surprised that that you don't have a bunch of stuff that you would like to get to when things are less crazy yeah especially since you and maybe that's another key is during the crazy times instead of attacking every little thing that comes up create a place where you can record those things so that during the boring times you can do that so like for example like you know if you if you're sitting here working on a crisis and you're like gosh it would be great if these logs had a little bit more metadata in them so that i could query better because i'm gonna have to write a bunch of code to go find all the data i'm looking for in these logs instead of doing that in the moment writing all the code just

instead create a list of these things for later and then i think you'll solve two problems number one maybe take the edge off some of the crazy during the high stress times and give yourself something really fun to do during the boring times yeah i wonder if the urgent stuff is less the system is broken and more like we need to crank out this feature really quick it probably is it probably is those are those can be harder to anticipate and give you more leverage like say i don't know say you you build up this awesome component library no component library survives first contact with product design like yeah but surely there's something that you can do maybe you don't have the freedom to pick stuff and and you just kind of get chucked back in a in a team

that pulls things off of a queue that you don't have a lot of influence over that could be part why it's so boring too yeah it could be where it's like thou shalt not work on anything except for the adobe sorry the product backlog yeah where part of the nice thing with firefighting is as long as you can say this will help me with the urgent thing you you just get to go do it so maybe there's some i don't know some more wiggle room or some more autonomy you can push for in the boredom time to make it less boring it could also just be like suck it up and eat your vegetables i don't know that's that's that's why they pay you money to do the things that they think are important that you are not super pumped on yeah i don't know i i think i feel like

we've given a bunch of options to try i think so and and i i do think that this question is probably most reveals to me mostly that you need to incorporate a ruthless prioritization system especially during the crunch times and then have some engaging things to work on during the slow times because it sounds to me like you and this is probably true of many engineers but you're happiest when your mind has something to chew on during the the less crazy times you know something you can think about when your mind is idle something you can design and turn over a design in your mind like oh man we really need a new logging system let me think through that you know it's like okay i finished my ticket for today let me go plug away at that new logging system

yeah yeah all right i think we've answered the question what can people do if they would like their own questions answered if you'd like your own questions answered go to soft skills.audio and click the ask a question button thank you so much to everyone who submits your questions each week we read them with jittery anticipation when they arrive jameson often giggles they are wonderful i i like that image just tapping our feet really quick oh we got a question coming down the pipeline what if we imagine we had what are those tubes they used to use in banks i guess they probably still pneumatic tubes yeah yes maybe we need to make a pneumatic tube patreon tier where yes you you become a patron at that level desk yeah yes it

will result in a mechanical thing landing on our desk from a tube yeah i would call that a very expensive tube but beloved oh beloved yeah i mean this is not yeah this is not a bad expensive tube Now I'm imagining what would it take to just like hook up a printer to the API that we store all the questions in and then literally actually do this. That would be so wonderful. All right. I've got some side projects now. Okay.

Totally. Thank you for listening. We'll catch you next week. Bye-bye.