Some people's mind just goes blank when they see error and it prevents them from solving it themselves. Often times, they are so used to copy-paste and also not being empowered by management and colleagues for some of their approaches diminishes loads of their confidence.
The other thing I'm always kicking myself about is forgetting that users will just start poking at things and reclicking if they don't immediately get some feedback that things are happening.
It feels like people have a tunnel vision focusing only on the parts of the screen they're accostumed to. The other parts are ignored.
They try something, fail, try the same thing again, fail again, and repeat until they either give up or decide to slow down and explore the corners of the screen (which often leads to them finding the error).
I wonder if this is somehow related to the "magical halo" of technology. First because they try the same thing expecting different results, second because they don't explore the unknown parts of the system (maybe for fear they'll make things worse?).
I think debugging is a hard-won skill that comes from fixing your own mistakes and having the patience to trawl though logs for hints.
1) How to add `-ansi -pedantic -Wall` to their compilation flags.
2) That they absolutely have to do it whenever they're coding C/C++.
3) That they need to read and then clear out all the warnings before continuing to code.
Suddenly, their programs started to work most of the time, instead of crashing or hanging.
I still give this advice whenever I teach people, but with modernized set of flags. That'll be `-Wall -Wextra` and `-std=c++17`, or whichever standard is most current for their situation. Recently I've been teaching people who use MSVC community edition, so I tell them where to bump the warning level in setting - and the IDE is good at catching and annotating typical mistakes too.
Myself, I do all that + run clang-tidy for good measure.
(Another C/C++ thing that beginners need to be told is that, for any given translation unit with compile errors in it, they should always focus on the first couple errors, particularly on the very first one. A compilation error usually confuses the compiler, so anything past the first one or two is usually garbage, and disappears if you fix the real ones.)
I do not remember the details anymore, but some code provoked a compiler warning from one of the compilers, while its easiest fix provoked a compiler warning from another of the compilers.
I wanted to keep my -Wall, but it required strange twists of code sometimes.
I have decided to write an essay since, about everything I am about to do. This slows me down and makes me look at every detail that might be crucial in the project execution.
These docs then become some sort of a data lake about the process of building this project, from which later I can derive documentation or slides for presentations from or send people there when they ask me why I did something the way I did.
Along those same lines, I like to use the phrase "sanity check" a lot. It's meant to imply nothing should be wrong yet but we can't rule anything out, so let's check every single step and make sure they match our expectations.
For me it seems to work to get the other person to explain what they're expecting as they go through the steps (forcing them into rubber-duck debugging with me as the duck), and many times has caused them to find something they were just glossing over before without me even having to point it out.
I use a phrase when this whole "jumping past messages" is happening, so often in fact that it's become a meme at our company, "You are clicking like a mad woman/man!"
But, counterintuitively, it actually might work better with the projects you are less familiar with. Once you are too deep in some rabbit hole, all the details you know may have negative impact on your ability to orient yourself.