Tim has been part of my software engineering journey. His YT videos helped me immensely from zero knowledge to becoming a mid developer. Thank you for your time.
Excellent advice as always. I would like to emphasize logging. There's a difference in debugging while you're building an app vs debugging after an app has been deployed to production and users begin to report crashes/bugs. Logs have proven critical in these situations for me. If a problem shows up later that doesn't appear in the log entries which may be out of the application's control, I'll add a log entry to help direct the user to a solution. I'd also like to recommend a book by David J. Agans titled "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems". It's a quick read and is filled with what feels like common sense advice but is easy to overlook.
I think I missed step 5? It seemed like you went through step 4 and then said “step 6”. I can’t seem to find the point where step 5 starts? Learning more about debugging as I’m moving into a more technical role and your videos are so clear and helpful, so thank you:)
Good stuff. Often in a agile team with time estimates you don't have the luxury of going through all these steps. Step number one is very important. When I feel I understand the problem, I often use chatgpt as a talking out loud partner. Sometimes i refactor bad code to get a clear picture and by doing so I go through everything in a new light. If you have someone to talk to that is helpful, step back an present your problem from a higher level. They will not know exactly what you are working on, give them context, dont just blurp out an exception.
I rarely go through all of the steps. They are designed to help you short circuit the solution, where you can quickly solve the problem and move on rather than spending time with debugging techniques that aren't needed.
printf debugging. If you know, you know. Seriously, debugging with modern tools, as well as old school approaches are both very important. Race conditions and memory corruptions are some of the best things in life. Realizing the common assumptions make can aid a LOT in debugging things. What did the author assume when s/he wrote the code?
@IAmTimCorey Great tips. I've been a dev for about 20 years. I learned most of your tips from this video the hard way haha. I love to watch your videos and "Fill in the gaps" in my knowledge
I don't have a summary for you. Here's what I recommend: take notes. Instead of trying to remember things in your head, write them down. It will help solidify what you are learning. Otherwise, you will end up watching videos and not getting any value out of what you watched.
Just basically identifying the issue, recreating it, debugging and checking variables and using unit tests.. talking it out.. logging...ask a co worker. Ask online if all other steps are not a success
Tim has been part of my software engineering journey. His YT videos helped me immensely from zero knowledge to becoming a mid developer. Thank you for your time.
Great to hear!
One of the best video on the channel.
Thank you!
I do the "talking through" method all of the time. My coworkers give me funny looks because I am "talking to myself too much". lol
Show them your duck. That should at least give them something more entertaining to talk about.
@@IAmTimCoreyHahahahaha, now that's a stance :D
@@IAmTimCorey My dev team actually has rubber ducks at our desks to help us.
Greetings, Master. It is always a pleasure to hear from you.
Thanks!
Excellent advice as always. I would like to emphasize logging. There's a difference in debugging while you're building an app vs debugging after an app has been deployed to production and users begin to report crashes/bugs. Logs have proven critical in these situations for me. If a problem shows up later that doesn't appear in the log entries which may be out of the application's control, I'll add a log entry to help direct the user to a solution.
I'd also like to recommend a book by David J. Agans titled "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems". It's a quick read and is filled with what feels like common sense advice but is easy to overlook.
Thanks for sharing!
I think I missed step 5? It seemed like you went through step 4 and then said “step 6”. I can’t seem to find the point where step 5 starts?
Learning more about debugging as I’m moving into a more technical role and your videos are so clear and helpful, so thank you:)
I think this is one of the most important pieces of advice to give in terms of growing yourself as a developer.
Thanks!
Good stuff. Often in a agile team with time estimates you don't have the luxury of going through all these steps. Step number one is very important. When I feel I understand the problem, I often use chatgpt as a talking out loud partner. Sometimes i refactor bad code to get a clear picture and by doing so I go through everything in a new light. If you have someone to talk to that is helpful, step back an present your problem from a higher level. They will not know exactly what you are working on, give them context, dont just blurp out an exception.
I rarely go through all of the steps. They are designed to help you short circuit the solution, where you can quickly solve the problem and move on rather than spending time with debugging techniques that aren't needed.
Thanks for the advice
You are welcome.
printf debugging. If you know, you know. Seriously, debugging with modern tools, as well as old school approaches are both very important. Race conditions and memory corruptions are some of the best things in life. Realizing the common assumptions make can aid a LOT in debugging things. What did the author assume when s/he wrote the code?
Thanks for sharing!
Who is debugging while watching this lol... Me!
I hope it helps.
@IAmTimCorey Great tips. I've been a dev for about 20 years. I learned most of your tips from this video the hard way haha. I love to watch your videos and "Fill in the gaps" in my knowledge
can you summarize the 6 steps please:
you talked a lot made me confused about what the steps are.
I don't have a summary for you. Here's what I recommend: take notes. Instead of trying to remember things in your head, write them down. It will help solidify what you are learning. Otherwise, you will end up watching videos and not getting any value out of what you watched.
Just basically identifying the issue, recreating it, debugging and checking variables and using unit tests.. talking it out.. logging...ask a co worker. Ask online if all other steps are not a success
Last option = copilot
👍