4 ms·

This can really be extended to basic troubleshooting skills, and goes beyond software development -- beyond technology, even. Troubleshooting is really just a

by gregmac 10y ago

This can really be extended to basic troubleshooting skills, and goes beyond software development -- beyond technology, even. Troubleshooting is really just a special application of general 'problem solving', which is something schools aim to teach. I'm not sure why troubleshooting skills are not taught, especially something like "divide and conquer" [1]. Even in very complex systems, so long as you have the right access/visibility/logging to see what's going on at various places, it usually doesn't take very long to isolate a problem down to a particular component. [1] https://en.wikipedia.org/wiki/Troubleshooting#Half-splitting https://en.wikipedia.org/wiki/Troubleshooting#Half-splitting

joncampbelldev 10y ago
That wiki link is a fascinating rabbit hole for debugging related advice/pages. Also I'd never heard the term half-splitting, Cheers
- mannykannot 10y ago
  Half-splitting is a binary search for the root cause.
Pamar 10y ago
I wanted to write something similar, so I just upvoted you and piggybacked here. "Debugging" is really a subset of "Problem Solving". My grandfather had (by today's standards) very poor schooling, but he taught me some PHYSICAL WORLD DEBUGGING techniques which proved useful later in life. Just one simple example (I suppose this would be "Tracing" in IT) - once he was working on a cabinet that had somehow warped and wouldn't close properly. His solution: he cleaned the door and the frame, dipped his finger in oil and smeared it along the side of the door that would touch the frame. Then closed the door and opened it again - the point were some trace of oil was visible on the frame was the one that needed to be pared down to allow the door to close. He also used intuitively divide&conquer to find faults or leaks in wirings and pipes and so on. It is really something that should get more study and practice outside of IT or science, and I am sure that mechanics and other craftsmen have their own set of algorithms that can be used in various situations.
- empath75 10y ago
  Yep, my dad was a mechanic when he was younger and worked on cars for fun, and he taught me troubleshooting before we even had a computer.
- Pamar 10y ago
  see also this: https://news.ycombinator.com/item?id=8280379 https://news.ycombinator.com/item?id=8280379
nicklaf 10y ago
It is interesting to think that there have been those¹ who thought about the converse proposition, and saw early on the potential for the debugging of programs to become a widespread activity which would promote general habits of introspection in children (Seymour Papert's "thinking about thinking"). But that's not how things happened, and today people pretty much do not think about writing (and thus do not end up debugging) the programs they use. Instead we are all users now, and for many the troubleshooting algorithm is to: 1. google it, or 2. reboot it, or, failing that too, 3. throw it away, or, failing even that, 4. complain and curse. It's amusing to think that this model is now sometimes used by programmers as well (though hopefully mostly just #1, and sometimes #2). [1] https://youtu.be/Pvgef9ABDUc?t=43m10s https://youtu.be/Pvgef9ABDUc?t=43m10s

by gregmac 10y ago

joncampbelldev 10y ago

That wiki link is a fascinating rabbit hole for debugging related advice/pages. Also I'd never heard the term half-splitting, Cheers

mannykannot 10y ago
Half-splitting is a binary search for the root cause.

Pamar 10y ago

I wanted to write something similar, so I just upvoted you and piggybacked here. "Debugging" is really a subset of "Problem Solving". My grandfather had (by today's standards) very poor schooling, but he taught me some PHYSICAL WORLD DEBUGGING techniques which proved useful later in life. Just one simple example (I suppose this would be "Tracing" in IT) - once he was working on a cabinet that had somehow warped and wouldn't close properly. His solution: he cleaned the door and the frame, dipped his finger in oil and smeared it along the side of the door that would touch the frame. Then closed the door and opened it again - the point were some trace of oil was visible on the frame was the one that needed to be pared down to allow the door to close. He also used intuitively divide&conquer to find faults or leaks in wirings and pipes and so on. It is really something that should get more study and practice outside of IT or science, and I am sure that mechanics and other craftsmen have their own set of algorithms that can be used in various situations.

empath75 10y ago
Yep, my dad was a mechanic when he was younger and worked on cars for fun, and he taught me troubleshooting before we even had a computer.
Pamar 10y ago
see also this: https://news.ycombinator.com/item?id=8280379 https://news.ycombinator.com/item?id=8280379

nicklaf 10y ago

It is interesting to think that there have been those¹ who thought about the converse proposition, and saw early on the potential for the debugging of programs to become a widespread activity which would promote general habits of introspection in children (Seymour Papert's "thinking about thinking"). But that's not how things happened, and today people pretty much do not think about writing (and thus do not end up debugging) the programs they use. Instead we are all users now, and for many the troubleshooting algorithm is to: 1. google it, or 2. reboot it, or, failing that too, 3. throw it away, or, failing even that, 4. complain and curse. It's amusing to think that this model is now sometimes used by programmers as well (though hopefully mostly just #1, and sometimes #2). [1] https://youtu.be/Pvgef9ABDUc?t=43m10s https://youtu.be/Pvgef9ABDUc?t=43m10s