It’s also an amazing way of duck-debugging. By the time you write down what the problem is, you’ll figure out where’s the issue or at least what you should try next.
“X is giving me an error, I checked X’s logs. X communicates with Y… Oh, I need to check Y next!”
And if you can’t figure it out, you have the problem and everything you tried documented so you can ask for help and get answers effectively.
I often take notes in the form of “TODO” comments, as I work through a problem. Then I have my editor set up to highlight them, and my git asks me if I’m sure I want to commit them. Works pretty well with keeping my thought process straight
This is why I write down the questions I’m trying to answer in a text doc, e.g:
Where is this network call comming from? …/some-api-call.js Why do you think it’s causing a 403?
Etc. So if I lose my thought (all the time), I know exactly what and why I was doing it. Also stops you from re-investigating things you forget
It’s also an amazing way of duck-debugging. By the time you write down what the problem is, you’ll figure out where’s the issue or at least what you should try next.
“X is giving me an error, I checked X’s logs. X communicates with Y… Oh, I need to check Y next!”
And if you can’t figure it out, you have the problem and everything you tried documented so you can ask for help and get answers effectively.
It’s a very valid advice.
I also try to do it for complicated bug and it helps me to keep a track of what I tried to do and my hypothesis.
I often take notes in the form of “TODO” comments, as I work through a problem. Then I have my editor set up to highlight them, and my git asks me if I’m sure I want to commit them. Works pretty well with keeping my thought process straight