Welcome to another episode of the website 101 podcast. This is the podcast for people who want to learn more about building and managing websites. I am one of your co-hosts Amanda Lutz. With me this week is Sean Smith.

Hey, Sean, how are you? I'm doing good. Doing good. Excited to be here and looking forward to recording this episode. Excellent. Our other co-host Mike Mele is under the weather today, so he will not be joining us.

But instead, we get to talk to Ben Crocker again. We've had Ben on the show before as a reminder. Ben Crocker is a craft CMS. plugin developer is also a plugin trainer and consultant. And he's a lover of the outdoors and adventure.

Hey, Ben, welcome back. Hey, good to be back. Thank you. So I don't know. Maybe we should mention this is actually a take to of recording this podcast episode due to technical difficulties that happened the first time.

We got about 20 minutes in and then it just died. Yes. And I will mention that it was my fault. Everybody showed up and And I'm in Costa Rica now, so we get power out of the just regularly. And we do have a backup power system that failed.

We had a generator which I started up that failed to. So the irony of needing technical support in that moment was not lost on me. Hopefully things go smooth. So when you put in your technical support request to get your generator running,

did you follow the guidelines that we're going to talk about? Well, I did not put in a support request. I just kind of let it cool down. And then a couple of hours later, of course, it worked. So it was the typical, turn it off,

wait a bit, turn it back on. Turn it back on. Yeah. Hey, that's always a good first step in troubleshooting anything. Absolutely. Yes. And the physical world is a little bit different to the virtual world.

Obviously, we understand the differences, but technical things are technical things so that they share a lot in common, too. I think we're kind of privileged to work with software because we get updates.

send down the internet pipelines to our computers, which is pretty amazing. And we can, of course, get people to send us code samples or tips to things to try out. So we're pretty lucky in that sense.

Yes. Absolutely. In university, I had a co-op work term where I did tech support at a revenue Canada office. And on my first day there, and I'm trailing around, I'm shadowing some senior tech person

or tech person. or whatever, and the very first ticket that he went to go do, he tried a bunch of things, he tried a bunch of things, and what ended up working in the end was control-alt delete three times.

Wow. And I just thought to myself, how would anybody, like once, yes, I get it, maybe twice, but to do it just three times in a row. And he was like, yep, that fixed it, let's go. There's no explanation, no rhyme or reason.

It was very frustrating. That's interesting, cause, you know, all three of us have then done technical support. I'm Ben. Click. Click. does it for his plugins Amanda did it and I previously worked for Alice Lab doing technical

support in the forums. You did and those were very active forums back in the day. Oh they were. It was fun. I did that for a little less than a year. I forget why but I stopped working with them and well here we are now today. It was a good learning experience about what to do, what not to

how to interact with people. Oh, that's awesome. So, Ben, what are some things that users should consider before they submit a support request? So, they're working with your plugin or somebody else's plugin or even just whatever code

that they're trying to do, and they're looking for help. What are some things that they should do before they ask for help? Right, I think first of all, it's important to consider nobody actively like things,

oh, I'd like to create a support request. Like, they just want their problem solved, right? And if they could, they would turn around and ask the person sitting next to them. But if that person isn't there or doesn't know, then they actually have to create the support request and go through this process.

And there's this phenomenon I've found where intelligent, well-meaning people become kind of like lubbering buffoons when they need help, like in a rush, right? And myself included. Like, I've been there, so I'm speaking from experience.

Like, raise his hand. It's a situation of, you know, I need to get this thing launched or I need to get this thing delivered. This one thing is holding me back and it turns into this kind of a crime for help.

But the end goal of what we're trying to do is we're trying to solve our problems. So we need to consider that when we're asking for help so that the person who we're asking for help for can also kind of help us reach that goal as well.

But I think probably the most important thing to do. or before you submit a form as a for request is do some like collection, like data collection of what is the problem? I go through that process and mentally

and there's this thing called rubber dogging. Maybe you've heard of it where- I was gonna mention that, yeah. Yeah, but programmers should have a rubber dog on their desk next to their computer and if they run into an issue,

before you send out this cry for help, ask the rubber dog. And simply the act of formulating the question. often forces you to go check other things which tends to in many situations kind of like allow you to find the answer on your own. So just kind of taking that

pause and exploring what the actual issue is and formulating the question in a way that provides all the information necessary. We'll often get you the answer just in the act do we? Yeah I've found that rubber ducking

does work but I don't actually intentionally... when we do it, I find that when I start to write out a support request or when I'm talking to somebody about it, it's the act of going through and explaining step by step by step.

And then all of a sudden I'll have this epiphany is like, oh, it could be that. That's it. And it's solved. And I don't actually have to submit the support request. So I mean, it's rubber ducking, but it's like the last step just before I submit.

Yeah. And our tendency is to reach out to a person. as the first step. But if we read out, if we simply reflect on the question and go do some discovering on the issue, then we can often, not always, we'll find the answer.

But that already sets us up for creating a good support request. And I think our focus today is going to be on the side of the person who's creating the support request. But I think later we should also discuss setting up,

as a plugin developer or as a developer providing a product, how you can set your users up for success in terms of how they should go about creating that request and channeling them to the right place to submit that.

Absolutely. Yeah, that's a good idea. So back to your question though, I think that's the first step, is doing some recon and figuring out what the issue is. As we said earlier, turn it on, turn it back on is...

is step number one, in most cases. If it's your generator, do what I did, turn it off, come back 10 minutes later, and it just works. Or the router, or the Wi-Fi? Yeah, if it's the router, the Wi-Fi, the printer,

these things, we've all been asked, I think, by friends, relatives, can you, my printer's not working? And there's no question there, it's just like a statement. We should be able to say the magic word.

And often that does work. My wife actually will often call me over saying, this is not working, this is not working. I'll walk over and I'll say, OK, what's not working? And then she'd be like, oh, it now it works.

So there's often this like just, I don't know what it is, but it's this kind of, when you're doing something in the presence of somebody who you think knows what's going on, then things tend to work.

Have you found that? Have you come across that one? Well, I heard, so I've heard, anecdotally, this story a very long time ago. Somebody in a car, they had a brand new car, they were very excited about it.

And they noticed that whenever they went to the ice cream store. and got a certain flavor of ice cream that he would go back to the car and it wouldn't start again. And so trying to like contact the car manufacturer and explain that it's like it's not when I drive to work

and it's not when I go to the mall and it's not when we go up for dinner, it's when I go to this store and buy this flavor of ice cream. And everyone thought the person was cuckoo pants because even like at some point

they were like even when I go to that store and I got a different flavor of ice cream, the car will start. It's no problem. It's only ever this flavor of ice cream. And I don't know how they figured it out but eventually what it came down to was that...

The car didn't have a chance to cool down. So this flavor of ice cream was at the front of the store. So their trip of going in and getting it and paying for it was like half the time of picking any other flavor

in the store. And so just going back outside and trying to, like so it's often times it's like, it seems like something ridiculous that makes absolutely no sense. But if you can use that almost like as a detective

and try to figure out like what exactly is the cause? It's not ice cream, but it's like the wait time. So yeah. oftentimes it's so frustrating. Yeah. That's a really good story. Oh, come on. The car is possessed and it just doesn't like that flavor of ice cream.

Because causality is like it's important and it's risky because we can get into this thinking that, you know, like you said, I have to hit control all the three times. And I'm not saying that was not the solution.

It worked in that instance. But you know, maybe that person just had to wait long enough and three times was long enough. Yeah. Maybe. So that comes back to, you know, turning it off, turning it on kind of forces you to just

wait for the thing to restart or allow it to cool down or, you know, sometimes we simply don't know what the issue was. But once it's solved, we kind of, you know, just get onto the next thing. So we don't even take the time to figure out what the problem was in the first this.

But the more you can do upfront on your own, I think the better. So we talked about turning it off, turning it back on that, I guess, advice to your computer or your web browser. Or if you logged in like log out log back in maybe it has to do with your current session

And then I would say like once you've tried those things aren't and you've waited a bit of time If you can that's that's a challenge because you know, we're often in a rush to get the thing working Then I think it's important to figure out. Okay. What is this the correct support channel?

I'll often get like kind of support requests. I get a C ground call them But they're more like questions on direct messaging apps, sometimes on Twitter, sometimes on Discord. And it's okay as a first step of reaching out,

but it's not ideal, right? Like direct messaging back and forth, asynchronous communication is probably the best thing because we can work through a problem together regardless of whether one person's online or not.

And there are much better tools than direct messaging for submitting support requests. So I think figuring out what is the official. support channel is an important step and hopefully that is something public

that has some sort of issue tracker that is searchable and discoverable which will allow you to kind of do a like a web search but within that issue track. Yeah I was just gonna say if it's something that's

public then if you're the first one with that issue when it gets resolved you're helping future people who have come across the same problem. So yeah, getting support by DM, you know, it's more personal

or email, it's more personal, but it doesn't help everybody. And Google's not indexing it. Like if you've got a GitHub issues, which is very common for the plugin developers in craft, I can just Google the problem. And a lot of times it'll show up the link to GitHub.

Yeah. And this is, this is why I use GitHub, where one of the reasons I use GitHub issues, it's discoverable. It's public and I can refer people back to it. I can search it myself if I know, oh yeah, I did answer that question,

but I don't remember the solution. I can refer back to it as well. And as you said, search engines will index it. Before we go on, actually moving to something else, I just want it. We've talked about users Googling for answers and I'm sure users should start

using, you know, AI solutions like chat, GPT, etc. or whatever to try to help them find solutions. But I find that really the biggest one is just go and read the documentation. RTFM. And I have fallen victim to that as well where it's like I thought for sure I was following

every step of the instructions and then it's not working and why and tech support. And it comes back and they were like, well, the documentation says this. And it's like, oh my Lord, that was the step that I missed.

And after that, everything worked great. So just like with a recipe in the world world, just follow step by step and actually Take the time to read it and don't skip over things because you think it's not important.

Documentation is really important. Not speaking for plugin developers. Not every plugin developer has the best documentation. Ben is good. Andrew Welch. And there are others, but there are some plugins that have really poor documentation.

And I recall a story that Mike mentioned that he was trying to get some support. The developer came back and said, as it is in the docs. you need to do this." He went, Mike went and checked the docs. It wasn't there. So the issue here,

I think, is that the developer knows their software so well that they forgot to include it in the documentation or they planned to, but they just didn't get around to it. And they're like, yeah, it's in the docs. It's really easy and it wasn't. The documentation is a good plan,

but it might not always work for you. Yeah, well, and the documentation too is often... at different levels, like maybe somebody more junior needs a little more handholding or somebody more senior doesn't want to like troll through pages and chapters like to just get to get to

the very advanced specifications that they need or want. And you can't have documentation at different levels that's way too much work for the plugin developers. Please work on the plugin instead of the documentation. It's a hard balance.

I think documentation is the hardest job for the developer, not the actual coding it, but you have to write it in such a way that it's It's easy to follow. Searchable covers edge cases and just everything.

I think it's a difficult job. If I remember, Greg, last time I was on my mention that support is about 50% of my time, which might be surprising. But that does include answering support requests, but also documenting things, going through the docs

and reworking them, writing articles and knowledge on a base. documents, writing frequently, ask questions and common issues. All of that stuff for me is just as important as you say, as the plug-in actually doing what it's supposed to do.

Because if people can't use it, then how much functionality are you really providing? And I try to be as disciplined as possible when the support request comes in and I answer it, I will then go refer to the docs and see what does do the docs explain,

that question that that person had. And if not, could they? Or is there somewhere else like it frequently asked questions section where it might belong? Again, just to help future me and future people, users from being able to solve this issue

on their own. Yeah. One of the things that I like about your documentation, especially for Sprig, is that you went through and you've got a cookbook where you've got things that common tasks that people want to do with it.

And it's really helpful. And I... Even though I use Sprig on almost every site I build, I constantly going back there to check things. It's more than just documentation. It's examples real live example code that you can actually use.

Copy and paste it and it just works. It's great. Yeah, some plugins are going to be very simple to use or an intuitive. You turn it on and it just works. Other plugins like Sprig, there's a learning curve and part of addressing that learning curve

is giving people not only documentation, but examples and sample recipes as we call them in the cookbook. I have a whole video series on how to create different types of components and make the source code available.

The whole idea is there is, this was two ideas. One is to reduce the support load on me, and the other one is to allow developers to give more advanced complex things on their own through giving them all

things learning resources. And that's part of support as well. Hi, Amanda here. If you're enjoying the website 101 podcast, we would love it if you could give us a positive review on Apple podcasts or wherever you get your podcast.

Reviews help new listeners find out about us and allow us to keep doing the show. Thanks. So speaking about users, when a user comes to you and they've got an issue, what are things that you want or would expect them to include in a support request?

Sure. So I think everything we've talked about up until this. in terms of what to do is like before you actually submit the support request. And there's one maybe important step is to update the software.

Like make sure you're on the latest version because one of the first things that I'm gonna ask a user is what version are you on and how many tried to update? Because updates are there to not only add new features

and functionality to pieces of software, but also to fix issues and fix folks that are known about. So if you're a few versions behind, chances are, or there's a good chance that Maybe you've encountered a bug and that bug has been fixed in a future version.

So updating the software is important. But really, I think it's important to kind of explain the problem from a kind of roundabout situation of, you know, this is the issue that I'm encountering. This is what I would expect to happen, but this is what's happening.

Here's everything that I've tried. Maybe if there's an error message, here's the error message I've encountered. Here are the steps for you to reproduce it, which is really helpful. Because if it's something that appears to be a bug, then I need to be able to reproduce

that to be able to confirm or deny that. And like you were saying, Amanda, with the guy who his car would start after going to the ice cream store, that's not something you can reproduce. So like how can you help this person?

unless you go with him to the ice cream store and take some measures. And we can't really do that here. And similar to the ice cream store, because craft CMS itself hosted, it can be running on all sorts of different environments,

different machines, and different operating systems. So it's difficult to reproduce some, or we can really reproduce someone else's entire environment. So we need some code or something that we can.

reproduce the issue and troubleshoot it. So providing like if it's appropriate, things like screenshots, error messages, and code samples that I can take, reproduce, and then fix the issue if it isn't an issue or tell the

person what they're doing wrong are all like greeting important things. When I make a support request, the first bits of information I always include at the top or the CMS version and the plugin version.

And then if there are any other relevant plugins that might be affecting things like in that template, I'll include that as well. But I think that you should know what version of the plugin I'm on.

And there might be a reason that I am unable to update because for some reason the production site, we just can't do it, then you need to know that, hey, I am a few versions behind. Yes, because if I want to reproduce your environment, I need to maybe backtrack to that version.

and see if it was an issue. Yeah, so one of the ways of addressing that is in, I mentioned GitHub issues. GitHub issues allows developers to create different issue templates. So for example, for a bug,

I'm able to specify what you need to tell me how to reproduce the issue and I can make different fields so that everything is laid out and I do that because I want to ensure that the person is in.

done some due diligence. I'm able to request the version of plugin, kind of old version of Craft CMS and dependencies. And you mentioned dependencies shown, which is an important thing because dependencies add a whole lot of complexity into software.

And it's something that's difficult to, yes, you can provide all of the version numbers of your dependencies, but difficult sometimes to know is the issue being caused by the piece of software that you're using, that you're

interacting with, or is being caused by something that it depends on. That's always going to be a challenge. And therefore, I think you wrote an article about reducing dependency on plugins to PEPI.

Yeah, I'll include a link to it in the show notes. I'm sure. But yeah, I wrote that and it gets mentioned several times in the Discord because really, the fewer plugins that you use, the better it is for the life of your website, in my opinion.

Fewer dependencies, fewer things that can go wrong, fewer things that need to be updated. Yeah, if you're moving parts. We've talked about some of the things that would be good to include. And I also like that on GitHub issues, sometimes there'll be a template there to show you the

type of information that's expected. What are some things not to include? And do you have any hilarious stories about people that have just sent really wild and appropriate information that you just did not need?

API keys? Yeah. Oh yeah. Yeah. Secrets have been sent. Because very often when you. send error messages or stack traces, yeah, or a log file. Those will include secrets. So I have had plenty of situations where secrets have been incurred in there. And I'm able to

delete those in the issue tracker, but it's still never good to do that. So some amount of redacting before you send your logs would be important to do. I do ask, like I mentioned, for code samples when relevant. Sometimes I will just...

just get like a wall or code. And in those situations, it's difficult because it's like, you know, how much Sean is hiding in this happening? Yeah, because in January, I did that to you. I was gonna bring it up myself, but you brought it up

and it was, referring back to what you said earlier, it was like, I need to get this fixed and I just dumped this, the entire template instead of stripping out what was relevant. I'm. I. I'm so sorry I did that too.

That's okay. I don't remember this exact situation. Oh, thank God. My guess is that my answer was, you know, please provide the reduced. Yeah, it was something along that line. Yeah. And, you know, on the one hand, you know, I don't think it's worth my time reading through

hundreds of lines of code just to find the, you know, three lines of code that are relevant. But on the other hand, like I can't copy paste that into my environment and reproduce it, right? Because you're likely.

referring to different sections, maybe by their IDs, that kind of thing, that I wouldn't have in my local copy. So getting a code sample that is just reduced down a few lines of code that really demonstrate the issue is important.

Anything else that you would like to exclude? Yeah. The other thing that I think is important is anything that is an actual security issue. So if you discover a bug and you don't really know what's going on, that's fine.

But if you notice, hey, this is something that could actually be exploited and maybe... sensitive data could be stolen or manipulated or something, then there's a bit of a different process for submitting that.

It probably should not go through any kind of public and issue tracker. It should probably go directly to developer. Most developers will have a security policy where they outline steps that you should take

to submit at the potential security issue. And that will normally be... They're in the same form of a support request where you describe the issue and the potential security implications, but they'll go directly through email or through some sort of private

channel to the developer who can then address that in a more responsible way. Yeah, that makes sense because you don't want that security issue out there before it's fixed. Yeah, that's it, exactly.

And usually there's this grace period, security of this whole cyber security, this kind of whole other world. And that I've dipped my toes into and I find it interesting, but it's a bit alien to me too.

But this is kind of grace period when security issue is reported. The security researcher or whoever submitted it will not disclose it publicly until a patch or security fix has been released and normally for one or two months after that point so the

people have a chance to update their software and make sure that it's security. Another important reason why updating software is so important. It's not just those bug fixes and those features, it's those security updates.

Yeah, and actually since CMSs and plugins rely on other packages from GitHub, if you update the CMS or the plugin, you're also getting updates of everything else that might have a security issue that even Ben might not know that there's a security issue in a certain package

that he's using, but he updated it with a new version for Sprig or... whatever plugin he's updating. And so there would be like this rabbit hole of potential security fixes. So I guess that brings us to, you know,

once you've submitted the support request, what are the next steps? And hopefully if you've gone through that process, you've given the developer all of the information, then you're going to receive a quick response.

And you've done your work upfront. So that response is not gonna be like, well, what version are you running? Or, well, have you tried turning it off and on? Because... That's the other thing that as the people providing support, we need that information.

I'm unable to help somebody who hasn't provided the basics of what's necessary to actually encourage them to try what to try. Hopefully, you'll receive a response that points you in the right direction or even

gives you the summation. And I think once the issue is resolved, I think... it's good to go close the issue. If it just started working or if you solved it in a different way, I think it's also a good idea to kind of put that in the issue so that other people

are maybe experiencing the same problem. Don't just kind of get a blank at the end, they can actually maybe learn from you. I think everyone, everyone has been super frustrated when they go search for the issue that they're having. And one other person was like, describes

the exact same problem like on Stack Overflow. And then the only comment is... is from a month later from the same person where it's like solved. And it's like, how, though? What did you do? Yeah.

So it's definitely helpful to keep everybody up to date. Oh, 100%. I tend to follow up with support requests with GitHub issues of, like, if I see two weeks of past and this person hasn't responded to me, I'll say, hey,

did you get that? Like, you said, Sean, closure. Like, did you get that issue resolved? I want to make sure that they did. And if they did, I want to make sure that they. I want to encourage them to explain how they date for, you know, for anybody visiting that in the future.

Yeah, I try to almost always go back and and close the issue and Thank you for your help fixed this fixed it or like you said, I Ended up not needing this or whatever like just let people know that you walked away from it and it is done

Yeah, right and closing the issue kind of In github it doesn't force like you can still comment on that issue, but it kind of shows code and sometimes people then follow up with the next question. And I'll try to encourage them, hey,

can you create a new issue because it's a completely different topic and this issue goes just for my own organization. And it's helpful. Right. So having a support system, I think, in place, like an issue tracker, you can get notifications from GitHub

notifications is great because I don't get a stream of emails coming in telling me that the something's I can check it in my time and I do that, you know, visually in the mornings. And then I can organize the issues based on priority,

based on what's been answered, what's pending. If you have a team of developers and you can assign issues to different people, so having some sort of system in place, I think is really important. And support for me kind of bleeds into the product as well.

I can try to build support into the. the product or the plugin. And what I mean by that is, anytime you have to enter information or choose settings, I try to explain those settings in place, in context.

Rather than forcing or expecting people to read the dots, they don't. I can explain. This setting means that what is the implication of? And I'll also use info windows that can be expanded that explain.

things in more details and when appropriate link off to the docs for even more details. All of that, you know, it's really just helping or encouraging people to have a good experience using your plugin, which means that, you know, they don't get stuck, they don't get frustrated.

That's really important for quality product. How often do you run into an issue with somebody that you cannot find a solution or to a new product that takes a crazy amount of time to figure out, like, it's a super edge case.

Yeah. And do you have a story you could... Sure. Those are the tough ones. Yeah. The easy ones are like, oh, you just need to disable this setting. Or here's the link to the docs. Unfortunately, for me, the majority of the support request

are relatively straightforward. I can address them in a couple of minutes, or there's some back and forth getting information. But it is those kind of edge case support requests that are very time consuming that kind of cause some worry

because I think like the car that doesn't start, like, did I do something wrong? Is there some big issue or not big? But is there some bug hiding in my code base that only crops up in these certain situations

and also known as an edge case bug? And yes, those come up not that frequently, but there was one not too long ago actually. And it just took a lot of looking and a lot of trial and error. It was only happening in one specific environment on Amazon AWS, which I tend to avoid.

I think we all do. Yeah, it's over complex. So it was not reproducible locally. It was not reproducible. I couldn't reproduce it on any kind of server that I tried. And we have a lot of back and forth

because site was already in production. It's happening in the production server. So it's, you know, it's. And all of the entire scenario just made everything difficult to troubleshoot simply because it was not reproducible.

Once an issue is reproducible locally, I can run a bunch of tests. I can use step debugging to step through the code. I can try things out very quickly. But in this case, it was like, make a change, ask the person who submitted the support request

to test it. I guess they were testing and staging. But it was a... mirror, the production server. So all of this just took a long time. And it felt like, I think it took us about two weeks, two and a half weeks, maybe in total,

to troubleshoot that earned. That's challenging, yeah. Because it's always at the back of my mind. Is this some big issue? Why can't I figure this out? In the end, it happened to be this unique scenario

where it had to do with the environment, but it also had like, there was a combination of three different settings that had to be in a specific configuration. And it it turned out to be a bug so sounds really difficult to troubleshoot

Yeah, and there's always the question there like is it an issue with the plug-in or is it an environment issue? Environmental issue that I have no control over well it's so often those those Production environments are nothing but a black box

like Oftentimes as developers we don't even have access to it because we've got like all of these auto deploys that happen now So it's just kind of like a day You know, hopefully it works out and if not, I'm gonna have to figure out some magic

Right. It is a black box. You're right because we can't really look inside it, especially when it's, you know, this virtual server that's posted on in the clouds more. But yeah, it was a bit stress-inducing because I don't know if it has to do with my code or the environment.

And therefore, I can't really put up raise my hands and walk away, right? I need to kind of figure out because it could be an issue with the plugin. In this case, it turned out to be... And I'm grateful that the person worked with me for those two weeks or so and to get to

the bottom of it. And now, you know, now it's solved and now it's documented. So hopefully if it comes up again, we know how to address it. Yeah. I'm sure that they appreciate the effort that you put in.

It must have been frustrating for both you and the support, the person who put the support requests in. Yeah, for sure. And I know that they, for example, had to their development agency. So they had their clients telling them, hey, this is not.

working and they were the middle person and they were communicating what's mean. Fortunately, they're very good developers so they were able to work together with me and to kind of get to the bottom of it. But they had pressure from their clients which I completely understand.

So yeah, fortunately we got through it but those those edge case bugs are tricky and likely stress to me. Awesome. Thank you Ben for coming out and talking to us again about support tickets and how everybody can work together.

to get any issues figured out. Thank you, it's been fun. Yes, Ben, thank you. You're a friend of the show. Come back again. You'll be our first triple guest. Yes. And I'm glad to. The website 101 podcast is hosted by me, Amanda Lutz.

You can also find me online at amandalutz.com. And by me, Mike Mela, find me online at belikewater.ca or on socials at Mike Mela. I'm Sean Smith, your co-host. You can find me online at my website,