Slow & Steady

Benedikt shares a major life update. Benedicte gets things wrapped up before vacation.

Things were slow for Benedikt last week in preparation for his big day. Despite the slower pace of things, the Userlist team accomplished a few things: they worked on their message rendering refactoring, and made progress on their trigger unification. 

Feeling a bit frazzled, Benedicte wraps things up before they go on their summer vacation. She also enjoyed her time at the recent React Norway and felt very powerful (and old) when she helped someone out at her bank job.

Benedikt and Benedicte talk about pull requests vs. merge requests, going down rabbit holes, and more.

Creators & Guests

Host
Benedicte Raae 👑
Queen Raae - Let's get the most out of @GatsbyJS | Creator of POW! — the privacy-first menstrual cycle journal (https://t.co/t2m6aOaCgM) | Co-host of the @SlowSteadyPod
Host
Benedikt Deicke
Software Engineer & Co-founder of @userlist. Co-host at @SlowSteadyPod. Running @femtoconf. Creator of @stagecms. Loves music, food, and cooking.
Editor
Krista Melgarejo
Marketing & Podcasts at @userlist | Writer and digital marketer by trade | Still trying to get that science degree 🎓

What is Slow & Steady?

Join us as we share what it's like to build and launch a bootstrapped startup while working for yourself full-time. Benedikt is working on Userlist, and Benedicte is establishing herself as a Gatsby expert and developer advocate for hire.

Benedikt:

Welcome to Slow and Steady, the podcast where you can follow along as we build products in public. Each week, we'll give you an honest peek into our lives as we share our struggles, our and everything in between. I'm Benedikt, and I'm feeling happy.

Benedicte:

And I'm Benedicte. Today is June 26. This is episode number 183, and I'm feeling frazzled.

Benedikt:

Oh.

Benedicte:

But let's start with you. That's a much better feeling. You're happy.

Benedikt:

Yes. I'm happy. I got married last Friday.

Benedicte:

Totally out of the blue for me, but maybe not totally out of the blue for you.

Benedikt:

No. Not totally out of Blue for me. I kinda knew it was coming. But it was like it wasn't nothing big. Like, no no fancy wedding.

Benedikt:

No nothing. Just, just the 2 of us getting married. No guests. No no no no nobody. Just a photographer and, someone from the city council.

Benedikt:

So, Yeah. Pretty pretty small and relaxed, and we enjoyed it that way. But it's been a long time coming.

Benedicte:

Still a major life update.

Benedikt:

Major life update. But, I think I talked about this on the podcast in 20 late 2020 or 2021, Early 2021 that I got engaged, and it took us, like, two and a half years to actually get engaged.

Benedicte:

I feel like that happens a lot. Like, I have friends to who've been engaged for, like, years. I'm going to a wedding this summer, I guess, in 2 weeks. I haven't been to a wedding in years, and they got engaged, but then suddenly had 2 kids. So it's, like, taken them 5 years, 6 years, something like that to kind of get to the stage of getting married.

Benedicte:

Like, Getting not getting a marriage, getting a wag wet wedding up and going.

Benedikt:

Yes. Yes. Yeah. I mean, we didn't have Kids, but there was a pandemic, so that didn't help. We always, like, we always assumed you wanna have, like, a A big wedding, like, with with people and well, not a big wedding, but, like, at least have guests over and stuff like that.

Benedikt:

And then first we couldn't do it because COVID, obviously. And then once that was kind of ebbing down, it just felt so overwhelming to plan anything of That size that eventually we decided to, well, fuck it. Let's just let's just do it without anyone there. And that That's what we ended up doing, and I I think this was the right choice.

Benedicte:

Well, I'm really happy for you.

Benedikt:

Thank you.

Benedicte:

And you looked very cute. I got a photo for those who who's wondering.

Benedikt:

Yeah. I'm looking forward to see the the actual Photographer photographers photos, because we're not like, because we didn't have any guests and stuff like that, we had a lot of time Take photos.

Benedicte:

So it was basically a photo shoot?

Benedikt:

It it was basically a photo shoot. Yes. That was what most today was about, and then we had a nice dinner in, yeah, in in the evening. Went to our favorite vegetarian restaurant and, Haven't been there in years and it was so good. We should definitely go back there more often.

Benedicte:

Yes. More fun and celebration in everyday life. Yes. Yes. Totally.

Benedikt:

This is

Benedicte:

more of everyday life than anything else.

Benedikt:

Absolutely. Why are you feeling frazzled?

Benedicte:

I know. There's so many unclosed projects. I started too much, And now I need to, like, wrap them all up.

Benedikt:

I see. Yeah. That's that's always my That used to be my problem, like saying yes to a lot of things and then feeling so overwhelmed and then basically having to make sure I finish them all in time and in some order. And then I'm like, I'm never going to say yes to anything. And then Once you get back to, like, a reasonable amount of projects, you start saying yes to stuff again.

Benedicte:

Yes. That's all. Yes. Also, I just need to realize that life happens. But then again, like, this semester or with half year because I just saw your note that it were, like, half of the year is done, which is insane.

Benedicte:

Yes. But, like, I managed to have a concussion, like, 2 bouts, like, pretty You know, we had, stomach bug, and then we had the, some kind of flu, and then saying yes to all that traveling, which was a lot of fun. But it's all left me a little frazzled because everything has gotten pushed out a little bit more than I'd like to even though I do like Crunch time, it's just a little yes. I'm just a little frazzled. But this happens and I know I just need to make Action on things and then I feel much better again.

Benedicte:

So yeah. It is what it is. Like, You know what the meditation people say is, like, just you're frazzled. You'll just have to, like, let that feeling be there And just do your things anyway.

Benedikt:

Just accept it and then push through.

Benedicte:

Just accept it. I kinda crashed this weekend, actually. I was Gonna do some work because Leland was gone, and I kinda just crashed on the couch watching television series, but I think it was needed.

Benedikt:

Sometimes that's what you need to do to, be more productive to follow-up.

Benedicte:

Because I woke up at 5 this morning, and I was like, yes. Like Let's do it. Let's do it. And I've had a fun day. Like, we're like, not such a frazzled day.

Benedicte:

Like, I just I'm gonna do this project. And I did, like, a video script that's fully done, and then I can, record tomorrow. And then tonight, I'll do some of the admin stuff. I don't want any more concussions.

Benedikt:

Yeah. I I yeah. I wouldn't recommend those. Not a good idea.

Benedicte:

No. Because those kind of linger. Crunch time is harder when you can't, Like, look at a screen for as long as you're used to without getting some sort of, headache. But also on the fun side, we went to React Norway again this Sierra, and I am so happy I paid my way in because on top of everything that's happened, I would not have gotten a talk together. Like, that would just not have happened.

Benedicte:

But we met a lot of friends from last year and just kinda generally had, like, a chill out day, which was very nice. And I've gotten a car for the summer because of, some you know, with my mother's health, I need to be able to go back and forth between countries. So I, got a car, so we got to ride that down there. And now I'm just very scared I'm gonna become dependent on this car it's pretty nice.

Benedikt:

Yeah. Yeah. That happens.

Benedicte:

That happens. So I'm gonna try just like it's a summer luxury. It's like one of these, like, long like, semi long term rental deals. But back to business.

Benedikt:

Then at least there's an end date on it. Right?

Benedicte:

Well, you know, it can be extended indefinitely.

Benedikt:

It can be, but it doesn't have to be. Right? Like, when you buy 1, it's there.

Benedicte:

And it's only got like, it was a 50% off for the 1st 3 months for this specific model, so That is only for 3 months. And after that, like, it's double the price. So that kinda gives us a deadline.

Benedikt:

Yeah. That that helps a little bit.

Benedicte:

That helps a little bit. So But what's been up with business?

Benedikt:

Yeah. Kept it a little bit slow last week, to be honest, because I didn't want any Major problems on Friday when we got married. So we didn't ship anything, but there has been work happening, and we made some progress. Specifically, we had one of those things happen a couple of weeks ago, and we were like, Yeah. We should add more, like, validation error messages when people try to save messages and stuff like that.

Benedikt:

And you're like, sounds easy enough. Let's just add it to the UI and that's it. Yeah. Turns out adding it to the AI was the easy thing, But it actually surfacing the validation errors on the back end side of things was a little bit harder. So I spent Almost a week refactoring how we render messages on the server side so we can actually run those validations, before we actually

Benedicte:

just Swallowing the error message and just saying, like, a general validation error, or what was happening to the messages?

Benedikt:

That's like, the stuff we now added To be validated would not be executed until we actually send a message. So We previously were just checking, like, is the subject line there? Is the message body there and stuff like that? But we also added stuff like, Are there embedded images in there? Are the is the liquid syntax correct?

Benedikt:

And stuff like that. And those arrows wouldn't be surfaced until we actually render stuff. So we had To refactor how we actually render messages and have a way to do this, like, during save, I guess. Like, when we save, The the the broadcast or the, the campaign. And that turned out to be a bigger refactoring.

Benedikt:

Like, it took it took quite a while. I I feel like we have a good model now and a good implementation that's better than what you had before. But the biggest part of this was, like just surfacing those errors and getting those errors as an API response. Yeah, so that's there. It's not deployed yet, But I'm going to deploy it this week.

Benedikt:

As I said, like, didn't want to to roll this out last week for for reasons. And then I also finally got back into that other refactoring I've been talking about with, where we unify all our triggers into just 1 implementation. And instead of like 10 or 20, I don't know how many it's these days, I made some significant progress on that. It's still not done, but the general ideas I had Seem to be working out. And, yeah, it's it's exciting because it it removes a lot of code and a lot of complexity.

Benedikt:

And that's always my jam. And then one interesting thing I discovered or, like, I don't know. It's kind of obvious in hindsight, but what I did differently this time was the unified triggers. Sure, it's kind of a refactoring, but it's also kind of a new feature. And to make this possible, I had to Refactor a lot of existing code and and rearchitect how we do certain things.

Benedikt:

And previously, I would basically create a branch, Do my work refactoring work there, add the new feature, then open the pull request,

Benedicte:

and then merge it into into the main branch.

Benedikt:

But the problem with that is usually, That the pull request gets insanely large because it's the refactoring plus the new feature. And While it's still just me reviewing code on the back end, like I'm reviewing my own code, especially as a project takes longer. And over a couple of weeks, it's near impossible to follow what I was doing and what actually is a change that is a refactoring and what's a new feature. So what I did this time is, started doing the work on a branch, as usual. Also pushed it and I created a draft pull request.

Benedikt:

But then instead of merging the entire thing, I started new branches based off that branch and pulled out the refactorings and then, just opened pull requests for just the refactorings. And then it's super clear, like, what's going on. So we had pull requests that just changed existing implementations Without adding new features and without changing behavior. And those were obviously a lot smaller and, like, just focused on one thing. And as you merge those refactoring branches, the original pull request with, like, the feature and refactoring, like, The diff gets smaller and smaller and smaller, and at some point it's just that new feature.

Benedikt:

And It's so much nicer. Like, it's so much easier to reason about. And now I can actually look at that feature branch And

Benedicte:

it's a feature.

Benedikt:

It's a feature. It's just that new functionality. And it's so much easier to review. It's less files changed and all of That and it's one of, as I said, like, obvious in hindsight, but I I will be doing this a lot more in the future because it's so much better.

Benedicte:

You have to be pretty disciplined, and you have to kinda know where you wanna go. I

Benedikt:

I don't know. I wouldn't Say that because those refractories can still happen incrementally. Right. I know that the feature branch Still isn't quite there where I want it to be. But I know that the changes I made and the changes that already merged At the Refactoring, those definitely made the code, like the existing code better, even though they don't include a new feature.

Benedikt:

So I feel like I might be doing this a couple more times with that existing branch, just, like, adjusting to what I've learned. But, Yeah. Merging the the refactorings along the way.

Benedicte:

Mhmm. Did you merge them both to the future branch and to the main branch then? Or how did you do it, like, specifically?

Benedikt:

I basically did the refactorings on the feature branch and then created a new branch and cherry picked the feature, Like, the refactoring commits out of the feature branch, and then merge that that branch separately. Does it make sense? Mhmm. Basically, still working on the code, like, altogether and, like, doing the refactorings and the feature in the same place, but than just pulling those refactoring commits out of it and and merging them separately.

Benedicte:

I think there is with Symantec release. They have, a description of, like, a similar thing where you have a a longer living feature branch, and then You kinda do, when you do updates, you merge that both to main and then to your feature branch, I think. Like, they have a description, over the way of doing that and still getting their, like, automatic, release versioning.

Benedikt:

Mhmm. So Sounds somebody wants to similar ish. Yeah.

Benedicte:

Yeah. Somebody wants to look up, Like a diagram or description of how one can can think about these things.

Benedikt:

Yeah.

Benedicte:

But I've had some issues with, like, GitHub not updating. Are you using GitHub?

Benedikt:

Yes.

Benedicte:

I guess because you're cherry picking them from the feature branch. But this is my issue. Like, I did some rebasing or something, and, like, the diff didn't update where like, the diff in the pull request Didn't update. It was still, like, the original diff even though things had changed.

Benedikt:

Right. I think what I know yeah. Go ahead. Yeah. What I noticed was was that if you just push changes to the main branch, the diff and the pull request doesn't necessarily update.

Benedikt:

So I think it only updates when you push to the to the the the pull request branch.

Benedicte:

So it doesn't trigger any new jobs to, like, do a comparison then

Benedikt:

if you just

Benedicte:

do things on there. Because that was super annoying to me because I did, You know, I did a change to the main that I'd also done in the in my in my whatever branch. And then I realized, like you, like, oh, this should just happen anyways. Like, this should not be a part of of this feature branch or fixed branch or whatever it was. And then I pushed it to main, and then the diff was still like, all the changes, and I was like, this is not a helpful.

Benedicte:

Yeah.

Benedikt:

I guess it updates eventually, but it it takes it either takes a while or it doesn't do it automatically.

Benedicte:

I Yeah. It feels like an edge case with GitHub where they kind of, Like, don't catch that or something. I don't

Benedikt:

know. Yeah. Also, I guess they probably don't want to recompute the Pull request every single time a change happens on main. I don't know.

Benedicte:

Probably. Probably something like that. They should have a little trigger, though, like a little button that you could be like.

Benedikt:

Right. Yeah. That that that will be helpful.

Benedicte:

Please. Please refresh it. As you said, You know, I also always review my own branches or my own pull requests, and I still have not gotten this from GitHub. I should tweet it again, but I wanna be able to set myself as a reviewer and have be, like, in a reviewer role because there are things you're not allowed to do when you're reviewing your own code. Like, if you are the person if you are the person who created the pull request, you can't, like, write a review.

Benedicte:

Like, make a review of the pull request like another person would, which is super annoying, because they assume another person. You know? But I you know, I'm 2 different people. You're, like, you know, you're Benedicta the coder, and then I'm, like, Benedicta the reviewer. And if you at least give it 24 hours, Those are completely different people who need a completely different feature set from GitHub.

Benedicte:

Yes. So I'm gonna resurface that tweet because I keep. And people are like, but why? I'm like, because I wanna get into the reviewer mindset and be able to just comment onlines and be like, hey. You should do this.

Benedicte:

You should fix this so that I can actually see that those things get resolved when I resolve them. Yeah. Split personality type thing.

Benedikt:

Totally. Yeah. That's I usually don't comment on my own, like, pull requests, But I do this so often where I didn't just push changes and open up the diff and then go through it file by file on GitHub and just Look for stuff that feels off and then I try to fix it right away or at least make a note somewhere to look into this. And it's so helpful because I don't know why writing code, it looks different than while reviewing it.

Benedicte:

Yeah. And it's and it's also just because of that different interface, it gives you kind of a different mindset. Like, okay. Now I'm in review mode. It kind of just triggers a different way of looking at the code, like you're saying.

Benedicte:

And for me, with multiple projects, like, something at times I can do a review on my own code and see that I need to make changes, and I can't make them right away. And I wanna be able to log them in a similar way as if you had done a review, or maybe I'm waiting for somebody else's review. But I'm seeing like, oh, I see this issue. Like, let me just document that right away instead of instead of the other reviewer having to document it. Right?

Benedicte:

Yeah. Yeah. So I still think GitHub. GitHub, listen to me. I need to be able to give myself a review.

Benedikt:

Yes. Totally. Yeah. That that yeah. That will be useful indeed.

Benedicte:

Otherwise, I have to log in. That's like the other one.

Benedikt:

Yeah. Correct. Like, create 2 separate user accounts. Right.

Benedicte:

Yeah. Yeah. Ray, the reviewer, and then just Ray. Anyhoo, I don't need any more accounts anywhere. That's for sure.

Benedikt:

True. True. Too.

Benedicte:

If you have a Ray dev and Ray Cloudinary and maybe some other ray. I don't know. I don't know. Okay.

Benedikt:

But It's already getting out of hand.

Benedicte:

It's getting out of hand because some companies, like, they want you to have, like, a separate, GitHub account that that Don't have access to other things. I mean, it makes sense, like, if you're gonna get access. There are security policies. I I I don't fight those kinds of things. Chad, on the topic of GitHub, I am planning to open or create an etcetera GitHub organization because we have been getting some Some request another request.

Benedicte:

A user has just made typings for us, Like TypeScript typings for the script. And I'm like, yes. But then, also, we should probably have some prior to to host community initiatives and stuff like that. So I'm gonna open and not set up GitHub organization and see if we can get The that repo started there. And then also see when I create, because I'm working on the Framer integration, that Kind of the integrations we are making could be open source as well because there are so many tools that we could integrate with, and I think more eyes on that could be interesting.

Benedicte:

And, also, people are willing to contribute. That will be an exciting chapter to see if people are willing and how to manage that and

Benedikt:

all that.

Benedicte:

Do you have anything like that for UserList?

Benedikt:

Yes. Yeah. Basically, since day 1, we we created a GitHub organization very early on because, like, all our our integration libraries are on there And

Benedicte:

just a

Benedikt:

few yes. Public. Yeah. Because the code is on on RubyGems and, Packages and and NPM anyways. Like, it didn't make sense to keep them private.

Benedikt:

And also this way, we get sometimes we get contributions. Not a lot, but sometimes it happens. And it's just I mean, why not? Why not keep it there? Then a few weeks ago, we actually migrated The user lists, private repositories to the organization as well because they have been on my personal account for the longest time.

Benedicte:

So the code is on Bitbucket, but I'm not creating a public organization on Bitbucket for people to contribute to. So we are using version control, like, you know, but we're just not on GitHub. So Yeah.

Benedikt:

That's Doesn't have to be GitHub. Right? This can't be us.

Benedicte:

Doesn't have to be GitHub. But I think, like, At this point in time, GitHub is where you wanna be if you do want people to contribute. It does make it easier, and especially for beginners, I think if, You know, what they learn often in the beginning is GitHub. And if you are looking at any tutorials on how to contribute to open source, Then I will think all of the examples are from the GitHub user interface. So it just makes sense to to be there because, Yeah.

Benedicte:

I for for many and it took me a while, and it takes, beginners a while, I think, to kind of understand the difference between GitHub and Git. So Yeah. Yeah. In the beginning, let's just pretend there are none and let them use their you know, let them

Benedikt:

use their Let's just pretend it's the same thing. Yes.

Benedicte:

Let's just pretend it's the same thing. But now I'm using so outside eyes on Git, Bitbucket, and then the bank is on GitLab. And then my life is on GitHub, so I'm using all of the clients.

Benedikt:

Yeah. Yeah. Is it all git though?

Benedicte:

It's all good. Yeah.

Benedikt:

Okay. That's at least something. Could be Oh, yeah. I don't know. Some some of the others.

Benedicte:

Oh, it's been a while since I've seen SVN.

Benedikt:

Yes. Luckily, it's been a while.

Benedicte:

It's been a while. It's been a minute. No. But The weird thing is in GitLab, they call it merge request instead of pull request, which, you know and the way we're using it today makes more sense. But it just gets me so confused when people are talking about these MRs.

Benedicte:

I'm like, what MR? What are you like? Like, I have to do that mental gymnastic every time to be like, oh, PR. Okay. PR.

Benedicte:

And also to then write MR instead of PR and Communications with people and stuff. But yeah.

Benedikt:

Yeah. Makes sense.

Benedicte:

I'm wondering if GitHub ever will change from pull Request to merge request. Do you think so?

Benedikt:

I don't I don't know. I don't think so. Yeah. It's like a brand name, but at this point, right? I mean, why would they change it?

Benedikt:

Take away

Benedicte:

the the ones who started. Yeah. They coined the term. That's true. That's true.

Benedicte:

Because I see every now and then people are like, why is it called a pull request? I wanna merge something. And then I'm, like, helpful in the comments. I'm like, it used to be That you said, pretty please, could you pull my changes? You know, godlike maintainer.

Benedicte:

Could you please do that? But These days, it's it's more of a, could I please merge my changes into your repository?

Benedikt:

Yeah. It's right. I still like now that I think about it, I still remember the days of GitHub without pull requests, like when pull requests. It was It was basically at the beginning of my professional career, I remember, like one of my job interviews. I sat there talking to the.

Benedikt:

It might be even that very day. I feel like it was one of the longest interviews. I was there in Switzerland and Zurich. And I was interviewing with them for 2 days. And I feel like On that 1st day at night, I read the announcement of, like, the 1st pull request version.

Benedikt:

And I vaguely remember talking about it, about about it with one of the developers at the company I was interviewing with about, like, Oh, how how this changes everything and stuff like that. So, yeah, it's been a while.

Benedicte:

It's been it's been, yeah, it's been a it's been a while. I helped somebody at the bank job change things with women, the terminal, the other day, And I felt very powerful and old, But I was like, oh, you can just do it. You know, I can do I can barely get by with them. Like, I can open. I can change.

Benedicte:

I can save.

Benedikt:

And you can close it. Right?

Benedicte:

So I can close it.

Benedikt:

I It's already more

Benedicte:

than way to close it.

Benedikt:

99.9% of all people out there.

Benedicte:

Yes. But it came in handy, and I got to help somebody just in the exact same way a senior helped me Do the exact same thing 15 years ago. Open the SSH config, Change something and save and close it again. Yeah. We even did sudo, which, you know

Benedikt:

Oh. Yeah.

Benedicte:

I was like, oh my god. I have, you know, progressed or whatever thing like, I have learned things the last 15 years.

Benedikt:

Yes. And the fun thing is always like people are like, oh, you know, so much stuff. And how do you learn this? That's just like the long list of things I stumbled across and failed to know Because at some point, I had to figure out all of this as well. So it's not like I magically, gained the knowledge.

Benedikt:

It was usually hard earned.

Benedicte:

Yes. And some things like that, it's not like you learned it in the course or anything either. Like, when I wanted to learn React, like, I found the course. I did some courses, and I was like, okay. Now I understand React.

Benedicte:

And then I took with me all the knowledge from other, you know, other frameworks and other things into that. But when it comes to, like, opening a file in Vim, it's like somebody showed me once, and those are the 3 commands I know how to do. And I've never sat down to learn anything more because you just have to at some point, you have to just put a boundaries of where you're gonna go down rabbit holes, and that's a rabbit hole I didn't wanna go down. But my friend Monica of Afilimate, she still codes in them, which is a whole different level. It just makes me in awe.

Benedikt:

Me too. Me too. Yeah. It's like it's one of those rabbit holes I, like, repeatedly look at. Admittedly, these days not as much as previously, but that's a rabbit hole I'd love to be familiar with, but It never happened.

Benedikt:

Like, I I tried a couple of times, but in the end, I feel like Moving the mouse pointer around is fast enough for most of my stuff.

Benedicte:

I think it's a little bit like changing A keyboard. Like, you can definitely get faster on a different keyboard, but do you have the time To be slow for a couple of months or however long it takes.

Benedikt:

I feel like my brain is not fast enough for typing faster. Like, I am not entirely sure I gain anything from being able to change code faster because usually Most of the time is spent thinking about it anyways. Like I Yeah. Yeah. I don't know.

Benedikt:

You

Benedicte:

could say the same thing with the so I'm gonna close out with this because we can end it. But but I read in university, I read a study. This was in user interface interaction that people who use keyboard shortcuts often feel like they spend less time doing something because they engage their whole brain compared to using the mouse. But when actually timed, they often don't use less time.

Benedikt:

Mhmm. Yep. I feel like that's a similar similar idea. Yeah.

Benedicte:

Yeah. But I think if you get fast enough, it's faster. But, like, you know, regular use cases, they found that it's not faster. It just Feels faster because you're engaging more of your brain. So Yeah.

Benedicte:

That is a pointless knowledge that I have in my brain that I got to share With everyone. Hello.

Benedikt:

Actually quite interesting.

Benedicte:

But why is it taking up space? I'm just kidding.

Benedikt:

Could be worse.

Benedicte:

Could

Benedikt:

be Simpsons quotes or something like that.

Benedicte:

I guess it could. I guess it could. I know no Simpson quotes.

Benedikt:

Me neither.

Benedicte:

See you around.

Benedikt:

No judgment. No. Like, listen. No

Benedicte:

No judgment. No judgment. No judgment. I do know songs that nobody should know.

Benedikt:

Cool. Well Yes. I guess then the last thing to say is, and you're listening, you might have noticed, we are kinda using like switching to a 2 weeks schedule by now, and there will not be an episode next week. So talk to you in 2 weeks, I guess. And see you right at Nan2Web.