Ah, yes.

So I work every transfer as a friend and engineer and team leader.

And for me, that means that I write mostly react.

I smell see, assists a little bit of Ruby again.

And I also manage a team of six.

And I'm responsible for the day to day delivery for that team.

And this is also made about six years ago, I was helping run a workshop for young girls in New Zealand, which does?

Yeah, where I'm from.

And, yes, I'm a very long way away from home.

But the idea was that we would get these young women into the company to sort of show them what it was actually like to be a software engineer.

There were about 14 years old and they were all in the same tip class at school.

And honestly, I think we kind of blew their minds on How cool is this shit actually is compared to what they were learning on, but yeah, I really want to encourage people thio to do as many of these kinds of programs is as you can because it's incredibly rewarding and also inspirational because this was one of the inspirations for this talk.

Having worked with Junior Debs quite a lot.

It's one of these things that I've noticed is is they really struggle with debugging, and I think that's kind of because we don't really teach it as a skill.

It's one of those that you sort of expect developers to just pick up naturally.

And there's so much there to learn if you really focus on it.

And that's why I decided to write this talk.

Hopefully they'll be something useful in here, no matter how deep down this hole you've been before.

Better yeah, the quick look of the process itself.

How often have you actually spent time thinking about how you debug?

It's easy to forget that it's a difficult skill that it's It's something that you need to master in order to become a really experience developer, and it's learned over time and improve with experience.

And it's not just about the tools you use, but it's the mindset in the process and how you actually work through your debugging tasks.

And it becomes particularly clear when we compare those new developers with more experience ones.

Often new developers will jump straight into.

The coach will go and change a whole bunch of things.

They won't remember what they've changed in what they heaven and what actually might have fixed the problem and what was maybe just some extra bit of code that they stuck in there?

That wasn't useful little.

But it's something we do pretty much every single day.

And so in the talk, I won't go into the detail of how important it is to reproduce the bug.

Be methodical, only changed one thing at a time had a narrow down where the buggers.

But it's surprising how often this stuff is not talk.

So if you're a junior developer or you're teaching junior developers, I hope you're one of either that these two things.

Um, yeah, I do spend the time really looking into this stuff with them.

So there is one step that I do wanna cover really quickly because even the most senior developers I've worked with and including myself, sometimes I forget to write tests like this is the first thing that you do, right.

If you've discovered a bug, right, Otis, that reproduces it because it not only will keep your focus on just that one bug.

It'll also speed you up because you no longer need to launch you out and click about to get to the states of where your bug actually is.

And, of course, it'll help your bug never return.

So let's move on to the tools, starting with the consul Will the polls.

Aaron.

As you can see, we've got 56% of developers on the left hand side.

Use console.

Look on 67 on the right hand side, and it's It's not surprising, right, because we've been conditioned to use it alongside simple text editors like sublime text, Adam Note Pad, etcetera and a large portion of Web developers have also just simply missed the exposure to, ah form or or street or structured debugging process like myself.

And the browser console is a pretty nice way to inspect the results of your logs so it works and it's easy.

Well, why change it well, because there is so much more so even if we just take a closer look at console that look, you'll see that there are lots of different ways to optimize it.

So here on top.

We have the normal concert log usage for logging out these two variables.

Pin one and pen to, and here they are here but on the bottom.

If you just add to extricate characters to 10 this log into an object.

Here, you know only get the results of the lab but off the value of the variable.

But you also get the variable context, so it's much easier to see at a glance what you're lugging.

It could be really useful, especially when you're logging a lot of different things in your application, and you can also really add easily.

Add styling to your locks by including this percentage Cyan C at the beginning and then passing through some styling as the second parameter, you can get really pretty callous, so sticking to the consul for now.

Did you know that there are actually a whole bunch of different, well methods on that object?

I'm gonna show you my favorites, but Googling will reveal a hell of a lot more.

For instance, console table is super useful if you want to log out an array of objects, so here you can see it's much easier to kind of compare at a glance the different values and next we have console group, which is when I don't know about you.

But have you ever at if it ended up adding so many logs in your application that you can't tell which was the one that you just added well group and group collapse A really useful for structuring your logs into collapsible groups, creating less noise in the console for you to analyze, which is really the kind of game.

Another useful function you can use in the Consul is the dollar selector.

So it works similarly similarly to the J.

Crew selector.

It's an alias for the document, Doc.

Select a function in the console.

If you include a zero after it is done here, you can get the most recently inspected HTML element, or JavaScript object.

No one gets you a sick and most recently selected Exeter Exeter up to full super useful.

If you want to quickly see what properties what attributes on the domino door.

JavaScript objects that you're looking at, and if you use dollar dollar, it's the equivalent of document dot query selectable.

Even better, it returns you a proper array rather than a node list so you can manipulate its right away.

Consul, don't trace has been a lifesaver for me, especially when you're working in a new cold baths.

And you can't actually, you don't have that, you know, inherent knowledge of what is calling What?

Um and so in here, I added a consul trace on this handle filter click function to figure out what was calling it, and you can see that it's now telling me that it was cool by Handel Clock in filtered Out Gaius and Console Doctor is great when you want to inspect a dom note as a JavaScript object rather than as its markup, which is what concert log returns you.

You can see all the properties on that Don owed much more easily.

And no, though it's even more useful.

As you can see, Consul Logs blitz spits out the objects in black and white, and it only displays to levels Deep Consulate there, on the other hand, allows you to add some really handy configuration.

So here we've just added this extra object where we've said colors true of dip null, and it means that we get our logs or pretty with lots of different colors, and you can now access the LAT and long properties on that geo object.

So let's say we've been working with console functions for a while and want to step it up.

Well, let's dive into the details.

So I'm gonna focus on chrome because it's what I'm most familiar with.

But the Firefox Dave Tools also really great and have a lot of the same functionality.

Browser details have some really handy features for debugging.

So the devil's debug A Is that the best one off them?

One of the simplest ways to activate this is by using a debug, a keyword in your code.

So this debug a key.

Would I touch this in into my editor and opened up in crime?

And when I refreshed it hit the debug Ricky with their that break point?

And so now you can see Sorry, I'm having video issues as well, but hopefully you'll be able to see that we can log out the of the variables in scope at the moment.

We can also inspect the entire scope at this point of execution, and we can also step through the code.

And speaking of stepping just in case you've never used a debunker before.

Here, your main options.

They're pretty much the same, no matter what kind of language you're writing or what kind of tool you're using.

First, we have resumed, which is when you're on a break point on you.

Press this and you'll be able to resume the script until the next break point.

It's hit.

If you hold this button down, you also have the option to play through without hitting any more break points, which could be useful when you just want to get the code running.

The next is step over, which executes the next function after a break point and stops afterwards.

And then we have the step into and out of functions and note that these air functions that were stepping over into and out off, not lines of coach that can take a little bit.

Thio kind of get that, um and yes, So what we've been doing here is adding a line of code break point with the debug.

A key would in our idea, but if you set things, break points in the diff tools or in your head, Issa, you'll see why this could be much more efficient than using Consul Log.

It's almost as if you've pippins your whole code base with consul locks without actually having to do so and having to clean anything up.

Simply click on the line number.

So here I've clicked on 14 21 and 26 and then run your code as usual.

And the execution will stop on your set line of code break points, which you can then press resume to hit the next one and go through as opposed to needing to step through over every single function.

And when you're doing this, you may also want to use a watch expression.

So that's what I've got here.

On the right hand side.

I've just decided Thio click the little plus button there, and I've just decided to watch this dot state dot mysteries because I want to see what's happening to that data.

And then as you step through the code that, um, expression will update so you'll be able to see the value of whatever you're watching.

There are lots of different types of break points, and you can see these are cities directly in the details.

So, for example, example, we've got the line of code, which is what we've just been talking about.

Conditional line of code, which I'll show in a second dom.

So if it don't know changes except us off, you wanna break on a particular http request event, listeners exceptions and functions.

So here on the left, you can see howto ad break points just on certain event listeners.

So here, just by taking click, there means that any time I click on my app, a break point will be hit and then we have the dumb nards.

So here I'm gonna break on when a dumb nodes attribute is modified and then conditional break points down the bottom could be really useful.

For when a certain function say, s girl Handa or a react Renda is called multiple times.

But you only want to stop execution when something has a certain value.

So here I am, creating a break point that will only be hit if the length of my mysteries array is more than zero.

So I hear only want to stop when the FBI has actually returned my data because I only actually care about the data for this particular debugging case.

I know that the FBI is returning, so I don't need to stop when a pia hasn't returned.

But the react renderers run, so you can always click on the pores on exceptions button.

If you want a break point when there's an era and the tick box to pause on court, exceptions can be really useful.

For instance, if you've gotta try catch that's swallowing your errors and you're not sure why, then you can find out more about those exceptions.

When you have a bunch of break points in your app, it can be useful to disable one or more when you're focused on something specific.

So this chick mark in the break points list here will just disable that breakpoint temporarily.

And in the debugging TOBA, you can disable all break points in case you want to.

Just check how your runs while you're chickens and changes you've made, for example, and it's all that's really useful when you're using.

The D Bagger is like boxing.

The slits us prevent the D bugger from stepping into certain scripts when we're debating code.

So here I was debugging a reaction lifecycle function, and I jumped into the React Dom library.

I could be pretty sure that my bug is not in the react on library, so I black box the script and this way, next time I stepped through into a function that comes from this file the debate.

You will simply ignore it, and I can focus on my application code.

You can also include file patterns in the digital sittings to black box entire folders like no bottles.

For example, another useful trick when you're really unfamiliar with the code base is command plus backslash.

If you press this short cut when JavaScript, as executing it will add a break point to the code straight away and stop it executing, you'll be able to instantly see what is happening the moment you press that shortcut.

And you can also not add log points and crime death tolls, which is essentially a console log that you don't have to remember to delete from your coat.

The D beggar want paws on these points, but you'll still get the results in the console.

Another really useful tool, windy bagging and the deaf tools is the snippets option.

Under the Sources panel here, you can save your own codes in efforts to run in the console, and there are some really great collections of snippets of edible, online and different libraries.

So one of my favorites, old, wins the console with a function called console not safe, which you can use and pass anything to it, which then gets downloaded as adjacent.

Wow, this is really handy, especially when you have a big Jason objects that you wanna open maybe in an I D or you want to send it to a colleague, for example.

Another useful tool is live expressions.

You can click the EI icon here to type something into the console and create a live expression.

This pins it to the top of the console, and it updates riel time.

It could be really useful.

When something in your code needs to respond to a window with or scroll position, for example, you'll be able to see it update as you scroll down the side.

So what about when you want to actually test some of your bug fixing hypotheses while a really great feature in crime has cooled local overrides, So here we go to the sources panel and go toe over its and we can set them up by selecting a folder on, in this case, my discount clinic.

And we didn't need to give crime access to that photo.

And then we can go and change any of the code on this size, for example, this pot of the Reddit website and adds whatever we want.

So I'm gonna add a background color of purple.

And now if I go command save, you can see about this little purple dot up here on the file.

And then when I refresh the changes of persistent, which is really, really useful if I close the diff tools and refresh, the changes are gone.

This approach is really useful for making smallest changes to production websites.

When you're trying to debug something in particular, when you want to fix something quickly and you have a reasonably good idea of where it is, you don't need to have your local environment running.

You don't even have to have the original code on your computer.

It's could be done with just about any computer set up.