When I'm helping someone debug or just compile something it seems like they very often jump past potentially important information before fully comprehending it. I find I'm constantly saying "wait go back what did the output of that command say" or "wait that error message doesn't make any sense based on what we changed last time, why is it that error?" when they try to just go back to editing the code again. I've used this "comprehension-first" debugging strategy (just made that term up) to successfully debug systems that I am less familiar with compared to the person I'm helping. I'm not sure what to make of this.
I don't know how many colleagues I helped with 'git' just by telling them to read what 'git status' is actually telling them.
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.
I always have to force myself to remember that users will actively avoid reading any kind of error message you present to them, and just clear it away or close a modal automatically. There's an entire dark art to presenting this information such that it breaks through that conditioned response.
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's called impatience. When you're spending what seems like all day on finding the damn bug, and you don't want to waste anymore time on trivia. We're all human, we all get impatient.
I think it's more that there's this curve in your experience level where as you start out, you have no idea how to contextualize error messages outside of your code, so you just pick the thing that seems most related to your particular problem and try to Google it. And newbies are very bad at picking the relevant bits, so searching for the errors they are seeing often doesn't help them address the problem they are actually trying to solve. As you gain experience, you are able to pick out the signal from the noise and so going through the errors you seem becomes a valuable exercise.
Not only developers, but I think most people using computers.
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 remember helping a friend on a uni project we were writing in C. Of course, a C compiler very rarely output an actual error, just a bunch of warnings. My friend saw the warnings, figured "they're not errors, so they're ok to ignore for now" and kept scrolling to find their code flat out didn't work. When I pointed out the warning were actually errors and we went through and fixed them all, it magically started working.
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.
Yeah, during high school and uni years, whenever I helped someone with C/C++ assignments or projects, the very first thing I taught them was:
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.)
There was a slightly frustrating time in my life when I had to compile a single source base with several compilers (MSVC, Clang, GCC, CodeWarrior and ARMCC), whose tolerance for various quirks was rather incompatible.
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.
Knowing why a warning happens and being able to say that a particular warning is safe to suppress in a given instance is a reasonable way to deal with that case. There isn't a lot else you can really do... but you need to know the why part and have a documented explanation of for the suppression.
Love it. The same strategy was used by a colleague with a struggling team member. For that case, it was: show me a diagram. For nearly every question. The struggling dev just wanted to solve the issue so much, they were not stopping to understand the issue. Slow down to go faster.
> Slow down to go faster
yes! I had a similar problem with bigger projects. I used to start coding too early before understanding the problem completely.
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.
Same deal. I like to imagine I'm just plain smarter than others because of it, but smart is a pretty reductive term. I think it's more that debugging is an acquired skill, and one that we've practiced more than them.
> I find I'm constantly saying "wait go back what did the output of that command say" or "wait that error message doesn't make any sense based on what we changed last time, why is it that error?"
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!"
Yeah, "lean back and ask yourself what really happened" is a great debugging method.
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.
