Sign up to save your podcasts
Or
Share Sudoku and methodical debugging
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Sudoku and methodical debugging
Yesterday I taught my son Sudoku because he told me that he enjoys math
games which was you know, exciting for me to hear and so he yeah, we we
just had some sudoku puzzles that I'd printed and laying around and so my
wife was working on one and and I was working on one and we were just
talking about how we solved Sudoku puzzles and I just mentioned that I
pretty much just go with very methodically and I was I was explaining a
very methodical process for solving these puzzles and maybe it's not the
fastest or anything.
I don't really take notes or any.Like write the numbers and or any you
know, the possible numbers it could be whatever I just go yeah just think
about okay can this number be here no it can't okay let's just move on to
the next thing and and eventually you get the whole thing filled out and it
works out pretty well and I was just thinking about that and how we do the
same thing or I find the most effective thing for me when I'm debugging is
to be very methodical about it and and trial and error and and mostly like
I find that most.
Effective when I troubleshoot in such a way that makes the as few changes
as possible and then sees what impact that may makes and then slowly we get
closer and closer to the part of the code that where the bug resides in
rather than just making a ton of changes and you know shot in the dark and
hope that and that things work when I was early in my career, I really
spent a lot of time just changing all sorts of things in the hopes that one
of those things would fix the problem and what happens when you do that is
you.
Change a bunch of things and and sometimes the changes that you make are
sub-optimal but you're just like doing your best try to figure out what the
problem is and so if you make a bunch of sub-optimal changes and one of
those fixes the problem, then you may not actually go back and fix all
those sub-optimal changes that you made you just may end up shipping a
bunch of stuff optimal things leading to the potential for more bugs in the
future and completely different ones potentially and so being very focused
when you're debugging and just change one thing and then see if that works
and ifIt doesn't then then move on to the next and another thing that just
for some reason I was just thinking about is trying to find where the last
time in place where the code was working properly if this is like a
regression or something can be really helpful to so as your debugging be
very methodical about it just go step by step and and don't skip or don't
try to do a bunch of things at once and and hopefully you figure out what
the actual problem is so that you can have a better solution for that
anyway hope that's awful have a wonderful.
Thing bye.
View all episodes
By Kent C. Dodds
5
44 ratings
Yesterday I taught my son Sudoku because he told me that he enjoys math
games which was you know, exciting for me to hear and so he yeah, we we
just had some sudoku puzzles that I'd printed and laying around and so my
wife was working on one and and I was working on one and we were just
talking about how we solved Sudoku puzzles and I just mentioned that I
pretty much just go with very methodically and I was I was explaining a
very methodical process for solving these puzzles and maybe it's not the
fastest or anything.
I don't really take notes or any.Like write the numbers and or any you
know, the possible numbers it could be whatever I just go yeah just think
about okay can this number be here no it can't okay let's just move on to
the next thing and and eventually you get the whole thing filled out and it
works out pretty well and I was just thinking about that and how we do the
same thing or I find the most effective thing for me when I'm debugging is
to be very methodical about it and and trial and error and and mostly like
I find that most.
Effective when I troubleshoot in such a way that makes the as few changes
as possible and then sees what impact that may makes and then slowly we get
closer and closer to the part of the code that where the bug resides in
rather than just making a ton of changes and you know shot in the dark and
hope that and that things work when I was early in my career, I really
spent a lot of time just changing all sorts of things in the hopes that one
of those things would fix the problem and what happens when you do that is
you.
Change a bunch of things and and sometimes the changes that you make are
sub-optimal but you're just like doing your best try to figure out what the
problem is and so if you make a bunch of sub-optimal changes and one of
those fixes the problem, then you may not actually go back and fix all
those sub-optimal changes that you made you just may end up shipping a
bunch of stuff optimal things leading to the potential for more bugs in the
future and completely different ones potentially and so being very focused
when you're debugging and just change one thing and then see if that works
and ifIt doesn't then then move on to the next and another thing that just
for some reason I was just thinking about is trying to find where the last
time in place where the code was working properly if this is like a
regression or something can be really helpful to so as your debugging be
very methodical about it just go step by step and and don't skip or don't
try to do a bunch of things at once and and hopefully you figure out what
the actual problem is so that you can have a better solution for that
anyway hope that's awful have a wonderful.
Thing bye.