Well good morning, thank you for their introduction. So yeah, I've been doing this for a really long time, usually longer than I care to admit. And I've done all sorts of cool stuff. I work for government, I work for startups, I've worked for enterprise companies. I've touched the code problem in the sites that all of you go to every day. But what I realized is all it means is I've been fixing other people's problems really for a really long time. And so this talk was somewhat born out of that. But on top of that, there was another fact that really played into me talking about this. And that is a cloud really ruling everything. It did, it really did. Because we all got used to the whole mentality of destroy and rebuild, right? And that's fantastic. But it is vaguely familiar to an endowed reboot that we all talked about 20 years ago with Blinda was that we tried to get away from. The whole idea of servers being our cattle, everybody know the pets versus cattle analogy, right? Yes, good. So it's awesome, right?  That's awesome.  So in order to prevent that, you actually need to understand why your cows are dying, right? At some point, you may shoot it afterwards, but at least you've got to figure out what the symptom is. So trouble shooting as defined by Wikipedia and Willow Trust Wikipedia, it's a form of problem solving, right? You try to solve the problem. And in my definition, problem solving is an ability to fix things that you know absolutely nothing about. So why is it important? Why should we even care about this? And mainly it's because the systems we work with become more and more complex every day, right? We're not really building enterprise yet, but we're really getting there in some ways. And those systems break. And they break in the really spectacular ways. And what's worse, they break in a way, in the spectacular ways when you expected the least. And what happens then, right? How many of you here have a luxury not to have every one of your mess ups to be instantly seen by half of world? Like in other words, who doesn't work with web? Oh, there's one guy like in a bag who is lucky enough not to have that. For the rest of us, any mistake that we make is made available to hundreds, thousands, millions of people, depends on what you work with. And those people are generally not happy. And probably most important though is I know some of you may think that your job is to write the coolest software or whatever be, but in reality, your job is to fix code. Whether it's somebody else's code or code of you who wrote it a week ago, which is more likely. More likely than not, you try to fix what's broken, right? You try to keep the stability. So I wanna make one quick disclaimer before we go forward. When I mean troubleshooting, I don't actually mean picking up a ticket from a backlog, just going and fixing it and pushing it to production. I know we all wish to get a bug and sit there with a latte in the middle afternoon trying to figure out why the page is also lower than usual. In reality, when I talk about troubleshooting, which means everything is on fire, it's three in the morning, you're on fire, and the water buckets are full of gasoline, right? I'm talking about that kind of troubleshooting. So when you're in that situation, where do you begin, right? What is the first step you do when there is that problem you get woken out by a page or by an anger customer, which is even worse? Where do you start? And ironically enough, you start with replicating the problem. And I know a lot of people miss that part, but replicating the problem is really, really important because the input that you get about the problem is not necessarily the right one. You cannot imagine how many times I had a conversation, like after reviewing the code on push, and I'm looking at it, I'm thinking, well, this doesn't make any sense, right? I'm looking at the code, and I'm looking at the problem description, and there is no way they should fix this problem, like there is no way they should fix any problem really. So I go talk to a developer, I was like, hey, are you sure this fixes the problem? He's like, absolutely. I was like, how do you know? I'm like, well, it runs after this. I was like, did it run before? He's like, what do you mean? Let's talk. So once you actually, well, you should actually identify the problem, you need to isolate the problem, right? Because I mentioned that the systems are really complex, right? There is a lot of components to them, there is a lot of moving parts, and you need to figure out which part is broken. And it's not necessarily the part that warns you about, right? It's not even part of the error.out or send the page, it may be something completely different. So let me give you an example. By the way, all the examples I use here, no matter how ridiculous the sound are real examples, they happen to me. So keep that in mind. So this is an actual email, I got it from a customer as a bug report, said logins aren't working 100% of the time, alerts are going off periodically, and today the system didn't send out the scheduled emails, right? Pretty common or something on this line. So as an engineer, we parse it down to information that's important to us, which is logins aren't working and the system didn't send the scheduled emails, right? So immediately you get this email, you validate that it is indeed a problem, you get a chance at errors, and you go look into a login system, you look at SSO, you look at the email schedule, and you try to figure out what's wrong with this. Problem with that is, you're looking at the wrong part of the statement. The part they should be looking at aren't working 100% periodically today, right? Which indicates that the problem is not really in the systems that customer noticed, but rather there's a transient error somewhere that breaks different parts of the system periodically, right? In this particular case, for example, one of the nodes was out of this space. So whenever the processes would hit that node, obviously they wouldn't work, and that's why it happened periodically. But if you don't think about it that way, if you don't parse it out to really get to the root of the problem, you're gonna be going down the rabbit hole and trying to fix SSO when there's nothing wrong with that, really. And yeah, so once you get through all that, the third step, of course, is to fix the problem, right? That's, well, if it was, it would be the shortest talk ever. Because at that point, even when you isolated the problem in the way you identified the problem, you're still left with a simple question, right? You know what's the problem, you know it's broken, right? You confirm that it's broken, but you still don't know why. So you need to really understand what is broken. And actually, for the next probably a few minutes, 10 minutes, I'll be talking about this word, understanding. Because you really need to understand a lot of things when you're trying to travel through the systems, right? So the first thing, as we talked about, would be understanding the actual problem, right? And I can't stress enough how important it is to understand the problem you're trying to solve before trying to solve it. So many times I hear something along these lines, right? We can't support 100 requests a minute, we need to scale better. Sounds reasonable? I mean, yes, it should solve the problem. Except for 100 requests a minute means less than two requests a second. If you can't serve less than two requests a second, you don't need to scale. You need to improve performance. Those of you who don't know the difference between scale and performance, see me after this talk. Because if you try to scale it, right, you just throw money at the problem, like literally throw money at the problem without really fixing it. For the more visual of you, let's look at this graph. There is a problem there somewhere. Anybody can point that out? So, obviously, right? Somebody pushed the code, somebody did something that skyrocketed like the latency on a low terms. Except this is not the problem, right? If you look at the numbers, maybe they're too small. The performance degraded from about 200 milliseconds to 600 milliseconds, which is 200% decrease, so it's pretty bad. But 600 milliseconds is still pre-reasonable, right? So it may be an acceptable risk. This is the actual problem, right? The performance continued to degrade over time, which got to over a second at some point, which means if it hasn't been thrown timeouts to users at this point, it will at some point. All right, so what you actually need to fix is not the code that actually increases the performance, perhaps, because that may be a viable change, but the problem that keeps on growing and growing and growing. Because that will affect, at the end of it, affect the business itself, right? They'll affect the user, still affect the user experience. Which brings me to my second point that you need to understand. You need to understand the business. I have this quote that I've heard by a customer of mine many years ago that was still, by far, the best quote I've ever heard, and I probably use it in most of my talks because there are points to literally everything. Business people don't care about technology at all. They care about technology supporting their business needs, right? So honestly, I can talk about understanding business for hours, but I wanted to use the simplest example that everybody would be familiar with. 404 error, right? Everybody had those, everybody suffered from those. So what does that actually mean to you? I don't know, it's a page not found, right? Which means something broke, can't load the page, whatever it be. What does that actually mean to your business, right? So Amazon, if Amazon's homepage goes down, what does it mean to them, right? What does that affect the most? Anybody? Money, money, sales, right? I mean, the widget that shows recommended products on Amazon generates like 27% of their revenue, which is ridiculous, right, considering how much money they're making. So if a homepage goes down, the first priority should be to bring out that widget, right, that is right there, generates the most revenue. But that's a simple example, right? Let's bring something a little more complicated. Wall Street Journal, if Wall Street Journal goes down, what does it affect? What is the main thing that they can do? Advertising, it is not content, right? Although they're a content company. It is the advertisement, it is the ad revenue. They serve 32 ads on a homepage alone, 32. So you know what, if their homepage goes down, perhaps their first goal is not to show them the freshest content to the users, it is to bring out perhaps stale content, but with advertisement up, because every second they're losing money, because visitors come into the site. So whenever you try to establish it, whenever you try to build something, wherever it be, but even in a troubleshooting case, keep in mind that every technical decision powers some sort of business, right? So you need to understand the need in order to come up with the best solution, or even knowing what the solution should be, or prioritizing the solution in order to meet that need. And which brings me to my third understandable point. We need to understand the impact, right? Every time you touch something, you need to understand the impact of the change. And again, the more complex the system are, the more difficult it is to understand what is going to impact every time. But talking about impact and prioritizing, you need to be able to map the changes you're trying to make to that business need, right? So, and sometimes that means breaking stuff. Like it means legitimate to breaking stuff. I had a situation, this is actually a graph, I had a situation where a company was getting hammered during the holidays, like completely hammered, unexpected levels of traffic, great promotion, I mean great for the company, but the low times were ridiculous and high, right? At some point it become unbearable, so people were dropping out, people, users were getting timeouts. So if you have a performance problem that you can't fix, what do you do? You hide it, right? That's what Keshen wasn't made it for. So I was trying, it said it's fine, we're gonna pull it to a level of Keshen in front of it, we're gonna hide the problem, we can deal with the latency, let's do it. Problem is that for one reason or another, the way, they use Apache traffic server as their front end proxy. But the way it was configured, it could not serve non-SSL pages properly. There was some rerouting rules, it was extremely complicated. In about 20%, probably it's about 12% of the website was non-SSL, so effectively I couldn't put it behind the cache just like that. But you know what, I put it behind the cache anyways, because I was willing to break 12% of the site in order for the other part to work and actually serve customers properly, right? Because time is literally money. So I used to have big projects where I would run the query to show how much money the company makes every minute to show the developers what would the downtime cost every time they break something, which is an awful way to learn, but at least it gives you an actual perspective, right? It's not a theoretical, oh, we're gonna lose that money, it is physical money that you're losing every time the page is down. And the funny thing is marketers and business people knew this way before us, right? The 80% now is better than 100% tomorrow, who heard that mantra before, for marketers. Just a few people, surprising. But what actually means is usually marketers are willing to push something today, knowing well that it will break for 20% of the users and then incrementally fix it by tomorrow to be 100%. And the reason for that is because this way they get 80% of revenue today and 100% tomorrow versus fixing it until tomorrow and only get 100% of revenue tomorrow, right? It's a numbers game, which is very difficult for a lot of developers, for a lot of apps to understand. And what I just said is incremental improvements, right? It's one of the other keys to troubleshooting and to fixing problems, right? It is not black and white. More often than not, there is a lot of shades of grain between things being broken and things working optimally, right? I mean, if you look at an enemy of a problem, this looks like a pre-standard curve from when something goes wrong, right? You have a norm, right? You have a standard threshold for something which was great, then something happens whether you push something to production that you shouldn't or more people come to the site or there is a marketing campaign and then you have a problem, right? And then you get paid in the middle of the night, you start working on this, you fix the problem, everything gets back to normal. What a lot of people forget, I guess, because it's pretty common knowledge is that an acceptable threshold, which is much higher than a norm usually, right? So going back to the example that I gave, 200 milliseconds is a fantastic lot of times, right? But is 400 milliseconds acceptable for a short period of time or 600? The answer is probably yes, right? As long as it doesn't majorly impact the user experience, it's probably acceptable. So in this particular example, there was four different fixes that went into production before it actually got to norm. But after first fix, the user experience got to acceptable level and the business was still operating as usual. Right, so consider this, it doesn't have to be all or nothing, right? If you have even a short-term fix or incremental fix, do it, right? That's why we talk about continuous deployment all the time, right? So you could push small incremental changes. All right, so what have we learned so far, right? We need to understand what's important. We need to understand cause and effect and as such, we need to understand what impacts the business mostly and prioritize it based on that. And we need to take acceptable risk once in a while, right? We always gotta assess the risk between pushing to production, between making the change and wherever it be. So that's all great. And now let's talk something a little more fun. Now let's talk about what not to do when you're troubleshooting, which is gonna be significant or more rented than it was before. So first of all, like I said, don't assume, right? I mentioned it before and I'll probably mention it again in the next few minutes. Don't assume you know what the problem is and you know what the solution is, right? Correlation does not co-acquisition, right? If you wanna prevent people from drowning, don't try to stop Nikolaus Cage from making movies. By the way, that's a fantastic website. If you wanna go there and check it out, they've got a lot of awesome stuff. But yeah, correlation doesn't necessarily co-acquisition. So think about what you're actually trying to solve. Funny enough, don't trust the errors. Errors were written by humans and humans are faulty. I had a situation which is funny. I got a call from my bank saying, there is something wrong with your account, please come in. I was like, okay. So I come into the bank and a really nice gentleman said, oh, there is a problem with your birth date. I was like, that's funny. I'm pretty sure I haven't changed that in at least 40 years. I was like, okay. And he goes in the system, he logs in, he logs in my profile, goes, oh, I see it. Your birth date doesn't match the one on the credit score. And I'm like, again, that is really weird because I'm pretty sure I haven't changed that. And he keeps looking for another five minutes. I was like, oh, I see what the problem is. We don't have your birth date on file. So as a developer for many years who wrote a lot of crappy code, I understand how no does not equal something is really doesn't match. But it doesn't solve my problem, right? It didn't give me the right information in order to give a proper answer. So don't trust the code. I mean, don't. On the same token, we were talking about humans a little bit, troubleshooting is a stressful time. And it doesn't necessarily bring out the best in people, to say the least. There is a couple of, like when you troubleshoot, especially troubleshoot with people, there's always one or two, hopefully none, but the usual is one or two people who tend to complain more than to try to fix something. And there is a couple of excellent excuses that people give while trying to troubleshoot. This would be one of my favorite. It's not documented. You know what, at three in the morning when everything is on fire, I really don't care. You know what you should do? You should create a ticket, assign it to yourself and work on the first thing in the morning to document this. At this point, read the damn code. Even better, I didn't build it. Like, again, I don't care. Like, I don't care who built it at this point, I just care who's gonna fix it at this point. It passed all the tests. How many people heard people say that? Literally, everything is broken and the answer is like, oh, I don't know why it's broken, it passed all the tests. Well, I got bad news for you. Perhaps you should revisit your test suite. And by far, by far my favorite one is everything looks right. Like, you know what? Clearly it's not. I mean, it is the same as like, it works on my laptop. But generally, that answer comes in from the fact that people give up quickly, right? People go in, they look at something, they check the logs, the web page, they're like, oh, everything works. I don't know what's wrong with it. Oh, the pages are blown up, like the graph shows, all things, but everything looks fine, right? Everything's fine. So don't stop troubleshooting even if something comes up naturally. And on the same token, conversely, don't cling to the mistake because you spend a lot of time making it, right? A lot of people tend to, like be very protective of their own code, for example. So if you spend time on a code, they push that out and they're broke horribly, they will go out of their way to try to prove that it's not their code that's broken, which is awful because you're wasting cycles, you're wasting time, and in the meantime, the whole business is down, right? On the flip side of this, people think they have a solution and they work on it and despite being proven over time that that might not be the solution, they're very hesitant to just jump it and go in a different direction. So don't be afraid to change directions there, like you're there to solve the problem and not to feed the ego, right? That's the whole goal, like you're there to solve the problem. You can argue about it, you can argue about the documentation, whose fault it is, have a post-mortem, have a retrospective. Three in the morning is not the time to do this. And one thing that people always forget is don't be a hero, right? It's a team sport, as for help, right? If you are of your element or you think in your second pair of eyes, that's always great, as for help. General people are very receptive to that kind of thing. All right, so one of the things that I wanna talk about a little bit is tools. And I'm not gonna talk about particular products or whatever it be, I just rather wanna talk about the types of tools that you should be familiar with that would generally help with the troubleshooting. And there are three of them, logging, monitoring, profiling, which can probably be all wrapped in under the term observability. So logging, logging should be actionable, it should be concise, and should be parsable, right? And who's familiar with the log levels? Awesome. Who have them implemented in production right now, like those log levels? Well, less people, but still. Stop doing that. The only levels that you shouldn't print the production are error and fatal. And there's a couple of reasons for that, right? First reason, of course, is readability. When you need to go through the logs, like not the machine reading of those, but you actually need to go through the logs, you need to be able to find the information you're looking for quickly. So as an example, this is a log entry for a single request for one of the processes running. And it's fantastic, like it is awesome. It has the UIDs, it has all the data that we're getting, it had every step completed and whatnot, it has the timing. I mean, it's great, right? If I read through it, I'll get a full picture, I'll make sure every step completed properly, that's fantastic. Except for when I'm troubleshooting something, when I'm trying to find a root cause, this is all I care about, right? I care about the idea, I care about error. Everything else I can pull from other places. So it's much easier to digest and find the information, right? Chatter logs are never easy to parse and read. And another thing that a lot of people don't think about, verbosity is expensive, right? Logs are expensive. Like, that log that little snippet of code is 2K. Like, I mean, do the math, 100 requests a second, 60 seconds over two web servers, let's say, if not seven web servers, like you're aggregating max and max and max and max of logs a minute. So don't do that. Be selective with your logs, make sure that you can extract the information that you need when you need it. Unlike monitoring, you should monitor everything. You really should collect data on everything.  And I'm huge, huge proponent of business first monitoring, where the most important things are business related and everything should be supported in that. And it's such you need to be able to correlate it back to it. So again, I'll give you an example. Had a customer call and always starts with a call, right? And tell me we have a problem. I was like, okay, what's the problem is? And he was like, well, our revenue is down. I was like, okay. It's like something wrong with the system. Like, all right, let's take a look. So look at the graph. And luckily we had a metric for revenue. So yeah, I mean, if you look at the graph, there's clearly a dip in the revenue. So I looked through this and I was like, oh, I have to take a look at anything wrong with the system. So we'll look at the user performance, right? Maybe there's a latency like users can check out, whatever else be, looks pretty normal. We go through a couple other things. Database is generally a performance factor. We'll look at the database. Again, it's pretty normal, everything. And again, those are just a few. Like, you go through tens and tens and dozens of different metrics trying to figure out if anything's wrong. Everything looks fine. And I forgot to say, the company itself is a marketing company, right? They've been doing like, they had online entertainment. They had about 100 million users and send about 70 million emails a day, right? Because they're a marketing company, they have different campaigns, they have this, boy, it's all that stuff. So we keep on going down the shade and everything looks fine. And at some point I'm like, maybe you should talk to yourselves, people. I mean, really, like writing this down, everything seems to be ignored. But we continue digging a little more. And finally, we got to the email metrics, which we also are currently collecting. And apparently, one of the major ASP providers, accidental blacklisted them. Yahoo, I forget all however it was. Which means less people got the email, less people clicked on the link, less people went to the website, less people bought stuff, less revenue, right? So remember how said correlation does not cause causation? Don't underestimate the correlation. Like make sure you collect, we had a whole conversation yesterday in open spaces about it yesterday. Make sure you're able to correlate the business metrics, the ones that are important, to the metrics that you collect that support it, like system metrics, user metrics, performance metrics. And finally, I want to talk a little bit about profiling. And profiling is when you have the what, but you still have no idea why it's broken, right? You know what's broken, you know where it's broken, but you still have no idea why. And that would be any tool. There is a number of tools, obviously. It's your PR sets and tops, that's your Vellgr and Cashgris. There's a number of different profile tools that you'll use, Dtrace, Strace, right? So give you another example, the last one. I had a situation where the service ran out of CPU real quickly, like the cycles were spinning, it was really, really bad. And just looking at the distribution, it clearly was Apache, right? Apache was getting on the CPU. Problem is, I had no idea what process, right? I had no idea whether it's a particular page, particular process, what was it? So a colleague of mine, without a quick Dtrace script, they gave me this list. It basically parsed out all the requests and gave me CPU consumption per URL, which is amazing, right? It's awesome, because looking at this, like there's clearly the get all requests, you're all the CPUs, significantly, right? By a factor of 10, if not 100 over normal pages. I mean, fantastic may be a wrong word, but I was excited that I'd be able to get this information because with this information, I can go and go through a code and try to troubleshoot that particular page, right? And create an immediate help. The other problem is once you get this information, you go down the rabbit hole and then you have to troubleshoot the page, but that's a different problem. All right, so troubleshooting is a required skill, right? I think we'll agree on this. I think, I hope we'll agree on this because otherwise we're in trouble. It is educational. You learn a lot of things as you troubleshoot systems. A lot. Make sure that it's iterative, right? You can fix everything at the same time, but you can make continuous improvements to the system. It is extremely frustrating. Every time you have to troubleshoot something like any of the examples, it is annoying. But it is also extremely rewarding, right? Because hopefully rewarding because at the end of it, you can say, hey, I solved the problem in a real creative way. All right, that is all for me. Hopefully it was helpful. Thank you. I'm really intrigued by that CPU per URL example. Can you talk a little more about that? I can. It's a DTray script that basically attaches to the probe. We were running it on Illuma's base systems. So it had a full DTray support. So it actually has a code on the slides. I'll publish the slides and it's got a GitHub link. It attaches to basically a little script that attaches to the HTTP processes. It pulls out all the information. They can process it out and show it in a digestible format. It's real simple, actually. It's pretty awesome. Are there such things as design patterns for debugging? So things that might be common from case to case to case that you find you can reuse? I guess the short answer is no, because you never know what the problem is. I think there are best practices, right? What to do, some of the things that I talked about. Yeah, I mean, general things I just talked about basically validate, replicate, isolate and then try to fix it. And when you get to the part of trying to fix it, it's gonna be different every time, right? Because it's troubleshooter. You can never estimate it, you can never predict it, you don't know what it's gonna be, right? Up to the point where, like I said, up to the point where I knew it's a CPU problem, it was all, you can outline what needs to be done, right? Once we get to the point where a CPU problem coming from a patch, then it was anybody's game, right? Because you gotta get much deeper to figure out what it is. You were mentioning do not give up when you're troubleshooting and I wonder, when is a good time to give up and say, oh well, we have the next version coming or this might be fixed in a week. Do you look at the business or do you look at the software? So those are actually two different questions, right? Questions whether you can look at it in a week or you can look at it in the morning should be asked regardless, right? Because there is a whole conversation about alerting or cementoring, right? So you should never alert on something that you don't have an actionable response for immediately, right? Because if you're walking up in the middle of the night and you can't do anything about it, why did you get it walking up in the middle of the night? Question is whether you can fix later or whether you can pass it on to somebody. Generally, it's a business decision, right?  What that solution would be is depending on your business needs, right? So if you're a media site, for example, right? What I talked about is showing stale content acceptable solution in a short term, right? Well, it fixes some nails. And maybe the answer is yes, right? Then you bring up the older content somehow and then try to figure out what's wrong with it. Maybe the answer is no. If the answer is no, then again, you try to fix it as soon as possible but when you realize it's gonna take you, let's say, hours, if not days, then you go back to the business and say, you don't have an option, right? So here's the options B, C, and D that you can choose from. There is no more A kind of thing. Yeah, so it's case-based case but it does base on the business, right? It does base on the business. And like I said, sometimes fixing is breaking, right? Sometimes you need to break something or disable portion of the functionality which is actually really common, right? It's a particular piece of functionality breaks everything. It's, at least in my experience, it was very common to just turn it off, right? And that functionality can be critical sometimes, like it could be ads. It can be like CTAs on the page that show you all the immediate content, right? It can be login, right? So many sites nowadays, even when they do maintenance, they turn off anything right related, like logins. So it depends on the situation but it should come from the business side of things. Yeah, so the question is this, when do you make a decision what's acceptable risk and what's acceptable norm when you're troubleshooting? So when do you decide that you incremental and prove it enough that it's acceptable versus getting back to the base optimized line? It actually, again, goes back to the previous question, it is based on business, right? It is in business acceptable risk and whatnot. Yeah, so ideally you have those defined before that. Ideally you understand business enough enough to either make the determination or have somebody from business to make the determination for you. Basically, I'll lay out the options and saying, hey, we brought it down to an acceptable level, like, page doesn't come out for your customers anymore. It does low, slow, some images don't load, for example, but it does low for your customers, right? We now brought it to stable state. To get it to 100% stable state, because of X, Y, and Z, it will take us probably 24 hours. I need my people to go to sleep now because otherwise it's gonna be 48 hours because nobody works better without sleep and present those arguments. Ideally, though, you have enough information about the business to make a lot of those decisions. I mean, obviously not all of them, so you can make a decision what's more impactful turning off ads and turning off content unless you know it, right? So some of those decisions have to be made by business, but some of the decisions may be purely technical, right? I mean, if you see database load or CPU load at 80%, it's probably wrong. If you can get it down to like 65-ish, and do you think it can survive through the morning? Like technically, right? And if the answer is yes, you can call it a night, get some sleep, and try to fix it in the morning, that kind of thing. So in that example, when I showed the CPU stuff, right? If I fixed the biggest offender, which was like a factor of 100 over the norm, right? If I fixed that, would it bring down the CPU consumption to a level where it might not be the best, right? It might not be what it was before, but it'll be to the level where the pages would not time out or not take 12 seconds to load. And if the answer is yes, then I was like, fine. I can go through the rest of the pages and optimize them tomorrow, the next week, whenever over the next week, I get them done. So it depends what the problem was. My question is this, you've done a really great job about talking about troubleshooting as an individual, things that can contribute to an individual being more efficient, more effective, ways to do logging that would make it easy for an individual. Can you speak a little bit about what can be done around team troubleshooting?  What are effective things you can do as a team to improve your troubleshooting? So actually the same concept supply, actually when you work with a team, like as long as you don't whine, like I talked about, generally when I troubleshoot with the team, I try to distribute the areas of search, right? So if we have different skill sets, it also depends on the skill sets of a team, right? So if I troubleshoot, I have development background, so I'm mostly comfortable troubleshooting on top to bottom, not bottom to top. So if I'm working with somebody from operation site or heavy operations site, I'll have research the CPU stuff while I look at the code. If I'm working with somebody with the same similar skill set or a group of people similar of skill set, I will try to distribute the areas. So say I think we have a problem, potential vectors of problem in these three areas, let's investigate our own, but continues to communicate, right? Chat, sit in the same room, whatever that be, continues to communicate because every time somebody finds something, it may impact what other people are doing. So that continuous communication really helps.  Because when you see this and somebody said, hey, it is something that impacts you and you look at it and you say, oh, it just improved by 20%. I'm not really sure what you did, but thank you, like kind of thing. So yeah, I mean, it's pretty standard things, like nothing extraordinary that I can recommend. They just talk to each other, be nice to each other. Awesome, Leon, thanks so much, this was great.


We are Gerald Care, and we are transforming healthcare delivery in Africa, beginning with elderly care and beginning in Nigeria. So why elderly care? There's an absence of a structure for medical care for the elderly in Africa. And Gerald Care is using technology to provide that structure and make it possible for Nigerians wherever they are in the world to subscribe for regular doctor visits for their parents in Nigeria in the comfort of their homes using the Gerald Care application. They simply download the application, input their parents' details, and make a payment. Immediately, they are matched to a doctor who leaves close by, who begins to visit them at home at least once a month, and give us the children regular updates wherever we are in the world. We can pay for tests and drugs on our app and deliver to the parents at home. Our focus is the third SDG goal, healthy living and well-being for all ages, and in particular, in our case, for the elderly, especially because they have been neglected either too. The reason why we started this business was because a few years ago, in the space of one year, my father had two strokes. However, as is the case for millions out there, all this could have been avoided if they had a medical professional like myself closely monitoring their health. And so my co-founders and I created Gerald Care to solve this problem for my father and the millions of Africans across the continent experiencing the same thing. We are glad to say that so far we have over 1,200 subscriptions. In the next two years, we expect that number to hit when 5,000, and in five years 100,000 by maximizing our strategic partnerships. We will measure the efficacy by the increase in life expectancy of the Gerald Care patients. We have three offices in Nigeria, over 1,000 subscriptions, three enterprise partnerships, and 750 doctors, over 800 pharmacists across 45 cities. We make money in three ways, our individual plan with monthly client subscriptions, our enterprise plan with partnerships with organizations and commissions of every other service assessed via our platform. Yes, we have a great product, but we also have a great team led by myself. I've been a medical doctor for the past 16 years. I have a master's in business for which I graduated with a distinction. Our COO is a neuroscientist, is a healthcare marketing expert, and he has a PhD. Our CTO has been building software for the past 19 years, and we all strongly believe that the Gerald Care model is the future of primary healthcare, not just in Nigeria, but all across Africa, conversing every home to a primary healthcare center. We are well on our way to achieving this, but to get there much faster, we're looking to raise $300,000 as equity, depth, or both. So remember, we are a great team providing a scalable solution to oppressing need and making a huge social impact. So we implore you to join us as we will define healthcare across Africa forever. Thank you very much. Love your passion.  Do you think that may have some issues with, you know, people using your service because you're getting, you know, money paid for additional things? Okay, so what we actually do is aggregate everything the elderly patient needs. So we're the one stop shop for elderly care no matter what they need. So we have pharmacies, consumables, physiotherapies, every service you access, they are a platform because to provide it to you at home, we get a service charge for that. So that's the commission.  So it's basically the service charge that is the commission. Fantastic energy. Thank you. Any identified risk, threats or obstacles that you have right now that are preventing you from implementing? Obviously, you've got impact in your services, but can you just explain a little bit more what, where you stand with obstacles? So the key challenge we face is the issue of trust because we're a new company and our subscribers most times are outside the country and they have to input their parents' home address. So it begins to wonder, I don't know who these guys are. Is this safe enough for me to provide my parents' address? So usually there's a drop-off there. We have to now call and convince them that we are real for them to finally finish the process. But we envisage that if we can create enough brand awareness such that they already know who we are before they get to our platform, it's to make it easier for them to go through that stage. The second is the issue of customer education in the sense that most science people focus on curative and episodic care rather than preventive. We are focused more on preventive because we catch conditions while they're quite early. We visit them every month. So what would be an emergency in two months or three months, we catch it at an early stage. So they need to understand that those their parents are fine right now. This is the best time to still subscribe to Gerald Care.


you guys now will face the Knicks in the first round was there multiple conversations how we want to get this win to play to match up with the next you confident that next and was it more that or was it more to avoid the Boston Celtics in the first round to make this game so important last night I feel like we know smoke but yeah we wanted to match up of course that's the easier team I guess but you know it's gonna be fun you know we've met your pretty well with them they got a great guard we got a great guard we also got Joe you know MVP so you know like you said earlier he's one of the most unstoppable guys in there in the league right now so we have to send triple teams and he's gonna get everybody else involved I'm sure yeah I mean they got three out of four against you guys this year but Joel only played one of those games so now with him back playing 38 minutes last night you guys got to be confident right fully loaded oh yeah we're definitely confident you know I feel like that we could be any team in the league with I'll be really healthy for sure


What's good Josh, you're both back here again with another video. So we're gonna check out WWE top 20 emotional moments in history There's those few times where Like I Don't know how to say it. I wouldn't say breaking character like maybe the wrestler break character But something you can see the real person there You you don't see the character of like the version of themselves that they're playing you see the real person You see the real emotions and those moments be some of the best pure moments to see Sometimes it's you know to you know, maybe create a feud or sometimes Something serious happened and they want to just talk to us as a person as a human being not the character and It is it creates some memorable emotional and powerful moments So we're gonna check this out. Appreciate our love and support Road to 70k and let's get right to this one Yeah Eddie Guerrero, I really hope you are addicted about three years ago Oh in Minneapolis, Minnesota, but in the shower in the locker room. Oh, man I was high bro. They carried me out of that arena and they carried me straight into rehab They didn't do that. I did that to myself. I lost my wife. I lost my kids and I lost Myself I disgrace my race. I disgrace my family.  You know what I said I did Because I'm here right now By the grace of God Eddie fantastic. They want it. I'm gonna give them a better education That's my way of telling my family. I'm sorry I Just wish his title run was better But that's really what it was. It was very Underwhelming a lot of you have said and I do agree But at the time he did deserve it and I was hoping they were gonna You know saying at least give him something better to really represent You know the dub as the WWE champion, you know, and I appreciate what they did with Paul him and try to hype him up And really give him that that that extra push as a legitimate champion But ultimately once again if WWE does not book you correctly It doesn't matter, you know saying, you know, the original hype of you becoming a champion What matters in the title championship reign is really the booking How they book you the storytelling the matches you have that's what people will remember, you know saying so And one incredible friend above That's the piece This was a sad moment too. I watched this lie Man Such a sad moment Getting that kind of reaction from all of you people Ah, this gets me I get to share that with them. I get to share it with you. I get to share it with my wife in the back. I am Grateful That was a fantastic promo bruh when he had to retire from wrestling Watching it live bruh Definitely almost teared up. It was one of the most powerful moments is He was trying to keep it together cuz he knew you know saying he couldn't compete, you know saying anymore WWE wasn't gonna let him compete anymore, but ultimately he was able to he was able to find a way and and now Look at him now AEW. I love it Have a mission just even now in the future. Thank you all This is great This is great to their series of matches was fantastic Inducing ECW was a different He's getting the motion Like they ECW fans have always Showed that This was so I watched this live and it is so crazy how life works He's gone full circle and he's back in putting on some of the best work.  There's one person That would like to see to have one more run with the trap trap with the strap the WWE Championship Maybe the Universal Championship I would love to see edge get one more run with it I Don't think anyone don't think a lot of people will complain with that just one more run if possible if not that's fine But I would love to see it. Maybe one day. Hopefully. I don't know. We'll see If you ask me if I do it again In a heartbeat Well, thank you. Thank you very much That's much the pain that you receive from the ring but the pain that you've shared with your family And that person for me was diamond Dallas page. Hmm. I Didn't care anymore, man. I was doing drugs every day alcohol every day. I don't want to live right there Bring it bring him up here 20 years of WrestleMania 50 this kid will be there Thank you for letting me play the game. He sold that promo to he sold that promo to man That was a cool moment too. No, this is giving me good feels racing piece 80 man It was so great K2 Express show your expression. Oh Man What's going through your head? No, you're just as disappointed and they chant Sid's name or they chant Brett's name and they chant a lot of people's name time where toughness is real big here in Well-resting Federation. I don't have any toughness for anybody is go back home and See what's left for me and I have to go back and I have to find my smile because somewhere along the line I lost it. Well, you like me or not the infamous. I lost my smile He stepped away for a while. He did I just want to tell you that last year was the most wonderful year of my life as being the number one guy in this business I'm gonna go home now. Okay In Kansas City have a two-hour tribute to the life of Owen Hart I said I'd be a fighting champion. I said that was a sad moment as well in his in wrestling history Mainly because of just you know that whole situation him You know Passing away in that way at the show, you know, pretty much, you know, you know, he you know later was pronounced Dead at the hospital, but it's just you know, you don't expect that you don't think that's gonna happen at WWV event, you know saying so yeah, it's just just one of those type of things where you just you know sit up there and you know Yeah So yeah Consistent and I said I was gonna be a workhorse, but that's all lies And I've been living with leukemia for 11 years and I'm gonna have to relinquish the Universal Championship When I was 22 years old I was diagnosed with this I didn't have any money I didn't have a home and I had a baby on the way and football was done with me team that gave me a chance Was the WWE? This was a pretty powerful moment as well watched it live And one of it was one of the few times he actually got a real reaction One of the very few times The kids Shawn Michaels has left the building Man This this whole segment was really good by Mark Henry. He really sold this I Believed every word he said and then him switching like that was fantastic Easy one of the best almost You believe just like John Cena and them people believe I had y'all fool y'all a bunch of puppets So tonight we celebrate the life of Eddie Guerrero As we told the bell ten times after which there'll be a and you can bro Look it. Look at Chris Benoit. He's hurting. That was someone really his best friend someone real close to me Bro, he was never the same after that. He wasn't he just there wasn't there was You know, I wish he would have got to help you You know, he needed because he was never really the same was a he was gone. He wasn't the same special video presentation In this ring again, if you think that the millions of people This was a powerful moment to Retired Such a powerful moment and this right here a lot of people thought He was done Once he like left his gloves and stuff in the ring, I was like, oh, he's done and then he ended up coming back You know, we thought he was done But it was still a powerful moment and sometimes wrestling you have these powerful impactful moments that you'll never forget It will always you'll hold dear and you know, sometimes it's not about what's happening You know the characters and it's about the the individual person themselves. That's playing that character You know saying showing themselves to us as real people because they are you know saying they have real emotions They go through real, you know, real things that mean you go through it each and every day So comment down below. Let me know what was the most emotional part of this video that really touched you the most It'll always be there Eddie Guerrero one that that hits that hits man that that one is very very impactful and You know how, you know, it just it just sucked, you know It really was unfortunate that we lost them a great person fantastic wrestler Another one that stands up there is the Daniel Bryan one. That one was really impactful as well But appreciate all of us for row two Sam, you can't appreciate y'all keep with me. See y'all next


Hi, I'm Pastor Chuck from East Earl, Pennsylvania, and you're watching Trucker Josh on TJV. Good morning everybody. Excuse that bug that's pretty much right in front of the camera there. I've got to go deliver these tanks. There's my crane just over there on the left. How do I get into this work site? Right where that gravel truck's coming out. So we've probably just stayed across the street. I have an 8 o'clock unload appointment. The crane is there. Now I'm going to be there. It looks like they just finished unloading the guy before me. That's perfect. So whenever you come and fuel up at this loves here on I-94 and Russell Road, just at the Wisconsin border with Illinois, South of Milwaukee, think of me, I delivered one of these tanks. I guess we'll wait here for them to tell me where to go. As soon as I get here, it's busy, busy, busy. Or maybe it was busy all along and I just happened to slip in just at the right time. I'm going to go over there and ask those guys where they'd like me. So this guy's pulling out. This guy on the right here is going somewhere with his little scoop. I'm going to give this guy a little more room with his trailer. There we go. He's telling me I drive in and then I go the U-turn back of the site somewhere. I guess we'll find out when we get there. So this was the tank that was delivered by the other guy before me. Never met him before. Super dusty and my engine fan just kicked on for these guys to lift the whole cloud of dust. How am I going to turn around here? Unloaded them here. So this will be the loves travel stop like I've been telling you. I think it's called Russell. It's on Russell Road right at the border with Wisconsin. If you guys ever come here once it's finished, that's going to be the scale right there behind these tanks. The tanks that I delivered here are the water and oil separator. So when you're at the diesel fuel islands, there's always that drain on the ground, right? Where all the excess, the runoff goes into. All that runoff goes into these tanks which separate the oil from the water. And then let the oil back into the ground and then keeps the, I mean pardon me, let's the water back into the ground and keeps the oil in that small tank right there. I don't know what I'm talking about. Still too early. I think my job's done here so now we head over to Evansville, Wisconsin and begin the next job. Pretty cool. I can't wait to see what this looks like once it's finished. Let's see if I can figure out how to get out of here now. I think that truck is leaving right now. So I'll be able to just go out after him. Yeah, there he goes. Take it. That makes it easier. Go back across the street, grab a coffee and check the trailer over, make sure that this load didn't do anything to the trailer, which I doubt it did, but just to double check, you know. It's such a dusty, dusty yard. They're almost using sand. All right. So we're here tying down our next load. Now I've got all the straps thrown over and put through already. It's really nice that this place where we're picking up here, they put ropes through there so that it's easy for you to, you tied the strap to one end and you pull it through because I'm not allowed to get up on the trailer here at any time. They have ladders and stuff I can use if I need to. You see I got all these straps on the load. Go through there, up and over there. And now I make sure that all of these straps have a ratchet. These slide, right? I've got to make sure that everyone has a ratchet that needs one all the way along the trailer. Otherwise I've got to undo them later because once you like on this side of the strap here, like here, this side here, you can see that this hooks into the bottom of the trailer. Right there, you see? Like that. So once that's hooked in, it blocks the slide rail here and you can't slide the ratchets past anymore. So you got to make sure all the ratchets are in the proper place right away. So now I'm going to wind them all up. I got to put corner guards on all of the corners because you don't want this steel to eat through your straps. That'll happen very quickly if you're not careful. So what I do to reach all the way up there, to put my corner guards up there, this ladder right here that they provide, not allowed to get up on the trailer at all. So yeah, that's what I'm dealing with right now. I'm just going to tighten it all up. And this load's going up to Alberta. I'm the guy to bring it. Somebody's building something up there. I'm kind of vital to their building plans. It makes me feel important. Not going to build your building without Trucker Josh bringing you your stuff. And that's the finished product. That took a little while and a lot of energy, but we got it done. This load is not going anywhere. I've got my tarps back here all tied down as well. Let's hit the road. Oh my. First things first, we've got to go find somewhere to take a shower. Uh-huh.   We've got to go find a shower. First pilot flying, Jay, that we go past. We're going to stop in and grab some fuel and a nice cool shower. Not cold. That's too much. Too extreme. Just cool. A nice cool shower. Oh, man. Okay. See, I'm going to paperwork here. I've got to go back to the guard track and let them know that I'm done here. And we can give her on down the road. With the AC blasting, it's a hot one today. Let me see how hot it is outside. It says it's 25 Celsius, so that's actually not that hot. Probably like 80 Fahrenheit. Feels hot. Sure feels hot. So, uh, 1,210 kilometers from this exact spot to our yard back in Manitoba. I'm going to get there tomorrow afternoon. Friday, midday or so. Around noon. I'm going to head on out to, uh, that... Okay, I didn't even see you coming there, buddy. I am doing the speed limit. Oh, they say Saturday we're going to head out to Fort McMurray. We'll get there Sunday night. Unload Monday morning. It says that I could deliver Monday or Tuesday. I'm going to have to make sure that my appointment time is Monday morning because, uh, I want to pack in as much work as I can this month yet. Our roof is getting redone, uh, next week, I believe. Yeah, it's almost next week already, yep. Woo! Finally. So that'll be done. That'll be our biggest summer project that's done. And all I've got to do is rip down the rest of that lean tube beside our garage. And then all of my summer goals, summer projects for this year are done. I had three projects, three goals for the summer. One was to get the roof done on the house. The other was to sell the freight liner. The third is that lean tube. That's good. And then this winter time, our goal is going to be to probably start renovating our master bedroom. We're doing as much as we can inside. And then, uh, doing all the piping and stuff underneath there while it's still kind of cool under there. And then next spring, we'll finish it up. And we'll have a new master bedroom for next summer. Unless the plan's changed, but that's the plan right, that's the plan right now. All's Wisconsin. I'm actually not going to fuel up here. I'm going to wait till I'm a little closer to home. I still got over half a tank. I'll fuel tomorrow. I'm going to run in here and have a shower. You know what? Maybe I should fuel. Maybe I should fuel. No. No. Not going to fuel tomorrow. Going to fuel tomorrow. Already made up my mind. Can't change my mind now. Made up my mind. Going to fuel tomorrow. So we're just going to go find a parking spot somewhere around here as close as we can. And quickly run in there. I still want to get a couple of hours down the road. I have four and a half hours available to me to drive today yet. So I'm Karen. Karen. Karen. Karen.  Let's not damage that relationship. What do you want now? Ding dong to you too. Is that sort of like your way of whistling at me? I'm married. Back off, Karen. What's this guy doing? Why did he like nose dive into those trailers? What are you... Okay, so that big open space. You think you can squeeze her in there, bud? You got about six open spaces. Do you think you can make it? Don't go too fast now. Don't go too fast. That's six empty spaces. That's quite a tight spot. I'm not trying to be rude or anything. But you know, I'm looking into hiring drivers in the future to drive some trucks for me, right? Not under my own running rights yet, but just to drive some trucks that I own.  You know, I'm not just going to hire any guy off the street with a CDL because you know, some of these guys seem to get their CDLs in a cereal box and I'm going to have to make sure that whoever I hire didn't get their CDL out of a box of Cheerios. Maybe it'll be one of you. I trust you guys. You guys are good drivers, aren't you?  There's a lot of companies out there who won't give drivers a shot. Won't give them a chance. And I don't think that's fair. I mean, for me too, I had to do five years of local before I got on to a bigger truck over the road to gain experience because no one wants to hire someone with no experience. But I guess what I'm trying to say is I want to hire people with common sense and good hand-eye coordination, good motor skills, good backing skills, someone that I'm going to trust not to wreck my truck because a truck like this has, I have a $5,000 deductible on these trucks. It's a pretty high deductible. We could probably get that down to $2,000. But let's say even on the good end, a $2,000 deductible.  Maybe it needs a new hood and new mirror. And let's say it easily adds up to $10,000, $15,000 of damage. Well, that driver gets to go home and wait for the truck to be fixed. I'm stuck with the deductible. I got to pay that $2,000 to $5,000 deductible because my driver wrecked my truck. So it's a risk. That's the risk I take in hiring someone. I have to trust that they're not going to wreck my truck. Not only do I want them to take care of the truck so it lasts a long time, that they keep it maintained, that they treat it well, that they don't abuse it, that they run it nice, that they don't gun it everywhere they go. That I want my trucks to last a long time. I also got to make sure that they're not going to back into somebody because in a parking lot, if they back into a truck and completely tear off their hood, well, it's about a $10,000 somewhere around there. It could be $10,000 of damage. Again, $2,000 to $5,000 out of my personal pocket. So that's why I say like I've got... I can totally understand why companies are picky. They want drivers they can trust. And it's hard to build that trust when you have no experience. I understand that, but that's my biggest fear, you know?  I'm going to start off with just a few trucks running it. Like, not under my own running rights, like I said, but I have a few trucks running and it's a risk I'm going to have to deal with and there's a level that I sort of got to be comfortable with stomaching, level of risk. Because it can go downhill in a hurry if you put the wrong guy behind the wheel or the wrong woman. Anybody can have accidents. Equal opportunity. So I don't know.  If I do nothing, I will not be successful. But if I take a risk, I have a chance of being successful and building my business up to the point where, you know, maybe one day I can sit at home and there's other people running my trucks for me and I can spend my time with my kids, maybe my grandkids at that time. Maybe I can be doing a different business at home at the time when my trucks are running. That's the overall goal. But in order to get to that goal, you got to take a lot of risk. Got to take a lot of risk. That's why I don't like all these, like, people who get jealous of people who are successful. I'm like, you know, I don't know how many times that person failed before they got that successful. Don't try to tear them down. Let them enjoy their success. Let them enjoy their yacht and their big summer home down in Florida and, you know, all this stuff. All this stuff they have that people get jealous of. It's easy to be jealous of them. You know what? Who knows how many times they failed before they got to that success and who knows how much risk they had to take to build that up. You know, it could all come crumbling down in a month. You know, you know what I'm talking about. Most of you know what I'm talking about. I'm just preaching to the choir here, aren't I?  I'm going to leave you guys in here, though, if you don't mind. I like my privacy when I shower. It's not that kind of YouTube channel. This is a family-friendly YouTube channel. That truck is really tailgating that SUV up there. Wow. I don't know why people do that, you know? It's right on his bumper. I get you want to go two miles an hour faster, but really you're going to put everybody's life at risk.  The four-wheeler should be moving over to the right because he's... Obviously the truck wants to go faster than him, but wow, I hope. I hope nothing happens with that. So we're here in Minneapolis in St. Paul. I don't know if the truck's going to go around on the right. Okay. Why don't people move over? You know what? So often I see that too. Like I run slower than most traffic. I'm governing stuff. I do it for fuel economy as well. And when I see a vehicle pass me with like a long line up behind them, it frustrates me when they don't turn back over into the right lane, you know? They just sit in the left lane with that...  If they won't move over, they'll force everybody to pass them on the right, go around on the right. People are beyond me, you know? It's like they don't think. Or they just don't care. One of the two. So I want to get through the city. I was thinking of stopping on... Oh, there's a cop over there. Uh-oh, somebody's getting a spanking. Somebody's getting a spanking. Bad boy. Bad, bad. Maybe it's a girl. I was going to stop on the... on the east side of Minneapolis, St. Paul, in Wisconsin. But I figure, you know what? Traffic will be lighter now, going through the city than in the morning. So, let's get through the city. This is a pretty big city to get through. A lot of traffic, especially in the morning during rush hour. Sail through the city tonight. And then I don't have to worry about that tomorrow. Two kilometers. Came to the right on I-694 U.S. 10 West. Thanks, Karen. I don't think I'll get lost going through here. This is my home stretch. I can do this with my eyes closed. I'm not going to demonstrate. Don't worry. But I can probably get home from here with my eyes closed. Just saying. That's Petro off to the right there. Clearwater, Minnesota. So we're going to call home for tonight. Hopefully they got parking here for me. But I have a feeling it's going to be packed. If it is, I have an extra hour on my clock that I can get to the next nearest place. But I really hope I can park here. I really like this truck stop. Clearwater Travel Plaza. It's a Petro. Not a Petro Canada. It's a Petro Stopping Center. It's a U.S. company. They got awesome truck stop here. Everything you need. It's almost like a little mini trucker mall. Almost. Not quite like the Iowa 80. The Iowa 80 is sort of a beast of its own. Apparently it's the world's largest truck stop. The world's largest. There's no bigger ones anywhere. Karen.  You know what would be cool if Karen could tell me where the parking spot was. Why can't you do that, Karen? In this place. I don't even know where to begin looking. Where to begin. Well, we found a parking spot but it was on the street behind the truck stop. But it worked. No one told us to move. There's no parking signs or fire items or anything. That was our night. Right, Chevy?  So tomorrow we go home. You ready to go home? You want to go home? Oh boy. Oh boy. Let's do it, man. Thanks for watching today, everybody. Tune in tomorrow for another vlog. Don't forget to share my videos because YouTube doesn't like to recommend them like they used to. So if you think that YouTube should recommend my videos to other people to watch you'll have to recommend them for me. Don't forget to share, like and subscribe. Talk to you tomorrow. My name is Ethan and I'm from sunny central Florida. You're watching Trucker Josh and Diesel on the best channel on YouTube. TJV. Enjoy.


Good afternoon, everyone. It's a pleasure to talk to you today about risk assessment to advance brain health and dementia prevention. So I'm going to start off our talk with a few stats, and I hope this slide's not too heavy for everybody. But I wanted to point out in those figures on the left of the slide that dementia in late life, this is in people over the age of 60, increases quite dramatically with age. So every five years approximately it doubles. And it becomes really highly prevalent in people over 80. So people in their 80s and 90s make up the bulk of the group of people who have late life dementia. And what's important here is that overall we don't see, in the meta-analyses, when you sort of merge all the data globally, we don't see sex differences. But when we look at Alzheimer's disease, we find that is more prevalent in women than men. So we do see more dementia in the over 90s in women, and that's because women live longer than men. But apart from that averaging everything out, it's roughly the same except for Alzheimer's disease. There are particular population groups and demographics where we see higher rates of dementia. And that's often related to different risk profiles. And in Australia we have very high rates of dementia in the studies that have been conducted on First Nations Australians. So approximately three times the expected rate of dementia. And we think that is probably due to a different risk profile. I mean there's been a number of areas of disadvantage that compound to impact brain health. Lower rates of education, poorer control of metabolic disorders and diabetes and so forth. And high rates of head trauma. The distribution of the types of dementia that we see in First Nations peoples is fairly similar to what you see in all of the other studies. So it's still Alzheimer's disease is the most prevalent cause of dementia in nearly all populations except possibly some countries in Asia where some literature has suggested that vascular dementia is more prevalent. So I just want to talk to you about the risk factors for dementia. We have both non-modifiable risk factors and modifiable risk factors that we can look at in our research. And in the non-modifiable risk factors it's mostly things like the country you're born in, genetics, sex at birth, ethnicity and so forth. And then the modifiable risk factors we divide into two categories. There's the ones that occur at the individual level. So things like your actual, your BMI, whether or not you're physically active and live in a healthy lifestyle. And then there's factors that we think occur at the policy or social level and they may be the social determinants of health, things like air pollution as well and education levels. I'm just going to talk very briefly about genetics and then I'm going to move on to modifiable risk factors after this slide. So first of all, there is one main genetic risk factor for dementia and that's a risk factor specifically for Alzheimer's disease. It's called the apolipoprotein E4LL. It's actually really common. So people often don't realise that one in four of us carry this and that increases your risk of Alzheimer's disease by three times. That's late life Alzheimer's. We're talking about not Alzheimer's in younger adults. If you have two copies, it increases your risk by five to eight times. Now, what's really interesting though is that this is neither necessary nor sufficient for you to develop Alzheimer's disease. In our cohort study we run, we've been running for over 20 years called the Path Through Life Project. We've got people in that study who are homozygous, things that have two copies of the E4LL and they're not declining cognitively. They're actually quite resilient. So there's a number of other things that are going on and so this has led researchers to put a lot of energy into looking at what is causing neurodegeneration and dementia in addition to the genetic risk factors and those non-modifiable risk factors. So the rest of my talk is actually going to focus on the modifiable risk factors. So first of all, what happens if you have the genetic risk factor? I mean how important is lifestyle? Can you still do something? The answer is yes. So we've looked at this in the Australian data in our Path Through Life cohort and we found that the genetic risk for Alzheimer's disease was independent of lifestyle and medical risk factors. And in this big study which is shown on the slide here was a meta-analysis where they reviewed the literature to look at lifestyle factors versus genetic risk for Alzheimer's. They again found that they're independent. They're both significant predictors of Alzheimer's disease but they had an independent contribution. And people who had the genetic risk, who had a healthier lifestyle, that reduced their overall risk. So it was still beneficial to undertake lifestyle change even if you have the genetic risk. So how much, you know, the next question might be how much can you modify your risk of dementia? Well at the individual level for one particular person it's impossible to say if you do everything, all of these things you will not develop dementia or Alzheimer's disease or vascular dementia. It's a bit like smoking and lung cancer where some people develop lung cancer and they've never smoked. But we know at the population level on average if everybody adopted healthy lifestyle and treated their medical conditions and we could address social determinants of health we could make a big impact on dementia. So the Lancet Commission in 2020 conducted a big data synthesis and did a lot of statistical modelling to try to work out how much of dementia could be attributable to some of the key risk factors. And they concluded that about 40% of dementia globally is attributable to modifiable risk factors, which is actually quite a big amount. And then individual countries and researchers, you know, they've looked at the population attributable risk in their country or in their population subgroup within a country. And often they've found an even higher proportion of cases of dementia could be attributable to modifiable risk factors. So the risk factors that the Lancet Commission focus on, there's 12, they're shown on the slide and I'm just going to run through them. They take a life course approach so they argue that in early life low education is a significant risk factor. Now if you look at that slide it says the risk factor prevalence is 40%. Now that's because globally low education is quite prevalent. So 40% of the world's population whereas in Australia low levels of education. So not say just finishing a primary school not going beyond that. It's actually quite much lower. So we don't have, you know, this obviously we have a different pattern of risk exposure in Australia. We have higher rates of some of the risk factors though. In middle age the risk factors identified by the Lancet Commission included hearing loss, traumatic brain injury, hypertension, alcohol, heavy alcohol consumption. So more than three drinks a day. Obesity in middle age, they're all in midlife. And in late life they've identified smoking, depression, social isolation, physical inactivity, diabetes and air pollution. Now this is in a really important list but it's not the only authority on these risk factors. There has been a lot of work done even since 2020 on risk factors for brain health and dementia. And there are also some other sources of information. So there's actually quite a few more risk factors that are included on this slide. So for example the World Health Organization published its guidelines on risk reduction for cognitive decline and dementia in 2019. And it included high cholesterol in midlife and makes recommendations about management of high cholesterol. And since then and since the Lancet Commission there's been more systematic reviews published on high cholesterol. And it seems quite conclusive that high cholesterol in middle age is a risk factor and should be treated. The other really important risk factor which is not included in the Lancet Commission report here but we think is very important. There's a lot of evidence for it and that's a poor diet. So there's really been a lot of research looking at dietary patterns and just brain health generally. So in populations we're not looking at people who've been diagnosed necessarily with any neurological condition. If we just look at a population study, most studies are finding an association between healthier diet and less cognitive decline longitudinally. So we see that over and over again and we see in the meta-analysis a protective effect of the mind diet. And particularly the type of mind diet that's emphasises neuro-protective properties which includes green leafy vegetables every day and blueberries. I wanted to talk a bit about the medical risk factors. So we talk a lot about lifestyle and I think there's probably less known about some of the medical risk factors for Alzheimer's disease and dementia. Now this information is mostly taken from observational studies so the diagnosis of those outcomes is not high tech. They don't have usually pet imaging, they don't have blood biomarkers, it's a clinical diagnosis. And there's often a lot of mixed dementia in these studies and often the outcome is just all cause dementia. And these are studies where they follow people into old age. So we're talking mostly about factors that have been shown to impact late life dementia. And of course some of these risk factors are also linked to brain health generally and to neurological conditions at younger ages. Now the medical conditions, the main ones are diabetes, heart disease, depression, stroke, kidney disease, hypertension in middle age specifically not in late life, obesity in middle age, not in late life, head injury and then there's quite a bit of research looking at medications and whether or not they're protective. That's almost like a whole talk in itself and then there's also been looking at some infections as well. I'm just going to look at a few of these medical risk factors, we don't have time to go into all of them but I thought I'd just show you some of the findings on some of the key ones. So diabetes has been very well studied and the findings in relation to diabetes are fairly robust. Mostly they show that people with type 2 diabetes have an increased risk of cognitive decline and are more likely to experience decline in executive function to develop cognitive impairment and dementia. But the effect is more for vascular dementia than Alzheimer's disease and actually a number of the autopsy studies don't find any more Alzheimer's pathology in people with diabetes than without. So it really seems to be the vascular changes that occur with diabetes that's increasing the risk. Now if you move to heart disease, most types of heart disease have been associated with an increased risk of all cause dementia in late life. In particular atrial fibrillation has been shown in a number of systematic reviews to increase the risk. But other studies have found associations with more general heart disease, heart failure and so forth. Blood pressure is something that, high blood pressure is very common, we all have our blood pressure tested every time we go to the GP or regularly. And high blood pressure in midlife has been associated with an increased risk of cognitive decline and dementia. The thing is it's been difficult to find the association with Alzheimer's disease and most of the effect has been with vascular dementia and it's mostly been in middle aged people. It's less clear how hypertension affects the brain in later lives and that is an area of ongoing research. I've seen very, very recent work looking at things like changes in blood pressure, variability in blood pressure. But we know definitely that high blood pressure in middle age is a significant risk. The good news is that treating high blood pressure does reduce that risk and it doesn't seem to matter which type of medication is used. And people who have hypertension who are then treated with antihypertensives and bring their blood pressure down, that does seem to reduce their risk. Now obesity is another quite an interesting risk factor because it's middle aged obesity that seems to increase the risk of late life dementia specifically. But when people are overweight in later life, so 65 and older, that doesn't seem to be associated with an increased risk. So we don't understand the mechanism underpinning the association. There's a number of theories that it has been observed over and over again. And another medical respect which I think is not widely understood or known about often is depression. So depression has been linked to an increased risk of late life dementia. And initially this was thought to be what we call reverse causation. So it was thought that it was noticed that as people start to have cognitive difficulties in their daily life, they often withdraw and their mood is affected. And there's some common causal pathways underpinning mood and affect and mood disorders and cognitive decline. So it was thought that the link between the two was really it was all just caused by a single process. And that it wasn't that depression was causing it was causally related to cognitive decline. Since then there have been a lot of long term studies where they've been able to look at people who were depressed way before they would show cognitive decline. So middle aged adults and they have shown that people who have a history of major depression do have a long term increased risk of dementia in late life. So I'm just going to really talk briefly about the lifestyle and environmental risk factors because we've spent more time on the medical risk factors today. The lifestyle risk factors cover things like diet, physical activity, smoking, heavy alcohol consumption, sleep, cognitive engagement, social engagement. And the environmental risk factors, air pollution is a well established risk factor for cognitive decline. And then there's a lot of emerging evidence in a number of areas which I think in a couple of years will understand a lot more. But there's a lot of research looking at things like your exposure to green space, walkability, blue space, occupational complexity, noise and so forth. I just wanted to quickly mention alcohol because it always comes up in questions and I think most people want to know what's good for their brain health with respect to alcohol. And the message can get a bit confusing with alcohol. When we've looked at our observational data, so we've followed people over many, many years, what we see and we've seen it in our Australian cohort and we see it in the reviews of cohorts when we're looking at multiple cohorts together, is that people who have a light level of alcohol consumption tend to have better brain health and reduce risk of dementia. Usually up to one or maybe two drinks a day. However, there's a number of ways of looking at this whole issue of alcohol. One is that any alcohol consumption has been shown to increase some types of cancer risk. So you can't just look at alcohol and cognitive outcomes or brain health in isolation from general health. In fact, the World Health Organization says there's no safe level of alcohol consumption. And some people argue that the people who aren't drinking, so the comparison group in our research, may in fact have been former drinkers or have serious medical problems that meant their cognition or their risk of dementia was greater. So we may not be actually comparing the light. The light drinkers may not be being compared to the correct comparison group. It's one of these conundrums where we can't ever really determine it without a randomized controlled trial and it's probably unethical to conduct such a randomized controlled trial. So then people have looked at mechanisms, biological mechanisms, neuroimaging to try to unpick and unravel what's going on with alcohol. Now there is evidence that heavy drinking, particularly in middle age, so more than three drinks a day, seven days a week in middle age, does increase your risk of late life dementia. And this was reported in the Lancet Commission 2020 and that's why the Lancet Commission includes alcohol in its list of midlife risk factors. There's now emerging evidence on sleep, so the whole question of sleep and cognition and brain health is very complex. Again, because of that direction issue, we don't know which way the directions go. Is poor sleep a result of having a neurological problem or some preclinical dementia? After a lot of work and it's still very much an active research space, but at the moment the consensus is that sleep apnea appears to increase the risk of dementia when it's untreated. So it seems that people with sleep apnea have a 34% increased risk of developing all cause dementia and 54% increased risk of developing Parkinson's disease compared to people who don't have those disorders and when their sleep apnea is untreated. Now an important fact about all of this risk factor information, so by now I'm sure everybody's identified many risk factors that they have or their friends have or their family have because there's so many risk factors that almost everybody has some. They are cumulative, so the more risk factors you have, the greater risk of dementia, your greater risk of dementia. So they do accumulate and that's why when we look at trying to improve brain health and reduce risk of dementia, we want to take an approach that addresses multiple risk factors at once. And we need a reliable way to assess risk, otherwise we can't implement risk reduction policies and clinical practice guidelines. So risk assessment is really essential, accurate risk assessment for dementia is important for GPs, for people themselves to be able to assess their own risk. And also we use some risk assessment in our population modelling to give guidance to government around a public policy. So we developed an evidence-based reliable method of assessing risk factors for dementia and it's called Cogdea Risk. It's freely available on the Neuro website, I've got the URL here on the slide. This was developed through sifting through the literature over five years and synthesising all of the risk, the weights, the relative risks of all of the key risk factors. And once we developed the algorithm for this, we validated it on for international high quality cohort studies. We've also developed a short form and a Chinese version of the Cogdea Risk. The Cogdea Risk has a number of domains, so you complete the questionnaire and then you get feedback about and you can choose feedback in whichever order on your health, your sleep, your food and habits, etc. Once you've completed it, the program will generate a report for you telling you areas where you're going well and areas where there's room for improvement. And you can take this report to your GP and discuss it with them or you can follow the advice. The advice given here is all evidence-based, it's all based on things like the National Health and Medical Research Council guidelines or the WHO guidelines. Just out of interest, I thought I'd show you the relative weights of the risk factors that we have in the Cogdea Risk. What's interesting here is the cost of low education less than eight years is the biggest risk factor, has the biggest weight. But actually depression comes up fairly high as having one of the highest risks, increasing the risk of dementia and the vascular risk factors. So risk reduction obviously for all of us personally is very beneficial, enables us to take control and do what we can. And even if you have a neurological condition or you have dementia now, there are benefits for you to reduce your risk or if you've got MCI, all of these things promote brain health as well as reduce your risk of dementia. But there's also the economic benefits of risk reduction and have been some economic studies done. So there's been simulation studies and cost-effectiveness analyses. I won't go into the details here.  And for example, an intervention that could delay the onset of Alzheimer's by five years could result in 41% reduced prevalence of Alzheimer's in the population and a 40% lowering of costs. That was simulation work. And then other work from the trials has shown an enormous benefit through risk reduction in preventing future cases. So just to summarize, late life dementia is highly prevalent in the population, increases with age. There are a number of newer developments which I haven't discussed today. And there's both genetic and lifestyle risk factors. But the important message is there's a lot of modifiable risk factors for brain health and for dementia. And we can make quite a significant impact through risk reduction. Those risk factors seem to have an additive effect. So we tend to recommend addressing multiple risk factors if you have them. And this approach is cost-effective. And it has many benefits for you personally and for society. Basically promoting healthy aging, generally, not just brain health. And that's all. Thank you.