|
Member 12982558 wrote: Guided experience is needed here.
Absolutely true - but there's one precursor ingredient to debugging by whatever means: motivation.
Motivation goes beyond the coding - you need to want to do things and make them work. Solving the bugs could (should?) be as satisfying as finally getting it all working. I take my cue (or more, found a kindred spirit) in this quote often attributed to Hannibal:
"If I cannot find a way I'll make way!"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I teach an Intro to SQL class (okay, I gave the class ONCE...then I changed jobs and after I settle down the new boss wants me to offer the class again). After class, the one thing I learned as an instructor, was that I need a How to Troubleshoot SQL section. Common errors in code and what the message means. I learned this because my student keeps sending me his code (I also now serve as his mentor) to help him debug. My fault...I didn't introduce him to what those red squiggly lines mean and how to understand the text that appears when you hover over the line.
Simple things like leaving the comma when removing/commenting out the last line in a select statement (and the reason why I suggest the comma goes at the BEGINNING of a line and not at the end!). As this is an introduction class, I don't want to get too deep into all the things that can go wrong with coding, just the things that happen to most coders (that means the beginners and the experienced SQL writers, too). Just to have a basis of what do you do. FIRST...Read the error! Either the pop-up when you go to run it, or what you see with the red line. Then, decide what to do about the message. Simple, right?
|
|
|
|
|
It's amazing how much the programming and debugging mind set applies to other aspects of our lives.
I'd hazard a guess at almost anything man made.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
Which begs the question "how do these people manage to do anything at all?" 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
OriginalGriff wrote: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be.
Ohhhh...A JavaScript dev, right? 
console.log("the bug is here somewhere...");
|
|
|
|
|
Way before that: COBOL, FORTRAN, and punched cards (or if you were lucky, paper tape).
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
As it would be only useful in JavaScript...
I have done it in almost every language I have used (and I am not so old as many in this thread).
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I still recall the day I accidentally put the same error into a logging statement as the error I was trying to track down.
I was zeroing in on the error (I thought) by adding more and more logging, wondering "how can it fail in this section, it used to work and I didn't change anything"  . In the I had isolated "the error" to an empty code block with my faulty logging statement following. 
|
|
|
|
|
Ron Nicholson wrote: Makes me wonder if colleges who teach programming classes, teach debugging?
As far as am concerned, the real question is "do colleges teach?"
I have yet to encounter a competent programmer fresh out of college that knows about design patterns, language syntax, some decent design skills, etc, let alone how to turn on the computer and fire up an editor and write a program or website that displays Hello World.
|
|
|
|
|
:laughs:
I routinely taught my tutors and fellow students more than the tutors taught me.
I was interested & keen. They were on the other side of 20 years worth of life's disappointments.
TD
TASM
TurboPascal
BCPP
Oh how I have fond memories of thee. MASM, NASM & VC - not quite so much!
|
|
|
|
|
When I got back into programming in the late '90s' at uni, the only resources I had were the quarterly MSDN CDs, textbooks, and a growing collection of thick paperback reference manuals. In a previous era I taught myself BASIC, then later was a CS student when C, Pascal, and Fortran were the rage. In a decade, everything had changed and I now had compilers at home, not to mention working with objects and events...It was a brave new world and I was recently out of a bad relationship, unemployed, and living by myself...so one more chance at getting a degree...sorry, getting off topic.
Regarding debugging, my experience is that it is not taught in the classrooms and textbooks don't cover it well. I can still remember a colleague showing me how to set a breakpoint and F8 to actually watch the code step through the instructions! I was gobsmacked! ...how did I not know about this before? It was a true epiphany! 
I haven't bought a programming book in at least 10 years, even an ebook...though if I had my choice, I would prefer a hard copy over digital. I don't seem to have the time anymore to devote to a full understanding of the 'problem at hand', instead settling for Google searches and answers that are pertinent or can be twisted into a solution. Over time, I get a lots of example code for just about everything that needs to be done...if I can just remember where it is, which then usually leads to a Google search anyway. I'm not really learning the same way I used to. Just a thought!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
You know, Klingons do not debug... 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Ron Nicholson wrote: The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'
For non-fiction I like electronic formats (PDF preferred). I usually don't read these cover-to-cover, so the ability to search is very useful. The only exception to this for me are the O'Reilly "pocket reference" paperbacks, of which I have several. These are fantastic computer books. They are short, to the point, and they provide a nice breadth of information on their topic.
Fiction I always read as a paper book. Sequential reading electronically for me is distracting and unpleasant. Part of the problem is that most screens can't contain enough text to handle my reading speed, which is around 1500 words per minute. I spend a few seconds reading a page, hit the page down key, wait for the screen to update, repeat. Reading a physical book requires less time turning pages vs. absorbing text.
Ron Nicholson wrote: Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome?
I've never had the impression that practical skills were emphasized in collegiate programming classes. The more vocation-oriented schools like community college tend to lean more that way. In both cases students are expected to pick up those sort of experiences through internships.
I always thought it would be interesting to teach a course in practical software engineering as an adjunct instructor. I would organize the course around building and maintaining a software product. The product itself would be fairly minor. The point would be to get the students familiar with and thinking about the process from requirements, implementation, testing, release, maintenance, bugs, and so on. The temptation to be perverse about changing things in midstream would almost be irresistable  .
Software Zen: delete this;
|
|
|
|
|
On one hand, I've always thought colleges/universities shouldn't waste their time teaching how to work with the tool of the day, given how often they change and are made obsolete.
On the other, part of me has often thought why waste time teaching theory when they could show how to solve real-world problems with actual code that's in actual use. But then, I go back to that first thought. If you have a solid foundation and understand the theory and how it's applied (that point is important) then you're set for life. That's why I was never asked to put together a curriculum (well, that's not true, but I declined, as I figured I had a rather strong bias...that's another story for another day).
As I look back, I find there's just too much to learn. I'd hate to be back in the starting position today. That's why it's important to pick something, and learn it through and through. Make the wrong choice, and...well, this is why I'd hate to be back to my college years.
To (slightly more) directly answer your question: Teach enough of the debugging basics to let people each come up with their own methodology. There is no one-size-fits-all answer IMO.
|
|
|
|
|
Ron Nicholson wrote: if colleges who teach programming classes
Given some of the QAs we see I am not even sure that they are teaching programming properly. I had a question from someone the other day who said he was a teacher, but had no idea how to fix, or even find, the (fairly simple to find) problem. If that is the quality of teaching it is little wonder that we see what we do.
|
|
|
|
|
Richard MacCutchan wrote: who said he was a teacher,
I would like to hope that it was an excuse to try to get more help... but I would not bet anything
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I did feel a bit sorry for him when I read, "I have been staring at this all day, and feel like crying."
Instead of actually looking at the three lines of code that were the obvious root of the problem.
|
|
|
|
|
My schooling wasn't so far back, so I remember being weak on debugging while in school. I also had to train other students who were weaker than I was. I tend to view others as having different strengths and weaknesses and try to be tolerant. As an example, I am meticulous, and -fresh out of school- programmers tend to be much faster than I will ever be, but also overlook what are obvious code problems to me.
|
|
|
|
|
I think a big part of the problem is that students are taught how a language and some algorithms but not how to design robust code.
Recognizing that there will be bugs using such tools
- TDD
- SOLID design principles
- Error, and other Logging
need to be taught.
In addition, critical thinking and failure analysis are necessary too.
In most cases, you should be using the debugger to prove or disprove a hypothesis about what is causing and error.
TDD means you can verify the error is corrected and the correction hasn't caused other issues.
When I start using TDD while working for a large consulting firm, they were both impressed and horrified that while I was writing more code due to test code, I was completing assignments in 1/3 the estimated time and could prove to the client that the code completely met the agreed requirements.
The other thing they don't teach is that bugs multiply. If you don't squash them early, the patches and work arounds result in fragile code, and when the bug is fixed, many time the application crumbles due to dependencies on the error.
In short, writing code is not the most important aspect of being a good programmer.
Understanding the languages you use, the tools you use, and when and why to use them is.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
My dad used to teach programming in high school where he taught from the Programming first and second semester books. He felt it was important to teach the concept of debugging and finding mistakes in the lab portion of the class. In the class portion he taught going through your source code and tracing it manually. He felt being able to figure out what your program was doing before you compiled was important as he started programming when the University of Cincinnati go its first computer. At that time submitting just to get an error was both expensive and time consuming. I took his class and when I left I was able to get a developer job while going to school full time. Computers took a lot longer to compile than they do now, especially Windows GUI languages (as they were just coming out), so at one point a friend printed off a copy of his work before starting the compile and handed me the printout. Due to my dad's training I was able to go through, find the syntax errors before the compiler did and then produced an output and showed where it would not do what he intended and what it would do again before the computer could finish. I think it should be part of your first 101/102 classes the way my dad taught it. Both the debugging and the tracing skills are things that are critical to learn and showing how to do it with structured thought helps.
|
|
|
|
|
I generally agree with others that have posted by trouble-shooting is a way of looking at the world and breaking it down into manageable parts. However, one can't trouble-shoot what one doesn't understand at some medium to deep level. Surface understanding won't cut it. That's why universities don't teach debugging - the students are too new to really go there in any serious way.
But universities should do better.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
I've always thought about debugging in terms of tree pruning. Start at the top of the tree and eliminate branches that do not get you to the root of the problem.
In order to do that, you must have a mental picture of what the "tree" looks like. I think that is part of the problem with debugging today, the systems are so complex that no single person can put together that mental picture. Think any big software system, Windows, Linux, AEGIS, Space Station, etc.
Many moons ago on a super minicomputer I had a hardware problem that occurred once every 2-3 weeks, on a system doing millions of instructions per second.
The problem was easily to see (I was working in assembly language); the machine had word & half word instructions. If a half word instruction was followed by a full word instruction the assembler automatically generated a right hand half word NOOP so that the word instruction fell on a word boundary. If everything is working properly, the RH half word NOOP was skipped during instruction executions by the machine.
Except that every 2-3 weeks it didn't skip the RH NOOP (PSW was screwed up and pointed to the NOOP). I had a pretty good mental picture of what was going on, wrote a program to exercise I/O devices based on front panel switches and display each time the RH NOOP was executed in the front panel display (this was back in 1973-1974).
After fiddling to find the right combination of switches that would cause the counter to increment, the tech came in I ran the program & he fixed the issue in less time that it took to show him the problem.
Turned out to be a tap on a delay line that had to be moved to the next tap (5 nsecs).
|
|
|
|
|
Do you weigh a Millennial in Instagrams?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
A weighty subject indeed.
Unfortunately, an instant measure of mass is impossible because of Quantum. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
