4 ms·

I also think it is worthwhile stepping thru working code with a debugger. The actual control flow reveals what is actually happening and will tell you how to im

I also think it is worthwhile stepping thru working code with a debugger. The actual control flow reveals what is actually happening and will tell you how to improve the code. It is also a great way to demystify how other's code runs.

ajross 2y ago
I think that fits nicely under rule 1 ("Understand the system"). The rules aren't about tools and methods, they're about core tasks and the reason behind them.
nthingtohide 2y ago
Make sure through pure logic that you have correctly identified the Root Cause. Don't fix other probable causes. This is very important.
sumtechguy 2y ago
That is rule #3. quit thinking and look. Use whatever tool you need and look at what is going on. The next few rules (4-6) are what you need to do while you are doing step #3.
nottorp 2y ago
This is necessary sometimes when you’re simply working on an existing code base.
hugograffiti 2y ago
I agree and have found using a time travel debugger very useful because you can go backwards and forwards to figure out exactly what the code is doing. I made a video of me using our debugger to compare two recordings - one where the program worked and one where a very intermittent bug occurred. This was in code I was completely unfamiliar with so would have been hard for me to figure out without this. The video is pretty rubbish to be honest - I could never work in sales - but if you skip the first few minutes it might give you a flavour of what you can do. (I basically started at the end - where it failed - and worked backwards comparing the good and bad recordings) https://www.youtube.com/watch?v=GyKrDvQ2DdI https://www.youtube.com/watch?v=GyKrDvQ2DdI
- waynecochran 2y ago
  To go backwards, don't you have to save the previous states of the machine. This always seemed long a strong limitation.

4 ms·

I also think it is worthwhile stepping thru working code with a debugger. The actual control flow reveals what is actually happening and will tell you how to im

by waynecochran 2y ago

ajross 2y ago
I think that fits nicely under rule 1 ("Understand the system"). The rules aren't about tools and methods, they're about core tasks and the reason behind them.
nthingtohide 2y ago
Make sure through pure logic that you have correctly identified the Root Cause. Don't fix other probable causes. This is very important.
sumtechguy 2y ago
That is rule #3. quit thinking and look. Use whatever tool you need and look at what is going on. The next few rules (4-6) are what you need to do while you are doing step #3.
nottorp 2y ago
This is necessary sometimes when you’re simply working on an existing code base.
hugograffiti 2y ago
I agree and have found using a time travel debugger very useful because you can go backwards and forwards to figure out exactly what the code is doing. I made a video of me using our debugger to compare two recordings - one where the program worked and one where a very intermittent bug occurred. This was in code I was completely unfamiliar with so would have been hard for me to figure out without this. The video is pretty rubbish to be honest - I could never work in sales - but if you skip the first few minutes it might give you a flavour of what you can do. (I basically started at the end - where it failed - and worked backwards comparing the good and bad recordings) https://www.youtube.com/watch?v=GyKrDvQ2DdI https://www.youtube.com/watch?v=GyKrDvQ2DdI
- waynecochran 2y ago
  To go backwards, don't you have to save the previous states of the machine. This always seemed long a strong limitation.