Hi everyone. It's an absolute pleasure being here and discussing this really important topic. How do we debug debugging? Why do we need to approach it differently in order to work more effectively? So a bit of don't miss health. My name is Eleanor and it is an absolute pleasure being here. I grew up in New Zealand and have got the privilege of living and working in Tel Aviv. At the moment, I'm director director, director, director, director director director of solution architecture and partnerships observability tools as part of my role, I work with many clients around the world, ranging from small startups right through to Fortune 500 companies. And this gives me the privilege of having the insight into how different teams work, what works, what doesn't, and what I want to do today is share some of those learnings with you with a focus on debugging what's broken, what works, what needs changing? How do we empower teams to develop the highest quality code that they can in the quickest amount of time? And let's kick things off with why it's even important. Now. Developers do a lot and it depends on who you ask, they'll give you a different answer. But a study done by CoreLogics that found out that 75% of developers time was spent on solving bugs. Now let that sink in. In a five day work week, your developers only have a day and a quarter to work on new code. The rest goes to fixing existing issues. So if we can improve this metric by even just a little bit, then our teams will be more efficient and the business as a whole will be much more successful. Before we look at changes, let's look at what's holding us back. Now, if this was an in person conference, I would do a quick poll, but I'll just let you vote from home. So what would you rather work on? What would your team rather work on? Would it be a bug or a feature? All right, take a moment to think. So I would like to hope that I can't sense what you're saying, but when I do this in conferences, in rooms and in person events, people often say that people love doing new things. They like working on features, they love creating things from scratch. It's a lot more satisfying showing a new feature rather than something old that you've worked on. And this is human nature. This is what we're accustomed to, this is what we're used to. We always like looking ahead to what's new rather than looking back and spending our time on something that's not at the forefront. And we can't resist that, right? People enjoy getting new clothes, as opposed to getting old ones fixed. And this is one of the problems that I see, one of the first few problems with debugging, and that's the fact that fixing old things is simply not as fun as creating something new. Our engineers often get less satisfaction from fixing broken things rather than creating new, shiny features. And as a result, the motivation to work on bugs is much slower, which in turn contributes to a slower and less effective workflow. Now, let's jump into this scenario. We've got a comic here that I found on XKCD. So we've got one developer is asking someone else in their team to look into a bug that they've just opened, the other developed, freaking out, asking if it's one of those horrifying ones that will prove that the whole project is broken. Now, bugs, especially serious ones, are often accompanied by a lot of stress. There are many stakeholders involved in the fix, there are lots of complaints from customers, and there are huge repercussions. And this leads into what I classify as the second problem with debugging. When it comes to debugging, there's generally a lot of pressure around it. There's always the sense of anxiety. And this was illustrated in a comic that we showed. Debugging can sometimes feel like you're working with a Jenga tower, where changing one thing will make everything collapse onto the next example, showing what's really holding us back when it comes to debugging. I've copied this debugging exercise that one of the top engineering schools in the States gives its first year computer science students. Now, if you read carefully, it gives step by step instructions on how to debug. First you need to confirm the input function, then step over, then look at the output. Classic debugging. That's all well and good if we worked on applications that run locally and we had complete control over them, but it's not the reality we live in. If we look at what we work with, it's cloud native complex environments. And when it comes to working in production environments, running on the cloud, this methodology becomes irrelevant. The third problem that I'd like to summarize is that the tools we give our teams are simply not right for the job at hand. You see, people are equipped with debugging tools and techniques that are no longer relevant to our complex tech stacks. You can't really recreate your production environment locally in order to test things out. And in a similar manner, you can't expect your code, which is running locally to behave in the same way when you run it on serverless functions, for example. So we've seen some problems, but now I really want to focus on how we can solve them. How can we focus on these three pillars in order to address some of the issues with our approaches to debugging? So the first thing I want to focus on is the people side of things, and there are a number of things we can do here, and the easiest is probably to simply better market the debugging task. When you come to your team and there's something that they need to focus on, don't have this sad, defeated look on your face. Focus on the positive. What speaks to your engineers? An incredible challenge, working on a bit of code that is actually impacting users. Find that niche and be the advocate for fixing the bug. I caught up with a friend and I asked him, would you rather work on a bug or a feature? And for him, bugs win. He said that bugs are often well defined. The challenge excites him and he knows it's really important for someone. So it's all about perspective. The second point is around teamwork. We need to ensure that we have a team case ownership mentality. A bug isn't just fixed by a single developer. Make sure the entire team has ownership of the bug so that they can get behind it. And lastly, when it comes to people, we want to make sure we create a safe space for our developed don't let others nag. We as leaders need to establish the trust with our colleagues that the team is doing the best they can. And if you need to get your product managers to step aside, or if you need to have your business developed managers to just let things go and just trust the engineers to work on it without distractions, then you do that. The second pillar is around processes, and I want to see how we can refine the processes to ensure that we debug effectively. The first thing that we can do here is around adjusting the backlog, but really adjust it. Communicate with everyone. We want to reduce stress on our developers and one of the best ways to do that is to remove external distractions. We want to build a process with the rest of the company on how to prioritize bugs. Not everyone needs to be fixed right? Not everything needs to be fixed right away. As a matter of fact, not everything has to be fixed at all. You need to establish strong relationships with the stakeholders in your company and get real feedback from them on what needs to be done. Lastly, make sure that the groundwork is done for your developers. You wouldn't expect a builder to make a home without someone having surveyed the land. And in a similar manner, we need to make sure that our developers are well equipped with as much information was they need about the bug. And finally, my favorite topic, tools. Focusing on people and processes is important, but focusing on tools is an easy way to start seeing results. There are a number of things we can focus on here. First, give your teams a cloud native toolbox. If they're building apps using serverless functions, make sure that they have a way to debug it. Recreating that app locally so that they can debug, that will not be possible. Similarly, if your deployment process takes two weeks, make sure you give your teams a way to debug live environments, because adding a log line and waiting for two weeks before you see the data is simply not realistic. Second, we want to ensure that the tools are integrated into your team's daily workflow. Train the team share use cases we don't want someone to start learning how to use a tool at 03:00 a.m. When everything is on fire. Lastly, data is gold, but too much will weigh you down. Collect data where it makes sense. Make sure it's easily accessible and usable, but don't overdo it. So I want to wrap up with the fact that bugs are a part of our day to day life, and there's a ton to discuss around this topic. But I do hope that you'll be able to implement some of the things we've discussed, and I look forward to continuing the conversation on other channels. Thank you.