beginner debugging tip: change one thing at a time.
when a button breaks, changing five files can make the error disappear. but it leaves you guessing which change mattered.
try this small loop instead.
write down what you expected and what actually happened. “the app is broken” gives you very little to investigate. “clicking save closes the form, but the new note disappears after refresh” gives you a starting point.
write the shortest steps that reproduce it. use a throwaway test note. check whether it happens every time or only with a particular input. an intermittent bug still counts; record what you know without guessing.
for the missing note, ask: did the click handler run? did it send the intended data? did the server report success? does a fresh read return the note?
inspect one boundary at a time. keep passwords, tokens and personal data out of logs and shared screenshots.
maybe the page only updated its local display and never saved the note. that is a hypothesis, not a conclusion. look for evidence before changing the code.
make the smallest change that tests your explanation. if it does not help, undo it before trying another.
create a note. refresh. check it is still there. then try a nearby case, such as an empty note or a failed save. where practical, add a regression test that fails without the fix.
using an AI coding assistant? give it the reproduction steps, the relevant error and the smallest useful code sample. ask it to explain its hypothesis and propose one change at a time. remove secrets before sharing.
you do not have to understand the entire codebase to investigate one broken path. start with an observation you can check.