Hi, This is Rick from the fun sized podcast. Thanks for checking us out. This is upset six. And today we team up with the awesome power of the Dirt podcast for our first ever crossover episode. The dirt is an awesome podcasts about you, x and you I designed from the perspective of Boston Web and Mobile. You y u ex agency fresh tilled soil, from which we're joined by development director Tim Right, and designer and illustrator Mark Grandpa, who hosts the dirt together. In this episode, we discussed the evolution of the designer developer relationship. What? Itwas what it is and what it should be.

Should be fun. So I hope you enjoy. Ah, we're going. All right. So it's for the crossover listeners. We want to introduce ourselves. Yeah, absolutely. Okay. Um Oh, gentlemen.

Yeah. Okay, cool. So they were fun Sized me and me and Anthony. Uh, I'm a product designer of fun size Anthony from the expiry owner. Experienced director. Yeah, and we D'oh. Sorry. We do a podcast on specifically about product design and mobile design.

Grand Tim, right development director of Fresh Till soil where the hosts and team of the dirt for the fun size folks. And I'm here with Mark High on Mark Grambo. Also part of the dirt. I'm a designer and illustrator here, a fresh tilled soil on the dirt. We like to cover all topics around experience, design, from design development to larger trends and news in the technology industry. Yeah, so when one of the big topics that we've been going over in the office and on the show has been that the relationship between designers and developers and it's been like a big deal for for us and people that were you spoke with and I know that we wanted to discuss that on a podcast. So here we

are. Yeah, here we are. We've definitely kind of had similar discussions here, and we have, like, really specific ways that we like to work with developers and development teams, and it's interesting to look back on what has been and what it is now way. Certainly don't think it's, you know, really perfect. We're definitely striving to get there, you know, But maybe we can look a little bit into what it's going to be a swell.

So do you guys that fun size do the development in house? Or is that all the client?

Yeah, we don't we don't do any development in house. In fact, I don't know if we've ever had a client ask us if we do development because most of our clients are product companies. And usually the people that hire us are the product that CEO, owner, operator or product management or engineers so usually were paired up with really strong engineering teams. But, you know, for the business side, we've been pushed to be better by engineers lately. I think I think one of the struggles that we've been facing is how to keep up with them because it seems like our engineering partners know more about design that we know about development.

Yeah, that's interesting, because we have some development in house here, and but it's kind of split and, like back in development, is normally our client that we do some of the a lot of the front and development. But you guys have, ah, a similar but different pairing where you have the the design and development s'more. Hot, hard split, though, and it's it's been, Is it easier t deal like that than have it in house, where there's there's a hard line. Where you guys fighting that line constantly?

Well, I mean, I don't run no risks. Worked in some very different kinds of organization that I haven't. No, I really do want to get his input on this. But me personally, I've honestly never worked in a design studio that offered development service is Yeah. Even when I was doing what design we often when studios that I worked at were mostly boutiques there were that were maybe doing a little bit of the front end development, which we call like design technology. But I've never really been that involved in businesses that I ran. I have all been designed centric organizations. Yeah, when I was a web developers, Well, I was a web designer, Really.

I did some front in death, and before I started working, like in the product design world, started working for a product company about Ah, little were two and 1/2 years ago. Um and that was when I was introduced to, like, the agile development methodology and all that. And we were, like planning our sprints and, uh, you know, working on very regular release schedule and stuff like that. But before that, it was always like, Man,

the developer will. It's sort of like this, this constant like resistance, you know, like designer would basically hand something off. And it was sort of expected for, like, every possible scenario, to be thought of beforehand, you know, so that the developer basically would have, like, one meeting with the designer and then, like, hopefully not have to talk to him again. We've

talked about that a lot, not only with us here internally, but also working with external development teams. This notion of throwing something over the fence and what they're doing that for the developer or for your client, it's never a really great experience, right, because you're not getting any context. There's this sense of all right. My work is done here. Wipe my hands. It's like a shut up in code. Yeah, sort of a thing. It doesn't

it doesn't work right? I don't know about you guys, but nothing that we deliver is ever really done. It's just done for that sprint, so he's gonna have to find later. So right, I did forget for a moment that I worked at a work. It's been a great product. I worked it ever known, and there were two product designers and I would say, maybe 15 engineers. So that was kind of extreme, you know, balance of where? In that sort of environment, it seemed like design was owned by development. Not really collaborative, that designers were just like a tool for the developers should things. You guys were definitely outnumbered.

I think, um, that ah thought would have been really good if it had just left my brain. It's on. What are you feeling with? Um, yeah, the hand off. You had said something earlier about how, um you felt like the developers new design bear than the designer's new development. And I think there's a constant sort of risk of that, because design. Sure, you could say you're designing for the Web, and therefore it's different this great new thing. But in the end, a lot of the discipline.

We're using a lot of same standards of grids and aesthetic and function that have been used for a century. We inherit a lot from print design and from functional product design in the real world, and all of these same principles apply to the to the Web with development, especially now, with all these explosions of Java script frameworks and CSS pre processors and everything, the technology is exploding. And it's it's one thing for the developers to keep up with all the different ways that they might be expected to work. It's a whole other thing for designers for whom this isn't their natural language to keep up with those changes in technology,

right? Yeah, that's a good point. Um, it is It is definitely hard. But I think what, um, we could strive for like at the very least, is like, you know, if you're working with an IOS developer, something we're like working on is just like being up with, at least like the terminology of this, you know, certain type of controls that were designing so that we could be specific, you know, and help the developer out kind of speak their language just a little bit.

Instead of saying, Can you like, change that, You know, thinking that I made That's like, you know, you know that way, at least you know, be a little bit more like it kind of shows more respect for what the other person does, too. And I think that's sort of like a nice thing to shoot for, You know, having things not be so siloed there over there. We're over here on more collaborative and sort of like this mutual respect. I think just like a mentality altogether that needs to change. And I think it's changing.

Really? Yeah, I think that depends on the vory mutual symbiotic thing, because the development teams have to be as proactive as understanding the design language and being involved in the design workshops and understanding the the user's perspective, not just a new opinion of what they want to build on what they expect to build. Yeah, I think

it mean glad you guys brought that up. I think communication is a huge problem, and it's an opportunity right on opportunity. Yeah, and we've started doing designed for developers and developer sure designs many workshops, like during the weeks or like a Wednesday we'll sit down. Developer will lead a discussion with the designers about source order or something about responsive design, that it's important for the designers to know when they're going through the process so we can stop that uh, you know, design gets handed off, and developer says, No, no, no, no, no, no,

no. Because we've already gone over all the stuff and there's no Were we speaking the same language? Yeah. And for the design team, we're thinking of these things in advance is that source order is actually a really great example when we wanna, you know, try and think about the great ways to make responsive sites we don't wanna make something says, Okay, well, when it's on a desktop, it's like this. And when it shrinks down, everything re orders, and then this goes up here and then this turns into a seagull now, and we don't yet have the technology to transform random objects into seagulls. So Okay,

well, maybe not do that next time. And the same time we're teaching the developers color theory we're teaching. That was a great one way. Did do a session on color theory. It's cool. And what what came out of it was the developers understanding where all that where the color palette comes from and we can now generate color palettes really quickly because we know that, you know, maybe the what lightness Hugh just change 10? I don't know. The value is the U. S. Yeah, understanding HS L Yeah, it's adjusting our pre processor of sass mix ins thio so we can spit out color palettes really quickly.

Is that Are those conversations internally in your organization or you actually inviting your client? Thio. Speak to your designers and your designers were speaking to your client development partners

because we have development. And how's the those ones? Were someone from the development team speaking to people on the design team s Oh, that's internal. Those are internal externally, I guess the way we communicate that stuff outside of, you know, the day to day client interaction is things like the dirt, our podcast events that we have in the area. We try d'oh, be a source for education and community outreach on do events here. We didnt event in February that you put together Tim called Experienced Dev, which is about understanding the development interviews or experience and a lot of this kind of stuff a lot about the relationship between designers and developers, and we had some designers in the audience. We had some developers in the audience and we had a lot of like sea level people in the audience. A lot of marketing team. We really had a very diverse set of people in the audience,

and it was a nice day for everyone to be educated on, you know, seeing how the other half lives walking a mile, someone else's shoes. It was a good opportunity.

We're big on that. Like we like Thio open up. We try to keep unopened desk in our office, and we just sort of like, let random people that apply for it to come in and spend some time with us. And we usually just have, like, a little bit of time set aside in the day where we can hear a little bit about them and what they do. They might be a developer, designer or somebody that doesn't do anything really related to what we do. But we like to open that up. And I wanted to back up real quick and discuss something that you guys had mentioned about the H s L thing. Um right, H s l u saturation And what? Well, like this lightness. Yeah,

and then there's, like, just be depending on the right. Well, the reason I wanted Thio just just touch on that was because it's interesting thinking about code and color specifically because, like I know when I first learned like what you could do with, like a CSS like pre processor with color, you could actually like, apply like multiplication to like a color, you know. And then they watch it like spit out these these color palettes. But the thing is, even though sometimes it's, you know, it's mathematically correct. A designer may still look at that color palette that came out.

It's like, You know what, right? I want to tweak that just a little bit. I want to put Green in there. I know it doesn't work with the mouth, but I just see, I just see green. And the reason I wanted to talk about this is because I think that my action actually be like, sort of fundamental to someone like the disconnect designers and developers have. Sometimes, is that, um, you know, it's the aesthetic world. Sometimes you can't I mean,

it is like we should find every way that we can agree on, you know the science of it, you know, so that we can get a good process down and everyone could be, you know, efficient and that sort of thing. But sometimes it doesn't apply scientifically. It's is it pure like aesthetic choice? It just feels weird. Agree. We talked about

how if you have a palate, let's say and it's a, um, a tertiary color relationship, Um, that something might work. But if you wrote it around the color wheel, the same exact relationship same distances around the color wheel. But if you rotate it, it might not work, especially as computers could be funky about representing certain parts of spectrum like some, uh, slightly darker yellows. It gets really muddy, you know, all of a sudden something that worked on, you know,

secondaries doesn't work in primaries. Um, and so we we definitely take it all with the grain assault and in educating the developers. It was sort of like a glimpse into our world. And this is a great way that we often you wonder, Why did we choose that fund? Why do we choose that color? Well, colors have relationships. This is sort of the overarching system for how it works. This is often a starting point for us, but then we go out a little bit on feel that it was sort of getting them on the same page about that. Just as we explain grid systems, you know?

Yeah, we only

may use this particular grid for this, and it has certain it's a structure, but maybe we're actually going to go for an asymmetric rigging the end. But this informed our process on more often than not, that's exactly what the development stuff is doing for us. I'm not gonna be the one to sit down and work with sass. I'm not gonna be the one to build a database. But I speak the language more, and I'm gonna be better informed about the reasons that developers are making decisions they're making.

I think another thing that is important is understanding how important technology or technologist is to the conceptual design process, especially since a lot of the modern things that we're building our just pixels their weight and it moves the whole personnel product, right? Is it a card metaphor? What speed is that? Animated? How does the user feel? And a lot like, I think, designers learned to listen to developers a little bit because sometimes a strong perspective of how the this product is going to be designed, a creative can come from from those tidbits of information. But I guess, more importantly, like having a collective vision about what both parties were wanting to build. That way, developers don't feel like they're just getting things lobbed over defense. But they're actually part of the process,

part of the decision making process. And, you know, even in design groups, I mean, you guys know how it is, like everything is completely subjective. You know what Rick might like may look different to me versus different to everyone else in our studio, And I kind of sort of tend to be on in the camp of Let's get together, sort of quickly figure out what we collectively wantto do. Don't spend a whole Don't, you know, spend a lot of wheels, get it out there to the user and then let the user tell us what they think is beautiful and then, you know, make tweaks that are a subjective

I think also to your point about understand those tools and use them to spur, you know, the creative thinking. I think that justice designers will throw things back and forth to try and find the right aesthetic toe bounce ideas off each other. It works with developers and designers as well. Where, you know, as you said, because the design isn't just this static thing in a photo shop, it's this living, breathing, animated behavioral thing. I hate when people called static thing breathing and breathing really burns

that you're not at the amortization of the Web. I did this presentation at Mobile Camp. You guys might be interested in there. The whole thing is about change. But there is an interesting part in there, right? I kind of It's not like I forgot, but I really remember what it was like to be a Web designer in the in the nineties where you know, you didn't get the Web and these products weren't mature enough for there to be different disciplines. You know, in order to design for the Web, you had to be a great you had to know about the graphic artist rules. You had to know, you know, HTML. Remember D html and you had down menus. You had to know things like onion skinning and key frame animations and job script and all kinds of stuff.

If you wanted to build anything and you know and and I sort of realized that there's a relationship there for the way things were going. Now, as the interfaces are becoming less sort of static and more leaning on animations and transitions and things like that, I mean, it's kind of I think it's important for designers to re acquaint themselves with all those other things that they're important sound audio animation, technique, technology. I mean, it's not, but, you know, because Photoshopped you know, deliverables, which I personally used to be the delivery ble. It really isn't the product. It's just until it's in code. It's just an idea of what you want the product look

like. Exactly. It's an artifact. It's a sketch. Um, I think as designers, we need to go back to school and understand what can be done. We need to lean on new tools and explore and built, explore and find and build new tools that are better doing these things. Look at what Facebook's been doing with origami and trying to repurpose courts composer to turn into ah design tool, and I think It's also worth the throw stuff back and forth developers, because the parts where I'm missing in my vocabulary Tim has and all the say, I really want to do this kind of thing. And it would do this little bounce. Or there's a video playing in the background and Tim says, Oh, hey,

if you want to do that, you could actually do it this way which we use less Resource is, but it's this new cool thing we can do. And there's some bit of technology development that I'm completely not aware of. And so if we can talk in the outside of development outside design, the really high level in motion that we want to get across, we can then rely on each other's expertise to find out exactly what nuts and bolts we need to make that happen.

What kind of tools do you guys use between development and design disciplines to capture speeds of transitions and types of animations and stuff like that?

Uh, html javascript, C s s.

So that's that's used as like a temporary deliverable to explain the vision of the

animation. Yeah, well, if we're if we need to communicate it to a client. We could do it in a prototype.

Oh, I guess it might be easier with Web that's dead

internally. I've used because I'm not savvy enough to put something together in HTML CSS. JavaScript yet. And I don't yet know the origami and court composer stuff, which I wanna learn all throw things into keynote. You know something? I'm just aping this tool to do something different. I did that with a prototype for a mapping system where we knew we wanted it to zoom in and rotate and reposition the map at this point. And we were trying explain to one of our developers here I'm like, You know, I could do this in a keynote transition in 50 in 10 minutes and so I

through That's awesome. Yeah, and that was the way and

that. I certainly wanted more tools, but that that was effective.

I know that there's a couple of tools out there. In fact, I saw that Facebook launched 11 of our clients partners Tim, over a vast dot com released this tool kit called Tuned Kitt, and you can find it on Get hub and what it is. It's a panel that you can install into any native mobile application will IOS application and allows the designer and developer to have different installs of this app that tweak the animation styles, the squash, the the curves and all that kind of stuff. And so you could just quickly get your assets into the app and actually sit down together and tweak the knobs and get the animations. Exactly one. And they just pushes and pushes a lot

one of the river just a specific example of the the relationship between the designer and developer. Here we do a lot of responsive sites, and probably a year ago at this point we were designing a responsive navigation system. We had myself and our art director, Neil Corporate. We're working on this and we're both sitting in the same room, sketching out the large screen experience for the for the navigation. And we looked at it and he said, Okay, what can we do to get this to the small screen? And then we sketch something really quick and we said, OK, well, that's ugly. So what else can we d'oh! And then, you know,

Neil would say, Well, can we do this on the small screen that I would say, Well, we can do that on the small screen if we do this on the large screen and then we go back and forth until we had, you know, point a of large screen and point dizzy of the small screen. And we both knew that it would be something that that as a developer, I can execute. It meets the user's needs. And it's something that Neil Cone is happy with designing.

You know, that's cool, because that's another part of, like the evolved, you know, the evolution of the relationship between designers and developers. That I think would be waving official to both sides is if you could get together like physically, in the same, like geography, like you can't that would have been. Probably it would have taken away longer and been a lot more challenging to do if you weren't sitting in, you know, with the white board or whatever. How, however it is. Yeah, that's,

uh, that's really interesting to me. I mean, the three of you guys probably have a lot more modern Web design skills that I do because I started. I moved into native mobile. Around the time that responsive was getting big. We started this company for the first year. We were only doing mobile. But over the last six months, we've been doing more responsive web and the design, the quality, the design work was great. And, you know, But we get, you know,

since we don't do development are our clients keep asking us. Okay, well, we need you to make sure you keep up with a style guy, right? But, you know, since it's not ever finished, we're updating the style guide constantly, which could take 10 or 20% of the velocity of effort. And I starting Thio have this feeling now like maybe that's not the smartest use of our time capturing. Yeah, it's not bad when you could be sitting next to the developers more than we need. Maybe we do need to learn it would be so much different if it was just web, because that could very simply be recorded in like an HTML CSS like running document. You know what I mean?

Like, we can actually, instead of telling them that we want, you know Hey, can you make the border radius on this element like six pixels. We actually right. The CSS with that in there on that could be handled that way. We haven't quite got there yet, but the thing that is hard is that something like that doesn't really exist for Native Mobile. I know that's a little bit more something specifically that we do. But, man, we're just There's a missing links somewhere. Well,

funny you should bring up style. Guides were actually just recently made coded style guide to standard delivery ble, and we developed a framework around it. We're gonna be open sourcing it pretty soon. It's called corkscrew.

I just weigh like check that out

in the open. Sourced relatively soon. We're waiting for a project to wrap up.

Make sure I understand this. It's it's a similar format, but the bits are our html to

Yeah, yeah, yeah. You're laying out what are our type styles? Here they are on your putting an h. C'mon, you're putting the CSS. What are our color styles when there are what's our grid typography everything. It it build itself off of a config file and then you can put in the individual components you have tabs for a point. You can stick the tabs in one of modules and you have according to stick it somewhere. It's been it's been good for us so

far. I can't wait to check that out. That's that's something that has really been on my mind lately because I've been watching the teams. I spent a lot of time just tweaking way have. After working on right now, the style got his 42 pages long. It's gonna change every two weeks. Yeah, and yeah. And sometimes you change existing elements that have already been in the style guide. Right? And you're like, Well, we we decided that the header should change, you know, for the next release, and then you sometimes forget that that,

you know, because it's already in the style guide. You have to go back and change of speed. And it's the minute the developers expect parody of style guide and screens, and you also have to keep all the screens Updated. Design

tools are catching up a little bit, maybe sort of, but not really like if you look at photo shop about two months ago, so they had an update Photo shop CC that out of the ability to instead of having smart object being linked to living only within document, having internal

linked B s tease. Oh, my God, that's changed. Bricks. Bricks. Yeah, it's been great. And

textiles and stuff. Info shop, too. Although that is specific to the document. You can't link those outside, so

they're partway there, but not all the way. Yeah, it's weird. They're like, catching up to what, uh, adobe in design has been doing for years. So just like, you know, a print more for prints

as Photoshopped continues to grow. Is this great giant Frank and beast? Yeah. Tries to do everything.

Yeah. I have a question for you about this similar stuff in the native mobile roll. So, you know, I will experience working front and developers or design technologists or whatever you call it. And we thought for awhile surely there had to be a similar position for doing native stuff. And so we started talking to our clients like, hey would be beneficial if we started learned ex coat. Could we drop our assets in here and help you instead of delivering Photoshopped files? Could we just deliver X code stuff and the answer we got was like either. No, I don't want you touching my freaking code or be no, I don't think it's worth your time learning because by the time you learnt it, there's gonna be better tools. Yeah or C it's You can't really do that, but there is a next you're rebuilding. The response that I've pulled out of a couple of violence developers is that by the time you are doing what you want to do,

you are developing an IOS like you are doing. And probably somewhere along the line I learned Objective C. What happened? Yeah, changed? Exactly. I

Some tools. Ah, there's one that is completely escaping me that specifically for straddling the design. Thio. There's phone gap. Which one? Yeah, Phone gallery. There's there's something that specifically for building assets and remember it is, But there's a new app call paint pink up pink. Oh, there we go.

Yeah, they just released a new update away a couple days ago, and I haven't downloaded and use it yet, But that's really interesting, because that one of this one of these clients, developers and interviewed I asked him like, How can we be a better partner. And when when I was talking about like should we learned code and stuff? He said, You know, you should learn maybe at least paint could because honest to God, I only use about 5% of your assets and all the other assets are redraw myself

there. But when they're built dynamically well, the you know when we're handing code off to a back end team If we wrote some back in court, they're gonna blow it away, of course. But we're using our code. Maura's a communication tool, then production stuff in that case, sometimes its production code. But, ah, lot of times it's just as communication.

Yeah, I guess that's what's hard Thio get over because we I mean, one thing that we don't we've done like paint code is cool. And that house of assets and like this super useful to the developer, Um, but what we would really like to get into is being able to collaborate with development on really interesting interactions and things that occur over, like through motion. And so the only way we've been able Thio address that thus far is been. Neil is a guy that works with this. He's a product designer as well, and he has some experience with motion graphics. So we get our PS tees given to him. He opens them up in after effects and we go over animations and get him right just exactly what you like. But the missing piece still there is that that is very good visual representation for the developers, but it's it's not actually used, right. Take the code and implemented.

So you have to look at like what is the best use of time? Because you can do it really quickly and imperfectly and aftereffects and then collaborate with engineer on the execution. Or you can spend six months letting ports composer and spend four times as long doing animation and still have it be thrown away by the court's gonna like. I don't I don't know, like when I wasn't ever know, try to learn court composer. But the learning curve was so steeped in my mind. Yeah, I don't feel I don't I'm not sure whether it's were my personal time. I don't know about it, something that started

for building screen savers, you know, in In Mac OS 10.4 point five seriously flying toasters. Well, not for flying. It was off. Uh, core

remission. That's up. Does pipe dream one? That's awesome. I didn't know that started out as

a gooey for, um, some of the underlying graphical layers to Mac OS around 2005 or so 2006. And that was what it was built for. And then all these tools are sort of saying, Hey, wait. This is actually stronger reasons, other ways. But you're still sort of, you know, squeezing, manhandling this tool to do something else doesn't want to do. I know ideo just really something called avocado.

Yeah, yeah, yeah. I mean, you it seems like the stuff that we're concerned with right now are your also concerned with. And it seems like a lot of other agencies and groups of people are having the same conversation right now. And, you know, obviously there's a lot that, you know, like some you know, there's something missing, you know, there. But we should we'll work together to figure this stuff out because I think at the end, our clients expect us to figure it out, you know? Well, yeah, and it's

the same notion that when people saw the iPhone. All of a sudden, it's like, Well, crap, the baseline has changed, you know? Yeah, the absolute bury. The bare minimum for injury is it must be gorgeous, like that. Sort of, you know, a crazy expectation. But that's what it is. And now it's It must be gorgeous, and it must behave in balance and be fluid.

And we also have to go back to school a little bit, um, and learn. I'll learn how to fill this gap. And I think that's why we're seeing this explosion of tools everyone's trying to say, Oh, God, there's all the stuff you have to do. Here is a way of doing it easily. And I have yet to see one Holy Grail. But I'm holding out for it.

Yeah, it's a good way of putting it.

Well, we're We're sure you guys are. You're in Texas. You imagine you're gonna go ride horses or something? I don't

weigh. Gotta go read this. Horses. They're coming. I will say the time in the Texas

twice Austin wants. And the only thing that I noticed that what was bigger in Texas was the water glasses. They're like

like a small enormous. A small coke is like 44 ounces Starbucks. Starbucks here has, like, an extra size, like a trim Tae like. Yeah, they have, like, a larger size than other local leader of uh, So are you guys gonna be a couple of guys are gonna be in Austin in June. Do you know? Do you know

who else coming? I'm not sure who's coming down. I am completely uninformed regarding that situation.

I don't think there will be that that they're gonna tell Mark going pretty pictures.

And then sometimes, you know, I do some work.

Well, let's get together sometime outside podcasting world. And, you know, keep this conversation going. Some Really interested? Yes,

Absolutely. For the dirt listeners. How can people get a hold of you all?

Um, on Twitter at fun size, you could find pretty much any any way that you want to connect with this from there were, like, that team thing on dribble. So that's good as well. No. Uh, yeah. Just fun sized taco or on Twitter. All right. And for the fun size listeners that want to look you guys up, how will we find you? Yeah, right back at

you could get us at the dirt show on Twitter. I am CSS karma on Twitter. And Mark is Mark Grambo? Yep. On Twitter. I'm not gonna spell that out. I'm just gonna let people type it five times until they find me my smiling face on. You confined us, Of course. That fresh tilled soil dot com. Cool.

Awesome. Man, this has been great. I am so sorry we have to end this episode because we could talk. We've been talking about this very subject for such a long time. It's great to have you guys, uh, you know, here, here, that you guys have similar thoughts. Agreed.

We're not all stewing and suffering. We're all still suffering together for a party wearing together. We had a good time on your podcast. I hope you had a good time on ours.

I will say toast to that question.