3 ms·

[...] a whole bunch of engineers tried to figure out not how to fix the problem but why the problem happened in the first place. This is exactly what d

by Rexxar 11y ago

[...] a whole bunch of engineers tried to figure out not how to fix the problem but why the problem happened in the first place. This is exactly what debugging is. My friend was quite obviously an accomplished hacker. His hacker mentality would have fared quite well in software production, where debugging is part of the normal workflow [...] Finding a workaround in production is not debugging even if it's useful.

kipper_t 11y ago
Debugging is different to looking at the process and identifying how the bug even got there through the lifecycle of the module at hand. The article to me seemed to be talking about that rather than debugging a live issue. Debugging in local is exactly the same as measuring things as you work, I.e. The width of a bolt and what the error is. Incidentally, debugging in local should be replaced with unit tests so you can get a consistent automated check. Debugging is only really useful when you don't really understand either an algorithm or set of frameworks. The equiv in eng is to just start throwing different components together and then executing them to measure what the effects are, which by the way I doubt would ever be done using materials destined for live.
Someone 11y ago
"This is exactly what debugging is" Yes and no. Debugging (in the sense that programmers do it) stops when you learn "X wasn't initialized" or "that buffer isn't long enough for the trailing zero". This is root cause analysis (https://en.wikipedia.org/wiki/Root_cause_analysis https://en.wikipedia.org/wiki/Root_cause_analysis). It goes way deeper into "why the problem happened". The buffer may be undersized because the programmer isn't educated well enough, because (s)he was too tired to think properly, because the spec specifying the maximum size was wrong, etc. Each reason leads to a different fix, often through more iterations of asking "why?" The programmer's lack of education can be caused by a problem in hiring practices, by low quality of internal courses, etc. The programmer may be tired because of long working hours, because of troubles at home, because (s)he goes out too much, etc. That buffer size might be a typo, an OCR error, somebody declaring the maximum size to be N because, otherwise, the data couldn't be fit in the current hardware, etc. Each explanation comes with a different way to prevent the problem from occurring again (something that traditional debugging does nothing about. Initializing that variable makes the problem go away, but in itself does nothing from you writing code with initialized variables in the future)

by Rexxar 11y ago

kipper_t 11y ago

Debugging is different to looking at the process and identifying how the bug even got there through the lifecycle of the module at hand. The article to me seemed to be talking about that rather than debugging a live issue. Debugging in local is exactly the same as measuring things as you work, I.e. The width of a bolt and what the error is. Incidentally, debugging in local should be replaced with unit tests so you can get a consistent automated check. Debugging is only really useful when you don't really understand either an algorithm or set of frameworks. The equiv in eng is to just start throwing different components together and then executing them to measure what the effects are, which by the way I doubt would ever be done using materials destined for live.

Someone 11y ago

"This is exactly what debugging is" Yes and no. Debugging (in the sense that programmers do it) stops when you learn "X wasn't initialized" or "that buffer isn't long enough for the trailing zero". This is root cause analysis (https://en.wikipedia.org/wiki/Root_cause_analysis https://en.wikipedia.org/wiki/Root_cause_analysis). It goes way deeper into "why the problem happened". The buffer may be undersized because the programmer isn't educated well enough, because (s)he was too tired to think properly, because the spec specifying the maximum size was wrong, etc. Each reason leads to a different fix, often through more iterations of asking "why?" The programmer's lack of education can be caused by a problem in hiring practices, by low quality of internal courses, etc. The programmer may be tired because of long working hours, because of troubles at home, because (s)he goes out too much, etc. That buffer size might be a typo, an OCR error, somebody declaring the maximum size to be N because, otherwise, the data couldn't be fit in the current hardware, etc. Each explanation comes with a different way to prevent the problem from occurring again (something that traditional debugging does nothing about. Initializing that variable makes the problem go away, but in itself does nothing from you writing code with initialized variables in the future)