 Thanks, Alex. And with that, let's welcome Patricia with the talk, I Can't Work Like This. Welcome. Thank you, thank you so much. So, thank you for having me. And good morning. I'd like to welcome you to Bugs as a Service. This will be our company for this morning. Bugs as a Service makes a bug tracker plus plus. It's a fancy company. But it's a very small company. It's a small team. Let me also introduce our problem. A problem is here represented as a purple ball. We don't know much about this problem. We aren't really sure if it's a serious problem or not exactly sure if it is a problem at all. And if it is a problem, we're not exactly sure if we have to fix it right now or if it's easy to fix or even if it will take a long time to fix. So it's a very, very unclear problem that we have. Now let's say that we could place that problem in some sort of system. So let's say that we could say it was a red problem or yellow problem or blue problem or a green problem. Maybe if we could classify the problem somehow, that would tell us something. But maybe how we solve problems tells us more about the problem itself. Like maybe we could distinguish different problems from each other by thinking about how we solve problems. So down here, let's imagine that we have crisis. Now this could be like an everyday crisis like a house full of three year olds, for example. These are unfolding crises like stuff will happen. You can't just sit down and pretend it's not there, things will happen. Like if your house is burning down, you can pretend it's not, but it will burn to the ground. So these are things that if you now don't do anything about it, it will resolve itself and probably not in a way that you like. Now up here we have other types of problems. Now these are problems that you don't necessarily know what the problem is or how to solve it. So you kind of have to experiment, try out different things, debug, try to learn. There's a lot of unknowns in this scenario. So a lot of detective work to try to figure things out. Whereas up here you have really nice problems, delineated problems, you know what the problem is, you know how to solve the problem. You're not really worried about that. You know that the problem can be solved. Now you're thinking more what is the best way to solve these kinds of problems. There are several ways, but what is the best way for us? Maybe there's this, you know, you have a tradition of engineering of best practices that you want to apply to the problem. Down here we have great wonderful problems. These are problems that are solved with automation and routine. These are problems we know exactly how to do. We just have to do it. You know, sometimes we might realize that there's some bug in our automation or maybe some steps missing from our checklist. But this is stuff that we can fix so that next time we do it better. But we know how to solve these problems. Now you have certain people that tend to work in parts of this. And so this system, by the way, is often called the Kenevan framework. It's made by a guy named Dave Snowden. And he talks about it as a sense-making framework. And he has names for these different things. So down here he calls this the chaotic domain. And this is the complex domain. And here is the complicated domain. And down here is the clear domain. So they have names. But I want to talk more about the people who work there. So you have certain people who tend to work mostly in one domain. So here we have Ellis. He works for Bugs as a Service. Ellis started off his career as a graphical designer. And now his official title is probably UX designer. But he does all things design and creative at this very small team at Bugs as a Service. He's a very creative person. He probably wants to be an artist. Maybe, and he likes to play music. So he actually has a SoundCloud just in case, you know, a tweet goes viral at some point. And he likes to try to figure out what is the best thing for the users. And does a lot of like off the wall thinking and just throwing ideas out there. Now here is Alex. Alex does not throw ideas out there. That's not what he does. He will throw solutions out there. If you give him a problem, he will try to give you a solution. Alex is also a little bit tired of his job. He's more interested in the stuff that he does at home. And he likes to play video games and he also likes to do a home automation and all sorts of like little pet projects and open source stuff that he has going on. And that's really what keeps him going because he kind of thinks his job is a little bit boring. But down here we have Bailey. Bailey loves her job. Bailey loves her job because it basically means that she can make order out of chaos. So Bailey is an SRE or Site Reliability Engineer, but she used to be just called assistant. Her basic role she feels like is just to keep the world from descending into chaos. So everything has to have a system. There should be orders. She's not a big fan of Alice's off the wall ideas either. She thinks that we should have a plan and we should follow it and no one should be all too creative about the world. Down here we have Parker. Parker is an instant responder. And this means that Parker has a very strange kind of personality. So when the world is on fire, Parker is smiling. When everyone feels like, oh my gosh and everyone is super stressed out, Parker is like finally my moment is here. So Parker will smile at in the most inopportune moments when things really are not to be smiled about. But you have also people that don't really know where they belong. Like here we have Finley. Now Finley wasn't dead, but then Finley got a promotion. Finley's not exactly sure that being a tech lead was a promotion because now Finley feels like most of her time is being spent in meetings and she actually really liked to code. But being in this complex domain and this creative domain is necessary for Finley because she has to balance the role of trying to figure out what is the right system to build versus how to build the right system, which is her dev side. And so balancing what should we make with how should it be made is a part of her role. You also have Oakley. Oakley is a senior dev. And one of the things that Oakley's been working hard on lately is automation. So working on the CI CD pipeline, making sure that, you know, when we push things to production, they work properly. Also making sure that there's an infrastructure that can be easily put up and pulled down and all of those things. So that's more in the clear domain where Oakley has been working with the automation. In the clear domain, you also find Kean, who does QA. QA means that Kean is basically everywhere all the time. Kean is known binary and uses they, them pronouns. And Kean loves to figure things out and actually quite enjoys when there is a disaster in some way with together with Parker just because finally, I guess things really went as badly as Kean always worries about. It's a strange thing. Kean worries constantly when when things actually go bad, Kean kind of likes it. Also Kean likes to investigate things and maybe that's why Kean likes it when things are bad because that that means that Kean can run around and figure things out what actually went wrong. And in a little bit, you know, making order out of chaos there. So let's take a look at our team. So we have Parker, our Instagram responder, Kean, our QA. We are our cyber liability engineer. Oakley, our senior dev. I like our dev. We are Kikli and Ellis, our designer. Together, they are the parts of bugs as a service, our company. Oh yeah. Sorry. I almost forgot. This year, this is Jeff. Jeff is our sales guy. Jeff talks on the phone a lot and smiles a lot and speaks really loudly a lot. Oh yeah, and, and yeah, here, here's this is Brad. Jeff talks a lot with Brad on the phone because Brad is the customer. Okay, so it's Saturday. All of these people are going to have a really bad day. So welcome to my talk. I can't work like this. And also welcome to Katie Academy 2021. My name is Patricia also I'm a trainer and a consultant. I'm a C++ programmer and programming now in C++ for about 15 years. And I've been specializing like the application security. And I worked for a company that I co-founded called Terabasec. I, my first job was on the original opera browser where actually we were working in the, in the floor above troll tech at the time. Then I went over to, to do some Java consultant for a little while and then went to Cisco where I made embedded shell process systems also using QF there. And then I went back to making a browser again at Vivaldi. And when I have time, I work on a pet project of mine, which is making a browser as well. So I guess I have a thing about browsers. I have a master's degree in computer science and my pronouns are she her. But back to our heroes. Okay, so Kean is our QA. Kean is always worried. That is sort of Kean's default state of mind where Kean is always worried, mostly about worried about whether something is Kean's fault. But in this case, Kean's worry actually helped because Kean being worried, Kean had started making all sorts of little monitors for production to see if weird things were going on because Kean gets less worried if there's monitoring and production. But this morning, early on the Saturday morning, one of the monitors kicked in. And it says data exfil threshold exceeded. Hmm. Okay, so we have an alert in production. Kean starts looking into the logs trying to figure out what is it that had happened. And they do look weird. So, Kean pays the rest of the team on Slack. I think something's wrong. So what seems to be pulling a lot of data off the server. We might have a problem. I mean, seems like a problem. But in comes Oakley, who's been chilling on the couch reading book. She takes a look at the logs. And, you know, they do, they do look odd, right. So she logs into the server it has a look around to see what's running there and this does not look normal. Okay, so she thinks Bailey, we need an SRE I on this. Bailey is not happy because Bailey was building IKEA shelves and Bailey takes building IKEA shelves very seriously following instructions is Bailey's favorite. But she does have a notification on Slack on at all times with sound loud, and she responds to the call to catch us up what's been going on and that she says, but nothing's happened. It's Saturday, everything was fine yesterday, which is not something that makes feel Bailey good makes Bailey feel good because Bailey does not like weird things happening in production. But the truth is something is off right performances down and massive amounts of data is being pulled off the server. So something's going on. We have a problem. And it is unfolding as we speak. So this isn't really an unknown class of problem anymore. This is clearly a problem in the character domain. We still don't know anything, and it is unfold. So we have a problem in the chaotic domain. Hmm. Okay, so in comes Parker, right? It's no respond. She pops in takes one look at everything that's been going on, and then goes straight to Bailey and says take the site and the server offline immediately. Then she helps us like very lucky and Bailey and they need to figure this stuff out because something is seriously wrong. But our first set of heroes have done a very important thing and especially Parker. They moved the problem from the chaotic domain into the complex of the did this very simply by taking the server offline. By taking the server on the site offline, they got to put a pause button on the problem. It was no longer unfolding was giving them time to have a look at problem. So we're not leaving data anymore. We still don't know what was going on. We don't know what has happened, but at least we know that it has stopped happening, whatever was going on is not currently happening. So we have some time to try to figure it out. And so our heroes managed to move the problem from mechanic into the complex. In comes Ellis, our designer and Finley, our tech lead. Now they are here for a totally different reason. They also pop into Slack, but for something completely different, they have alerts on the Twitter account for for bugs as a service. And they've been added on Twitter. Some weird tweets. I'm cryptic tweets really. First one shows up at 8am says we got your data. And then like, are you still sleeping. And then that was as a service doesn't care about their customers. The catching up family starts to worry that this has something to do with what what is currently being debug what is currently being investigated right so she jumps in and tries to debug the system on a zoom call with Oakland. And they just they also think I like to join them because you know something is going on we need to figure it out. But Alex is busy. Alex is gaming. Alex is not one to work on Saturday. And he sees the pain. Okay, fine. I'll come debug with you. But come on. So they all sit down on the zoom call, all trying to to mob debug this problem trying to figure out what is what is going on. Meanwhile, Ellis is dying deep into the Swedish fear trying to figure out what is going on with these tweets like does this person or the people know anything do they actually have any data what is going on. In comes Brad, the customer. Brad is not happy. Brad is having a bad Saturday morning as well. Because Jeff, our sales guy, who is trying to be chipper. Brad is screaming, what is going on the server is offline we can't get any work done. What kind of terrible product are you people making. And Jeff was like, Oh, I'm not sure it's nothing. Let me check with the team. Don't worry. It's we'll get it back in a jiffy. Hopefully and I like they're still sitting around trying to debug this problem at when Jeff turns up in the zoom call. And Jeff is not happy on a Saturday morning either. Jeff starts screaming to everyone what is going on. I've got the client on the phone he says the server is offline. I need info ASAP. I'm not doing anything anymore. All we have is a zoom call where Jeff is just screaming at everyone to do something but nobody can do anything because Jeff is screaming. And choose the matter is Alec didn't want to be here anyway. I like wanted to be home gaming and it's not working out for Alec and now it's someone screaming at him for something that Alec believes strongly is not his fault. Alec gets angry. Listen we're trying to work here. Be quiet leave us alone. We're actually trying to get to fix your problem but we can't do anything as long as you're screaming. Jeff, Jeff is not having I have a paying customer on the line and he answers now. Jeff thinks that solving problems is something that you can do by yelling at people. So, so the idea here is that if you yell more at people they will do more things. Unfortunately, that doesn't really actually work the way that Jeff thinks it does. And the thing is Alec is not having it anymore. He is sick and tired. It's early Saturday morning he was having a good day and now everyone is screaming and he can't get his job done and he is sick and tired of this job anyway. And so he just screams right back. I can't work like this. It's clear somebody has to defuse the situation. So family steps in being tech lead that's sort of her role. She takes Jeff off the call and sits down with him on a separate Zoom call. And meanwhile the customer is still screaming on Jeff's phone which is making Jeff like so kind of aggressive. But family now she can't participate in the debugging anymore because now she has to manage manage Jeff and Brad's feelings because they clearly can't handle the situation. And Jeff on screaming and yelling. Meanwhile though, Alice has been diving into these tweets and he has come to the conclusion that they are spake like even though we have an ongoing situation with something going on with data. These are these these people don't have any data and it was just an accident that came at the same time. So basically we're not too worried about the tweets anymore. He has made some discoveries. No one. We're not saying who but it was totally Alec. I committed the server credentials to the open GitHub report. And but but the thing is luckily there's no no no sensitive information there there's all everything that's there is just stuff that you could have pulled off to scrape off the website anyway. So whatever these people are pulling off the server, it's not sensitive and nobody really cares so the situation isn't as bad as it seems. It's still kind of embarrassing because you know, it is what it is. But through this, this, this process with Ellis investigating the tweets and key and looking at the get logs. They have discovered what the problem is and they have moved the problem from being in the complex domain into the complicated. And the complicated domain is the perfect domain for software developers because now we know what to do. We have leaked data, but the data was not sensitive so we don't really care about that. But the intruder had access to the server and that we don't want. So we move the problem into the complicated domain but it's not finished we still have stuff to do. But the heroes for moving, moving a problem this time is elixir designer and key in our queue. So they managed to figure out what was going on and move the problem into the complicated. Okay, so back to the zoom call. Then Lee is back together with Oakley and Alec now the problem is is at least clear we know what the problem is. So together they discuss what how it should be fixed. So they form a plan. The first one isn't really necessary but they really want to remove the credits from get history mostly because they find it embarrassing and also because it's a bit embarrassed about the whole thing. But they also need to bring new servants and online instance online with new credentials and everything and bring the site back up. So Lee, Alec and Finley have made a plan and by making that plan have basically decided that the problem should be solved through automation by bringing up the site again. So they have moved the problem into the clear domain. So our heroes this time and move the problem down here. Excellent. Okay, so down there we have a new set of heroes so we have Oakley our senior that was been working with Bailey or SRE for a long time before this on automation and and they have they have a system for for taking down and bringing up the site on new instances. And they have key into to do their initial testing. So they take that they use what they already had, and they get a new server instance online point all the traffic towards it bring up both the site and the server online again. And key industry initial testing on the live website and thumbs up bugs as the services back. And now Brad the customer should be happy which would make Jeff the sales guy happy again and and everyone can go back to having a happy Sunday or Saturday. And so we had a problem in the clear domain, but it could be solved in the clear domain. And we moved it all the way there by moving it from chaos to complex to complicated and finally to clear. And we managed to fix it. So it was in the clear domain, managed to to bring the site back up and bugs the services back. Now, the thing is that this model with these, these four domains don't really reflect what we did today, because most problems start as unknowns, and then they move. So we started off with a purple problem, which is basically saying we don't exactly know where this problem belongs. And after a little bit of an investigation, it turns out that this problem was in the chaotic domain, and then that's where we pulled in our crisis management. Right. So this is where Parker took the site offline and where we have some time to define the problem in the complex domain. Once we figured out what the problem was, we moved the problem into the complicated domain where we could use our our engineering experience and good practice everything that we know how to do to figure out a good plan to fix it, and ended up that the fix was actually in the clear domain with automation and routine. Now, if you look at the Connecticut framework how how Dave Snowden draws it he draws in more like this. And so what we have here is this little space in the middle where we can put things that are unknown. So this is our unknown problem. In our case we figured out that it was a chaotic domain we moved it into the complex domain that into the complicated and finally into the clear where we solved it. But any problem when it starts up we don't know where it belongs and it could end up in any domain. It's just in our case that ended up being in the chaotic domain because it was unfolding. So now sitting back afterwards let's do a little bit of a of a think about what happened in our process. So, I like it from the sit down have a cup of coffee. Let's do a little bit of a retrospective, you know, a postmortem on this problem. What is it really that we need to learn from this. So Alex, I like ask family is like what is, what is the underlying lesson here what should we learn from this like how can we, how can we use this to become better in the future. And then they don't push credits to get up I mean, you know, but I was just now really like what what should we learn from this because there must be a lesson here for us. And maybe be folks being different isn't isn't a bug. Maybe that is actually the future. Because what we saw here is that people thinking differently and acting differently in different situations, people being used to different kinds of problems were contributing to the problem being moved through the different domains to finally ending up in a situation that we could fix. It is to look at this, this chaotic domain, people operate in the chaotic domain who like to to operate in the chaotic domain. They are generally decisive people, people who walk in and kind of boss people around. And in most situations you don't like people, they're very annoying people. And when there is an unfolding crisis you want someone to take, take initiative to take some kind of leadership role. It feels really comforting when things are falling apart around you to look at a person who seems to know what they're doing. And oftentimes that that role is not so important that they actually know what they're doing as long as they can act confidently. And people who are used to working in the chaotic domain they have that that calmness in the crisis, where they can walk in and look around, see what is essential right here and now, and and and move on that information. So so for example, a first responder who walks up to to someone has been in an accident, looks them over and and and thinks what is going to kill this person first. I mean, what in looking over a house full of three year olds going okay so how can we get the situation of the control. Looking at a house on fire going okay so first of all we need to stop the fire. We can worry about what caused the fire later but we have to stop the fire first or stop the fire from spreading this kind of of drilling down into the essentials are the kinds of of qualities that you need in people who operate in the chaotic domain. And the complex domain you have the people who who are creative who are out of the box thinkers but and and they there's a system to the madness but it might seem very off the wall to people looking at it it is a creative process it involves a lot of back and forth. Trying things out and finding things that don't work. It's not a structure process and it can frustrate people so much, especially people who are used to being in the conflict in complicated domain or in the clear domain. Because people in the conflict of complicated domain they like structure, they like systems, like you, if you would, if you look at developers move between the complex and the complicated domain. People in the complex domain that's where you make your prototypes that's where you try stuff out that's where you do your first bring up just to see if it works. Whereas in the complicated domain, you, you, you have a plan and you follow through. And, but even though it's like if you have a bug that you don't know much about you might start off in the complex domain by just by debug just investigating trying to figure out what is going on. But once you know what the bug is you move into the complicated domain we like how should I fix it. It becomes a well defined problem. And people who are used to operating the complicated domain can be very frustrated with people working the complex domain and vice versa people in the complex domain or creative. People might feel like they're not allowed their creativity when people want them to tell them exactly how things should have been done in advance and they're like I don't know I have to try. But probably the most frustrated person with people in the complex domain and maybe also with the complicated domain are people who are used to working in the clear domain. These are people who are used to solving their problems automation and routine and process. They do not like all of this like back and forth changing stuff. And they definitely are not fans of complex people who are too much imagination and too much creativity and too much throwing things at the wall and see what sticks. People in the clear domain don't like that they like like a plan a system and they want they want everything to be running perfectly smoothly all the time. The best thing would be if everyone would just like stop moving for like five minutes so that things could just work. Now when it comes down to what should we learn from this I think key in is actually have a different opinion. So key in things that the real lesson here is that you should never underestimate QA. They know where all the bodies were because it was key in that actually managed to dig up that someone I like I checked in the credentials to get help. And by doing that key in was managed to move the problem from the complex domain into the complicated domain. No, all of the deaths were sitting around trying to debug the problem but none of them actually found the key. And one of the special things about QA that you might have noticed here is key in is operating all over the place. Both both in the automation in the clear domain and also in the crisis it was actually key in that that discovered the problem in the first place. So that Parker could come in and get that decisiveness and shut down the servers. But it was the investigation that Keen kept on doing because Keen kept on digging and some people are like that they are just super curious people and they just want to know. And that keep that digging was actually the one that saved the day to actually bring the real bug into into the light and making it possible to fix it. And also later for Keen to test it. So so Keen was the one that was kind of running around all over the place, but not really getting a lot of credit for getting stuff done. And some people are like that they are neighbors in their teams, but they don't necessarily get the recognition that they need. They are. They practice their work by making other people better. And some some of those those roles are not necessarily well recognized. Keen does not make a big deal out of themselves Keen Keen will will instead dig up little nuggets of information here and there, giving it to people to to then run with it. So we have our company bugs as a service with Keen down here who is all over the place kind of person. And Bailey, who is the one that will structure everything to make sure it works to get everything in line and to make sure it works every day, the way it should. We have Parker, who you know it's it's fun to have a system and it's fun to be creative but what is really fun is when everything's on fire. Which means that Parker will be the the inappropriate smiling person at any kind of disaster area. But that is what Parker loves to do. Oakley is super happy both with with being able to build things but also to be working together with Bailey to to find a good automation steps to make the whole development process smooth. Because Oakley believes pushing to production is the best thing. So making sure that that is safe is something that Oakley really appreciate. Ellis are designer. Now he is the creative spirit and all of this and totally underrated by most other people because people don't realize that that the creativeness that Ellis brings to the table is actually what makes bugs as a service so popular. It is what makes at Brad the customer be so angry because it actually matters that the site is online. And that has a lot to do with Ellis's empathy and how Ellis can relate to to the end user. And then we have Alex who sometimes kind of misses the ball at work but mostly because Alex might not be as challenged as he should be. He's not having enough fun at work. He's not really feeling inspired these days. That's something maybe his colleagues could help him. Maybe he needs to be challenged more given more responsibility given given a chance to to use those skills that he clearly has to to grow more at work. And then we have Finley Artekli who managed to juggle these roles of hers from being this this kind of a people person who has to manage a team but also manage and manage the sales guy Jeff and and the customer Brad and then manage them when they went off being very angry. And managed to pull them off the team so that the team actually managed to solve the problem. And sometimes that is a huge job of being the buffer between the anger of the people who are solving the problem. And Finley really pulled that off. Unfortunately that meant definitely couldn't really participate much in the solving of the problem. And that is the story for today. It's a story about a team, building something together and and solving problems as a group. And what I hope that you bring from this is that sometimes you might look around at your colleagues and be annoyed. You might be maybe you're an Alec, maybe you're a little bit disgruntled with your work, but most of the time you just annoyed that people are just, they don't have proper plan. And so what I'm hoping that you will look at this and think, okay, actually, all of these people participated together to fix the problem on Saturday morning, working from home from their couches and managed to bring it all together and not despite their differences, but because of their differences. And that is something that I hope that we can all bring together and to see that even though we're different, we can all bring our whole selves to work. And by doing that, we can make our whole teams and our whole organizations better. So thank you so much for listening. And that is my talk. Thank you very much, Patricia, for this talk. It seems that we have a Q&A widget for the attendees to use. And also, maybe we can encourage them to ask in the chat. Yes. If that's not a problem. There's a small delay in the stream. So let's give them a moment or two to type the questions in either the widget or the chat and we'll see. So the chat, is that the KD Matrix channel? Yeah, the Academy Talks one. That's the one everyone is watching right now. Okay, the chat is full of applause so far, but also in the widget, I see the very first question from Kai. What was the name of the underlying model again? Oh, Kinevan framework. So it's written like similar thing with C and Y. It's apparently a Welsh word. So he's been working on it for, I think, like 10 years. Dave's known. It's a very interesting, and he has lots of interesting talks about it. So I really encourage you to look it up. Okay, thanks. I can also bring it back. Someone already linked it in the chat. Thank you. IP wizard. Yeah, exactly. I don't have the chat right here. So if there's questions, please read them to me. Yeah, yeah, I'm looking at the chat. So far, mostly applause and thank yous and no further questions yet. One of the things that I found really interesting about this model was mostly this realization that people are used to different kinds of problems. And that being used to different kinds of problems like here. Let's see if we have these here. Being used to different kinds of problems means that you approach problems in different ways. Like Parker is a very decisive kind of take charge kind of person. And that kind of personality works really well in a crisis, but it doesn't work very well if you're in the middle of a creative process. If you're trying to figure out what should we do? Should we do this or this? Then if somebody comes in and tries to decide, it breaks the entire process. And you might end up with a suboptimal solution because what you need here is more of a facilitator. Like trying to figure out, get people to talk and bring those ideas out and spin off other people's ideas to try to nail what is a good solution for us. And when you go into the complicated domain, it's more about what is the best way to solve the problem. We don't want to be too creative. We want to follow best practices. We want to be structured. And there you might have your test of development and you have a certain flow of things. And people there are not too fond of the whole creative process either. And then in the clear domain where Bailey is, it's mostly about uptime, keeping things together. It's like we don't want to have a complicated system for anything. We want to make sure it's the push of a button and everything just works. And people who are used to working in different domains have different kinds of personalities, but they're all needed to make a good feature or a good product. And I think we fight too much without actually realizing that we are. Being different is good. Okay. I don't see further questions, but in case people do want to ask you later something, do you have any contact information? Yeah, you can reach me on Twitter. My handle is here. So it's pati.discordayardo on Twitter. And my DMs are open as well. So just ping me whenever. Oh, one question came up while you were showing the Twitter handle. Where would the salesperson go with solving problems by yelling strategy? I think if you ask Jeff, I think Jeff would say that he is up here without like he's a reasonable man with like reasonable plan. But the truth is, and he's probably more over here in the creative domain where he's more, but it doesn't really have the tools, I think, to do the actual design. So it's more of an instinct that, you know, I want people to stop yelling so I will yell at other people, which is a really bad solution to a problem. So probably more of a personality like Parker would have been better in that role, like being able to just be calm and like somebody's yelling at you and you're like, yeah, yeah, I understand that you're angry. We're looking into it, you know, and not reacting by just turning around and yelling at somebody else, which is not really constructive. So, yeah, yeah, I definitely think he's a little bit off the charts. Okay, I think that's it for the questions. Again, thank you very much, Patricia, for the talk.