It is a task that shouldn't be learned in university but in middle school. And it's not just useful to stem, it's useful to many things in life. E.g. a disagreement between two educated, smart people usually can be resolved by debugging how everybody got to their point of view and then flashing out the details. It's also how you figure out why the toaster isn't working any more, or why your wife left you.
It's also actually two skills:
Analysing a state. What do you see, what is there, or isn't. What was expected.
Backtracing. Getting from point y to point x by figuring out how y happened.
I'd say at least in my country we also actually learn these skills. But when we learn the methods its in a completely different context, totally unrelated to life. In real life, you hit a problem, you get overwhelmed by the complexity, and then your brain needs to start applying the method. In school you learn the method, no idea why. Then you apply it to totally theoretical problems, no idea why. Then you get tested on how well you execute the method, no idea why. Then nobody ever talks about it again. Now, how should your brain in moment of being overwhelmed remember that method A it learned 20 years ago may apply here? There's no way.
Teaching shouldn't be: theory->method->application->test. It should be theory->enforce_problem->wait_for_questions->explain_how_theory_can_be_applied->review_of_application->goto:enforce_problem.
Your comment couldn't be more on point. I viscerally disagree with the direction that a lot of "coding" initiatives are taking in schools nowadays. The claim is that the intentional move away from actual computer science is that it is a way to attract more people.
Fine. But when the course is just about making "whatever you want," then that really valuable time of learning these debugging skills gets missed, 'cause you can always pivot and do something else. The most valuable lessons I've learned about coding -- and the ones which, like you wisely stated, are applicable elsewhere in life -- had everything to do with needing to work through a tough computational challenge.
That taught me how to know I don't know something, how to poke at an issue in such a way as it would reveal something about the system (or my own understanding), the oh-so-currently-hyped skill called "grit", etc.
Every thinker or scientist I deeply respect has a treasure trove of examples of being stuck and working through hard and challenging problems even as little kids. That somehow we think an avenue for a more educated populous consists of presenting fewer experiences like that to youngsters is beyond me.
An important part of analyzing state, and specifically a mismatch between the state and your expectations, is to ask yourself whether your expectations are valid. Not every bug is an error in coding what you intended, and we naturally tend to be somewhat blind to our own incorrect assumptions.
I agree that these are the same skills. Outside of the programming context I would not call it debugging but rather just rationality or problem-solving. Some call it the scientific method, though that's not exactly the same thing.
In the debugging context there are some more specific applications of the general principles, which should also be taught.
Agree in principle. Another way of putting it is, debugging is another word for applying the "scientific method." E.g., experimental vs control group is a useful concept in debugging
Yes! I've been saying this forever -- debugging is a science.
The best way to find and fix the toughest heisenbugs is to a) form a hypothesis as to what might be happening, b) figure out what would falsify your hypothesis, c) run an experiment that must make the bug happen reliably iff your hypothesis is correct, and finally d) figure out the solution.
Exactly. Debugging is just the application of the scientific method (or rationality) to a specific domain. I have been beating this drum for years now...
I never got military education, but I have to say I admire how well military personal can respond to problems. Anybody have insights how they get educated and if that could be applied to programming/debugging as well?
I have some insight, but not as much as someone who's actually went through formal training.
It's a mindset issue. In the military, a soldier is a tool to get a specific job done. The soldier must understand this and shed away his ego and any ideas he has about his "self."
He must understand that he is a cog and his only job is to be the perfect cog.
This could be applied to programming to increase efficiency, but I'm certain most programmers (and the HN crowd in general) won't be happy with what's to be expected of them.
The success of the mission rests on appointing a competent commander (CEO/Manager/Etc.) that'll make all the final decisions and having soldiers (employees) that can zero-in on doing exactly what the commander tells them to, even at the sacrifice of their comfort.
There's a lot of ego and self-identity in the programming world which collides with the very essence of the "military way of doing things."
Once an officer hits their unit, they have someone with 5-10x more experience to supervise them for their first 5-10 years. It would be like a new manager getting a senior engineer to work with 7 days a week to help guide their bad ideas.
Additionally, your software engineers aren't indentured servants. In the military, you often can't go home until a problem is fixed and if you quit, you go to jail.
The military burns through a lot of good people, most get out after their initial term.
That doesn't matter, though. What I'm talking about is that you can throw a granade next to a soldier, and he'll still be able to think and make decisions. That means he got trained to not let his amphibian brain take over when under stress. That's in some regards what you need if you want to learn debugging. Don't the stress of the too complex problem stop you from thinking. Go step by step.
I bet you can teach that without all the bad associations people have about the military.
One of the first computer class lessons that I remember--in maybe 4th grade?--taught us to use Yahooligans and Altavista and such to research a topic. Incredibly valuable to ingrain at that age the idea that the best way to figure something out is to start running vague queries until you understand enough to synthesize an answer or a theory.
It's also actually two skills:
Analysing a state. What do you see, what is there, or isn't. What was expected.
Backtracing. Getting from point y to point x by figuring out how y happened.
I'd say at least in my country we also actually learn these skills. But when we learn the methods its in a completely different context, totally unrelated to life. In real life, you hit a problem, you get overwhelmed by the complexity, and then your brain needs to start applying the method. In school you learn the method, no idea why. Then you apply it to totally theoretical problems, no idea why. Then you get tested on how well you execute the method, no idea why. Then nobody ever talks about it again. Now, how should your brain in moment of being overwhelmed remember that method A it learned 20 years ago may apply here? There's no way.
Teaching shouldn't be: theory->method->application->test. It should be theory->enforce_problem->wait_for_questions->explain_how_theory_can_be_applied->review_of_application->goto:enforce_problem.