This week, Devin is away on a Product Design Sprint, so John invites Dani Sandoval for an informal interview.

Dani has a background in digital product design and development and is currently a Senior Product Designer at Chipper Cash.

They discuss communication on product teams, Svelte, and contributing to open-source.

Chipper Cash: https://chippercash.com/
The Svelte Newsletter: https://svelte.substack.com

Transcript
----------
John: [00:00:00] Hello welcome. I'm here with my good friend, Danny Devin is currently in a product design sprint this week. So I thought it would be a good opportunity to catch up with you. Grab a beer, kick our feet up, celly some words over the internet, and try to find some interesting things to talk about. But maybe I'll turn it over to you to say hello and give it a little quick intro of your background.
So people get a gauge of where, who you are and where you're coming from.

Dani: [00:00:28] Yeah. How did John? So my name is Danny Sandoval. I am a product designer at chipper cash. Basically we are bringing financial services to. Africa and the African diaspora across the world. Yeah, it's been a long journey getting here. John you and I met, in, in Boston and I do miss being in the same time zone as you, so we could actually have beers and it wasn't weird the drinking at 2:00 PM.
But certainly I have been living in Los Angeles for eight months now. And before I moved to Boston, I was in Seattle, which is where I started my career. And design and where I went to school. So give a brief overview of what I've been doing. I started out as a front end engineer at a company called discus IO.

We made market research software, so B2B focused on video conferencing, bringing participants into a meeting room where they could talk about packaged goods, mostly. That was a super interesting space. I learned a lot about, customer interviews. I learned a lot about working with Marlene large companies with really big budgets and trying to get through the procurement process trying to build enterprise software when you are, five people is actually really hard and I scaled.

With that company up to 50 people and got to build a product design practice inside of a growing product team. So that led me to consulting where I moved to Boston, basically not for that job, but I happened to get it while I was there. And really applying a lot of the good practices that I had in a startup to these larger companies that needed to move fast.

So they were looking to us at pivotal labs where I worked on how they could ship things quickly. And that the big thing I brought from that I learned from that experience was being a designer in a balanced team. So rather than just. Working with engineers on a day-to-day basis and kind of treating us like we're going to changeable one in the same.

It felt like it was nice to clearly have sent delineations in roles where the product managers responsible for the business needs. The designer is responsible for the user needs and the developers responsible for the maintainability and overall sustainability of the code base. And. And these strong opinions loosely held is what made consulting super fun.

And what led me to where I am now at chipper cash which basically I was like, all these really good product practices. I don't get to see. Over time. It just ends, Oh, our contract ends and I don't get to see the product, after six months. So I felt like it'd be really cool if I could build a team that had good practices and then just kept having good practices for the rest of time.

So that's where I am now is building that team. I'm hiring some designers and, helping our CTO, develop good relationships between engineers and designers and of course dipping into open source as well. But whenever I have free time, so that's a general intro, anything that you're interested in, we'd love to dive in.

John: [00:03:21] Yeah, I think I'm, I think I'm interested in all of that, Danny. That is all very interesting. I think one thing that really jumped out to me is at your time during a consultants you mentioned getting a little bit more clear delineation between developers and designers and product people.

Like how do you. Maintain that separation of concerns without, communication suffering. Cause one problem that I've seen in a lot of product teams is when there's too much separation between those roles. And you just have a bunch of designers sitting over at one corner of the lunch room.

You have a bunch of developers sitting over at the other corner of the lunch room and they're working independently. And then there's this awkward handoff and productivity really drops. So I dunno if that inspires an interesting sort of thought, like how do you overcome those challenges or how did you overcome those challenges and how do you as a person who is currently building a team, think about communication between those roles and how to best I know, set the team up for success.

Dani: [00:04:22] It's a really good question. I think a lot of the bigger companies that I've worked with. Felt that pain, right? With just these huge design silos that I feel you actually be overdesigning in those situations which is weird to say as someone who wants to have a job in the future. But certainly at the smaller company, I never felt that at a startup, it was always designed was behind there just wasn't enough time to really do the due diligence.

And I think. There is a need for , a craving for as companies grow, designed to have that space to do good work. And I think engineers feel that too. There are plenty of times where it feels like the product has pedal to the metal. And it's just if we could just spend some time refactoring and Making sure that everything is consistent.

Our lives will be so much easier. Everything will be more maintainable. And the reality is you never get that time. And so I think whenever opportunities have come up for a design leader to say, Ooh, let's do a design sprint, or, Ooh, let's like spend six months on this. They take those opportunities because they're so rare.

And so I think one of the ways to solve that problem is to bake those opportunities into your team's processes. So rather than tech deck continuing to build up, or in my case design step, continue to build up over time. And then those rare cases come up where someone gets to go off and do a redesign, for fun for six months.

And it's totally okay. And no worries, this isn't going to block anyone. They're going to, instead of having that be like such a rare thing, that it never happens. Kind of spending time to balance those things and say, Hey, let's say once a month, we're going to do a bug bash or we're going to do this design dev pairing, where we get to clean things up.

And so those tiny little pieces that always add up to something big that requires siloing never end up adding up because they get taken off one at a time. And so I think that is helpful. And at the same time, I'm going to say something super controversial. Designers learning how to code has helped a lot for me personally, as there are times when I want to feel the pain, a little bit of what I'm, designing.

And if that means going in and trying what I think will work. And finding that it doesn't in the code because the API design is not going to work in that way or wherever it ends up happening. It helps to feel that pain every once in a while. So I don't feel like my developers are pushing back for no reason, but instead I felt it a couple of times and I built that empathy.

So I think there's really two sides. One is more strategic. How do you build practices that enable. All disciplines to have a balanced approach to product development. And then there's the more, tactical of ha how do I make sure that I'm not losing touch with my coworkers, the people that I'm interacting with on a daily basis.

And that's just, I think, more, a personal need than anything else.

John: [00:07:04] Yeah, it makes a lot of sense. It goes both ways though. I think as a developer learning more. Yeah. Design makes you a better developer. And you're able to collaborate more and get in front of poor design decisions that make products crappy to use. And you can be a better advocate for a better quality in that regard, if you spend a little bit of time, caring about it and trying to get a little bit better at it.
So

Dani: [00:07:30] I think a lot of the times developers don't feel enabled that they can push back. One of the things I was doing when I hired a discus IO is during my interview as a designer, I would ask to the developers that we were hiring. What do you do when you get handed a design decision that you feel like is a bad user experience?

And the people we hired are the ones that said, I go talk to the designer and ask why. And I think if we don't have a clear view back, if there isn't an acceptance that anything and everything that I, hand to a developer to build has the potential of having a long conversation to describe, to explain it.

Then I don't think we can actually have a balanced team. I don't think that we can respect one another's discipline if we can't understand and accept feedback on what we think is true. And I think that's another thing that goes both ways. There are plenty of times where I questioned an API design, where developers working on something and I go, why don't we return all of that one response? I feel like it'd be like actually much quicker if we all. If we took all that data and returned it all in one, one response, instead of splitting it up into multiple things. And I think even if I'm wrong, which I usually am having that conversation helps me learn more about the constraints of the system, which means that then I can go and design something around those constraints that I now know about.

And I think even if you don't have a good eye for design, you can still ask questions as a developer of like, why are we building it this way? This feels bad. As designer probably has a really good reason. And by explaining that reason out loud, you're going to learn something about user experience design or UI design or whatever.

You got a question on. And at the end of the day, a little, learn a little bit more about your colleague's job, which I think is never a bad thing.

John: [00:09:09] Maybe you'll even build a slightly better product.

Dani: [00:09:13] Hey, you said the name of that. They said the name of the podcast, trying to build good things.

John: [00:09:18] Yes. It's all about trying to build good things. Yeah. Yeah. That's interesting. I definitely, I think there's a lot on this thread that we can pull on. But I do want to get to some of, what you've been up to in your personal time. I think side projects that my friends are up to are super interesting and I don't know very much about. Any of your open source work that you're working on, you want to give a quick rundown of what you're up to. What's what's exciting problems you're trying to solve.

Dani: [00:09:47] Yeah, most definitely. I think I tend to reach for side projects that scratch the edge. I don't get to scratch on a day-to-day basis. So I rarely want to do user research or product market fit analysis, or actual UX design in my side projects because I do all of those every single day.

So I always try to find interesting problems that don't touch any of those things. Which tends to fall into a couple of camps. One is video games. I've been working on a video game partially in the open and partially privately as in some of the code is up in source, but not all of it. And that's been a lot of fun working in JavaScript in the browser, trying to make a fun experience focused on controls that actually feel tactile when, you're trying to make something for a mouse and keyboard.

So that's been something that's been fun. And I think only requires me as a user for the feedback loop. So I don't have to really pull on any of the I would say parts of my brain that I normally use at work, which has been a lot of fun. Plus video games are just a bunch of nested if and wild loops, which I can write, I can do that kind of code.

That makes it easy. And then other than video games, I've also been blogging a little bit for a spell JS which is a technology that I use on my own blog which is also open source as well as just really any side project that's on the web nowadays I pick up spell cause it's so easy.
It's basically just handlebars. JS, and then CSS and script tags, all in one file. And that like I don't know what you call it. Ergonomics of, organizing everything. I can think about a single component into one. Very easy to read file that just looks like regular standard JavaScript and HTML and CSS.

Something just clicks there in my brain. Even though I've written react and stuff. So I wanted to give back to that community. And when I saw that there was a gap in their documentation specifically in their release notes, they were very technical. They got into a lot of detail and people were always asking like, what's new and spelled.

And so I wrote an unofficial newsletter at first, that was just me summarizing the release notes and in ways that was actually digestible and easy to understand. And by the second or third newsletter I realized that people were reading it and that it might be good to put that on the official blog.

So since October, maybe. It's now the official spelled newsletter. And now it's just a matter of figuring out what email platform that the community is okay with for us to transition everything over. So that's been a lot of fun too, just dealing with open source maintainers who are always amazing.

And really just giving back to the community that has already given me so much in terms of just spinning up side projects. So those are the kind of, main things I've been working on recently in source.

John: [00:12:38] Super interesting stuff. I got two threads of interest to go down one. I'd love it. If you get a little bit more. Technical about what spelt is, how it does, how it be. And like more importantly, like when and why someone might want to use it. Is it like the naive question would be like, is this the new react or is there like a different.

A set of problems that's trying to solve then react does. And then to, like how do you balance open-source contributions? And like, how did you find the newsletter? And what are some good strategies for people in a similar sort of position? I was like, Oh, I want to give back to the community.

Like, how did you go from that to, Oh, I'm going to start this newsletter. So maybe we can do the first one first if you're down. And then the second one second, if you're down.

Dani: [00:13:27] perfect. I think starting with number one. The reason I use felt is because I am a web programmer or a web designer, I guess you could say and not really a software developer. So that means that a lot of the things that maybe come naturally to someone who understands computer science, who's taken more than two computer science classes.

Don't really come naturally to me pretty much the basic functions of a language, like if statements and, wild loops, like I said those kinds of things make sense to me I've gotten enough, confidence in using them that I can make something look the way I want it to look.
And then things like CSS, I've just gotten good at because I, want something to look good. And I've read enough documentation that I know how CSS works, which I think is its own super power and it's separate from smelled. But it's certainly something that having knowledge of helps me a lot in spelled.

I think, I would choose felt over pretty much any language at this point for a website. If there is just a website that I'm working on, which in my case, I have my own personal blog. The majority of that blog is written with Hugo just to generate the pages and, read Mark down, spin it out into HTML, but the actual styling of stuff is done with just.

Like bear CSS actually it's SCSS, but whatever. And the actual pages that are interesting, my, my portfolio page that shows talking with my hands here, but images across the screen that that's all done in spelled because it's a reactive layout, it looks pretty and it's more interactive.
And so any of those Hey, I have a static webpage, but I want to spice it up with some JavaScript. Doing that and native JavaScript land is really hard, right? It's a lot of boilerplate, lots of document dot query selectors, and I'm throwing some spelt in, it allows for us last for me to just think the same way I thought about static markup.

And all heck I said before, having it all self-contained and singular components gives me just enough of that react like ergonomics without having to be full-blown. Oh, what's a lifecycle method. And, should I do should I have to unmask this component or does it just say use effect hook that I need to have, like all that stuff doesn't make sense to me.

I don't know what use memo is and I don't think I ever will understand use memo. But certainly it's important, especially when you're like trying to attach Dom events to notes and spell just has these nice, like cooks in, you can write in your HTML that abstract away a lot of the stuff that you would need to care about.

If you're trying to have the most performant, beautiful thing, and you still get the most performance beautiful thing. So that's really nice. It's very fast.

John: [00:16:05] So you're still writing components and thinking about. The parts of your website in that way, just like you would in react. But instead of having this virtual Dom kind of floating in the background with all this complexity kind of abstracting most of the time, but sometimes leaky abstractions come out and you have these complex concepts, you need to grok to be productive.

It's felt just doesn't do that. It's if correct me if I'm wrong, but I'm pretty sure it's based off of observables or something like that too.

Dani: [00:16:33] Yeah. So basically it's a compiled language. So it's not shipping with any runtime or there is, it's a very small runtime. And so the majority of the reactivity is just done in the component itself. So it just ships up as like JavaScript bundle whose only job it is to do what you said it was going to do in the script tag.

And so it's very similar to the old jQuery days, where you're pulling things out of the Dom and putting it back in. But you don't have to write it in a procedural way. You can use like listeners and things like that. And so it's you get the best of both worlds. You get the it works, like I expect of jQuery, but you get the It does.

I don't have to write 800 lines of code to make it work in every single condition. You can be a little bit smarter and run it as if you were ready to react components. That's the point of the compiler. It takes all of your like declarative code in it. Translates it into a procedural code.
And you don't see any of that as a developer. You basically see just a script tag at the top. I see as a style tag in the middle and then your HTML at the bottom. And that's super helpful to just have that visual always be there. For yourself and then the compiler doing all the work for you.

I'm sure people who actually write stuff. So code and know more about it on the development side have a way or developer friendly explanations of it. But as a designer, that's the way I approach it.

John: [00:17:55] No, that's super, super helpful. Like I haven't had an opportunity to use it yet, but I've had my eye on it. And the building habits app is probably going to need a product marketing page at some point. So maybe spelt will be what will be what we reach for when we get to that.

Dani: [00:18:09] Totally. I highly recommend it. And I think there is this idea. It's like spelt for some sites, react for apps or whatever. And I would say it's probably true. There is felt kit, which is coming out. It's a framework on top of the framework, the meta framework kind of style similar to like next JS or next.

And that's spelled the answer to that. So when spelt kit comes out, I think will be a better app, like solution for spelt situations. But even then I've written some nice fun apps. Like I made like a. Treasurer generator for my D and D group which just reads a bunch of JavaScript objects and does some dice rolls and it will generate like a treasurer as if you kill the monster.

And that I wrote the whole thing is spelled including the UI later. And that's very app, as an experience. And certainly as it gets more complex though, I think you'd probably have to lean on something like spelled kids or to subject out into react.

John: [00:19:01] Cool. Does it tie into API APIs and stuff? A word like you left to your own devices

Dani: [00:19:07] Yeah. It's fetch all the way down here, you're using just whatever's built into the browser, but since it's just JavaScript, right? Like it's felt before spelled kids had, doesn't have an answer to, for instance, like how you do routing. There wasn't a spout router really. Because they didn't need one.

You could use any JavaScript rounder. And so it has that weird. Like again, jQuery, like vibe where you're just like, ah, just import it and try it, see if it works, which can be a little scary for people looking for a blessed path.

John: [00:19:37] Yeah, that's a, that's an interesting phrase. I like that a lot. The blessed path was not to tangent a little bit too. Not the tangent too much, but to take a big tangent was chatting the other day with a colleague. About state management and react apps. I'm curious your thoughts on this one.

And there's a lot of strong opinions. I would say, strongly held about this in the react community. There's people who are really into redox there's people who are less than to Redux. There's other tools out there like mob X and every, so often someone will come along and be like, how do I do state management and react?

And it's always just like a. Conversation and I get a little bit annoyed with the, just use Redux. Cause I've had some bad experiences with projects that have gotten unruly with Redux, but and so my answer has been, it's if you don't need something as complicated as the flux pattern and like, all you're doing is setting some state somewhere to I don't know, you're fetching some data, you're putting it somewhere and then you're reading it on a different screen or something when you need to.

Redux just doesn't make any sense to me at all there as a tool, but then my answer is it's like use, just use the context API until it's, until you problem is too complicated and then introduce redox, but that's not very helpful for someone who's asked. The question is like, Hey, what state management library should I use?

And it's more of go figure it out yourself, but start simple as it's not the best of answers. So getting on a bit of a ramble here, but I like the term, like what is the quote unquote blessed path for solving solving a problem. But, yeah.

So I guess my question on that thread is, do you have any opinions about Redux or actually, no, I take that back.

Dani: [00:21:22] Kara, Danny, I would like for you to come into this flame war with me and here's a flame thrower. I have a opinion as a non-developer, which I think is nice. And I think certainly my opinion as a non-developer is, does it integrate with the tools.

Can I see it from the dev console, that's the kind of stuff that matters to me. Who's not writing the code because if I can't go in and rejigger a, like a variable, so it's in the exact right state. So I can test something as a designer. Then I'm going to rely on you as a developer to make us very specific bill.

That's got the exact, like state that I need this thing to be in, or I got to walk through some really complicated manual tests set up. And I think the nice thing about Redux and mob bags, especially in react native is all this tooling has been built around it, that you can just be like blop here's my user, response that you can just inject into the observable and a, like I'm now in this weird state which is what I need to see of the designer.

And I'm gonna screenshot this and go and design the next thing, like that's super nice for me as a person who's not in the code all the time. To be able to rely on my team to have and so yeah, whether it's my backs or, the react context API or Redux, all of those have tooling, I think, built around them.

And they feel nice to, to me as a non-developer. And then of course the more abstract to get the more like complicated your solutions. I think I agree with you, you better have a good reason for those, state trees are a perfect example of that. That like X state is an example of a library that people really like.

And I think if you have a problem that needs, a state tree, then you should solve it with a state tree. You're not trying to solve it with context API or whatever. Just because it's the simplest solution. I think it's important to have a solution that meets the needs of the problem.

And a lot of the time, the biggest problem is just team collaboration. And so if your tool, your solution helps with that, include it in your problem, even if it's not a code problem. I would say that that's my, my perspective on this particular part of the framework is I don't care what tool you're using, but it's really cool.

If the tool that you're using is a tool that I can also use as a person who's not in the code.

John: [00:23:35] Yeah, it's a hundred percent, it's this super important part of the puzzle, being able to make it maintainable, but yeah, so it sounds like we're. In alignment and it sounds like it's just an unfortunate truth. That state management is hard and there is no one size fits all. Just follow these steps. That's unfortunately hasn't been automated for us yet, no bless Plath. When it comes to JavaScript state management, unfortunately you just have to pick something and see if it works for you or not. And then eventually you'll do a couple of projects and you'll get super jaded and you'll be like me, and you'll just dislike the thing that you know the best, and always be looking for the next thing.
Which I guess for me right now is my backs, but until then using the context API until that's painful. And then introducing Redux is my go-to, but we did promise to chat a little bit about your open source contributions. I was, I would definitely want to make sure we have time to chat about that.

I was super interested. How did you decide, Hey, I want to give back to the community and then once you decided that, how did you. Figure out that this newsletter was your thing. And also please share the newsletter link so we can put it in the show notes and people can find it.

Dani: [00:24:46] Yeah, I think the real big thing is this isn't my first rodeo in open-source contribution. The first time I wanted to, give back to the community was actually prompted by me wanting to get into healthcare systems as a job. And so I figured working in open source on a electronic medical records.

Platform will be a great way to do that because I would learn a lot of the ideas and, help solve problems. And I saw basically in opening in open EMR for people who needed basically like there's lots of requests in the community. This particular open source platform written in PHP.
That was like, Hey, we have the current medical record system that is all open-sourced here. And we need a new way of managing hospitals. Cause this is mostly managing like individual patient records. And managing hospitals really complicated to kinda manage beds. You got to know how many people are in each bed.

And so it just felt that the developers who were working on it were overwhelmed. There were all these different problems. They, they didn't have a concrete problem statement. And it was really hard to distill that into code at that point. So that's a design problem, and I got really excited about it.

Seen it. I got pulled into it basically through a hacker news post. And from there, it was just a matter of time before I was like just talking through how we might solve it and sketching things out. And at that point it was easy to hand it over to some devs to start prototyping. And so that, that felt good.

And from there I spent a little bit more time, like redoing their that projects CSS build. Process. I moved it over to something that was easier to maintain. And at which point I I dropped off cause I got burnt out and I realized, after about a year of not contributing and getting a couple of responses from the community Hey, where'd you go?

Like we miss you. You were doing great that consistency and sustain sustainable pace is a lot more important. Then, like a big bang contribution, which is what, rewriting an entire CSS build process was. Now at that point I had lost a bunch of context and momentum on that project that when I wanted to get back into contributing to open source, that wasn't my first one to reach for.

Like I said I ended up wanting to contribute to spell because I was using it all the time so much so that I was in the discord. Just watching people's questions and getting excited about the answers and just trying to learn through osmosis in the community. And I think in that Dysport is where I saw the need for a For a newsletter.

It was mentioned on their podcasts that they had about Hey, no, one's writing release notes that readable, we need to have the release notes, but there's gotta be something else, like a newsletter or something that someone can do. And I wasn't the only one who heard that podcast. I think two other people also start a newsletter like that exact week.

But it just felt like there was a call, a need to do it. And a bunch of people who were like, yeah, I can do that. Started writing newsletters. And I think mine just happened to be the one. That caught the right tone. And I think was at the right frequency. It was once a month as opposed to like once a week or once every other week.

And that it interested at the maintainers enough that they mentioned it. And I think that was where there was a cycle of, I was paying attention. The maintainers asked for something that was a need that I could provide since it was monthly thing. And that was just a decision I made, it felt maintainable.

It felt like I was able to maintain it consistently. And I now have a reminder in my phone, the few days before the end of the month to go back and read the change log and write a newsletter. I think it's been really nice to see it grow. And to, Every month, we get a couple more subscribers.

And it just feels like I'm actually helping. And I think that's something that I guess public service announcement, you don't have to write code to contribute to open source. In fact all the examples I just gave besides the CSS rebuilt were all things that you can do without coding.
It's just paying attention. And looking for ways that your unique set of skills can help. So that, that felt like it's a nice thing to. To reflect on, and really point out in this particular moment.

John: [00:28:42] That's awesome. That sounds very fulfilling to you. Do you finish newsletter? And feel something

Dani: [00:28:50] Yeah. Probably the best thing is I get a little green square, my get hub

John: [00:28:55] it's all for that. That's all for those green squares. Yeah.

Dani: [00:28:58] But no, in all seriousness. Yeah. I think now that it's more of a collaborative effort, it used to just mean, be me. Writing the whole thing and hitting publish at the end of the month, but now it's a PR into the blog. So I actually ended up getting a lot of feedback pre-post from actual maintainers people being like, Hey, you probably shouldn't mention that.

Like it's not ready. Or people being like, Oh, this is super cool to have you like, actually there's a completely parallel project that is working off of spelled that like you should mention here. So they get the good news and Just stuff that I wouldn't have noticed if I was working on my own, that people who are, they're in the community more often than me are noticing as well.

So that is even more fulfilling, I would say is just to have other collaborators who, without me owning it without me like doing the main part of the work of editing and authorizing it, they wouldn't have a platform, to have their conversations. So that feels really good too. I think just, it's just like sometimes stuff just needs.

Someone didn't push it. It was just a little bit like the energy to do it, especially when you've been contributing all month. And then you're just like, I don't want to run it. Release notes. That's the last thing I want to do, but having someone else do it is helpful.

John: [00:30:05] Yeah. Yeah. It's super important work. Making sure that communication to the broader community is clear and accurate and projects that, fail to document sufficiently. What it is they do and what they're doing or are going to be doing a struggle because people don't understand. So it's it's usually important work, like the value add added by, I think like co-leading information and editing it into something digestible is so high.

And I don't think it gets quite the recognition that it should as part of the open source process. So good on you for for doing that and making that happen. I'm sure. It's felt is is better for it. 

Dani: [00:30:45] Thanks. Yeah, everyone who's listening to this, you spell it or at least try it.

John: [00:30:49] yeah. And I'm sure it's a good networking opportunity for you to you get to be a part of the community in a, in an important way and meet everybody and have all that stuff. So it's a it's a win-win, it's not just a give it goes both ways. So that's cool too.

Dani: [00:31:03] Totally.

John: [00:31:04] Yeah, sweet. I think we're getting up there on the time and we should probably find a nice way to say goodbye.

Dani: [00:31:13] Oh, yes. I guess tune in next time or me diving into the habitat. Which would be something that I'm looking forward to given that I have not seen it at all, and I'm not an iPhone user. So you will get lots of interesting feedback of me telling you that this is a weird thing. And you might just say, Hey, that's how I,

John: [00:31:33] So it's just how Apple told us to do it. Yeah. Yeah, definitely looking forward to it. Yeah we'll get into building habits. We'll given, we'll give an update and a an Danny level. What the fuck is this? Conversation, which I'm sure I will. I will enjoy if I'm only a little bit nervous for.
Danny, it's it's a pleasure, like always, and I look forward to the next time we're in the same place and we get to have a beer and talk about whatever it is we talk about

Dani: [00:32:02] Same. Thanks for having me on

John: [00:32:05] bye-bye.

Dani: [00:32:06] bye.