Thought for the ages
-
I'd disagree to an extent. Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened. I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course! :laugh:
"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!
OriginalGriff wrote:
Debugging is a state of mind
As is the whole of the software development lifecycle. And it was pretty obvious to me, even during my first exposure to coding, (on a TOPS programming course), that some people got it and others never would. I've always believed that it's a 'knack', that some people have and some don't.
OriginalGriff wrote:
I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course!
I think you've nailed it! As farmer's lads, my brother and I spent many hours fixing up all sorts of unreliable stuff - including a BSA Bantam 125; a Triumph Tiger Cub, a Lambretta 150; and a Triumph Tiger 350 - which was way too heavy, (and fast), for us. And, occasionally, (when they were working), actually riding them around the fields. Any programming aptitude test should require applicants to figure out that a carburetor jet has muck in it - and be able to fix it! :-D
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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.
-
OriginalGriff wrote:
Debugging is a state of mind
As is the whole of the software development lifecycle. And it was pretty obvious to me, even during my first exposure to coding, (on a TOPS programming course), that some people got it and others never would. I've always believed that it's a 'knack', that some people have and some don't.
OriginalGriff wrote:
I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course!
I think you've nailed it! As farmer's lads, my brother and I spent many hours fixing up all sorts of unreliable stuff - including a BSA Bantam 125; a Triumph Tiger Cub, a Lambretta 150; and a Triumph Tiger 350 - which was way too heavy, (and fast), for us. And, occasionally, (when they were working), actually riding them around the fields. Any programming aptitude test should require applicants to figure out that a carburetor jet has muck in it - and be able to fix it! :-D
I can see your viewpoint. On the other hand, I can't do anything with my hands in terms of mechanical things, construction, fixing the plumbing, etc. However, I used to be able to earn programming languages on my own (never took a course on a single one of them), write programs real fast, make few mistakes in writing them, debug my programs and systems written by others from core dumps (what the heck are they?), have an intuitive grasp of logic, understanding of systems at a high level, etc. That came in handy as a consultant too. I think an analytical mind is sufficient to work in programming. In fixing tractors, motorcycles, automobiles, etc., you develop logical thinking because for all those things to work, you needed to gain an understanding of how those IC engines worked, how you had to time the spark for the engine to fire, etc. If you were into construction, I can see how working with the HVAC (heating, ventilating and air conditioning) systems or the water heating system would help develop your thinking and troubleshooting ability. However, if you only pounded nails day in and day out to frame the building or to nail the Sheetrock to the walls or just painted buildings for months on end, I don't see much benefit from those activities.
-
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.
-
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'd disagree to an extent. Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened. I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course! :laugh:
"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!
-
The very first "larger" (i.e. 4000 instructions) program I wrote was a TRAC interpreter on the PDP-9 in assembler language (I had some experience with writing assembler programs on the PDP-8). (TRAC, Text Reckoning and Compiling was an interpreted language, essentially a big macro expander, it was popular in the late 60-ies and earliy 70-ties, search for Calvin Moors for details). As it happened, the PDP-9 had an excellent debugger -named SCALP - and since the program contained lots of pointers I really needed this debugger from time to time (the PDP-9 had just one accumulator, no further registers). Ever since that time I told students - I kept working in academia - to pay attention to debugging and I gave some demonstrations. But giving a "course" in debugging, no. It is too dependent on the project being debugged, so the basics are that you can interrupt the processing (breakpoints), inspect registers and execute step by step. Of course on the PDP-9 step by step means executing single instruction, while with e.g. the current gnu debugger (I must admit, I develop under Linux) provides lots more possibilities. As a side note: one of the nice "features" of the PDP-9 was that you could reduce the clock speed, and - when you were experiences - could follow the execution of the program on the lights on the control panel. Came in handy when your program was looping. Conclusion: yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
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?
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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.
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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."
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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.
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. 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'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
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).
