15

I give students targeted debugging exercises to make them aware of common traps that they can fall into while coding, and I believe that this is beneficial to them. Certain errors come up all of the time, and pointing them out can be a real time-saver for students when they code their own labs. I also give out small bits of badly-formatted code, with poor ...


13

In the engineering world, being able to read, understand, debug and add on to existing code is MUCH more valuable skill than writing code from scratch. Too often, programmers will opt to rewrite a block of code from scratch rather than (or being intimidated by) spending the time to understand the existing code. This leads to re-introducing bugs that have ...


13

Debugging is more a craft, an art, than a science. That's where the pedagogical challenge lies. That said, here are a handful of tools/techniques I used to varying success: Model the debugging process. I would project sample working code, break that code, and talk through the error messages (and how to read them). Trying to instill the patience and ...


11

I was a Girls Who Code mentor this year. The exercises provided by GWC included "debug this program" activities on a regular basis, so students got used to reading and understanding error messages. By the end of the year, when they were doing their own project, they were quite competent at debugging.


8

I do it the other way round: I enourage my students to compile and test very often! Of course, just changing random lines of code until the result seems to work is not a good idea and this should be avoided. I try to encourage thinking about the code by writing the essential parts in pseudocode first and writing the documentation of funtions prior to ...


6

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill): teach them theory show them good code as an example have them write code it's implied that they will need to do SOME debugging to "evolve" their code to a working state have them debug others' not-so-good code Start with the theory. ...


6

Because debugging can be learned very easily through experiance, I'd try and help the students self-correct when they make mistakes. When correcting mistakes, ask the students to type the corrections themselves, so that the corrections will be better ingrained in their minds. Also try to correct them by leading them through the debugging process. You can ...


6

In places that use the ideas of agile software development, the usual way is to just let the newcomers pair with the more experienced members in all tasks. In your case it would consist of a lot of pair programming. But you would need to do it correctly. It isn't one person programming and the other person watching. Both participate, but in different ways. ...


6

Back in my day (which wasn't that long ago), many of the tests for my programming courses involved writing code on a piece of paper, with a pencil. In this environment, I couldn't rely on the compiler at all. Your teachers might not want to do this because it involves a lot more hands-on grading, which might not make sense for your class size. I can also ...


5

My philosophy is "use professional tools" and creating an experience that is like being in real programming shop. The compiler can help you get rid of silly errors very fast without wasting time on unnecessary puzzling. If professional devs avail themselves of this, I think my students should have it. Anyway, most of the compilers we are using are OSS ...


5

Because it's a meaningless obstacle Putting an upper limit on compilations is like telling a car manufacturer that they must build a new supercar, but are only allowed to test drive it a few times. This means that you're pushing your developers/mechanics to theorize about whether something would or wouldn't work, instead of actually finding out. ...


5

You've said that having an identical environment for everyone would be an incomplete solution, since students' code could still work "by accident" in that environment. One option would be to provide access to two or more sufficiently different environments which would be the same for everyone; such environments could be provided in several ways, for example: ...


4

I agree that learning to debug code written by someone else is a critical skill, but I do not think it can replace having to write and debug your own code. Writing your own code is a critical design exercise and students need to continue to develop their design skills. Debugging is a critical skill, but if students cannot create and debug efficient code ...


3

Your student/staff ratio is pretty unfavorable. This makes everything difficult. If you had a few more TAs or could find the schedule time, I'd make one of the TAs the person to handle all such technical issues. It would need to be the one with the highest "geek cred" I think. But debugging stuff shouldn't be the instructor's job. Part of the job of the ...


3

While limiting use of compiling and testing, will stop same bad behaviours, it will also stop the best behaviours. Test driven development is one of the best ways to write software, and it involves a lot of compiling and a lot of testing. However it is not about guessing (the shot gun approach). Test driven development Test driven development is about doing ...


3

A few Java specific examples come to mind: Using % with a negative number - I recently came across this and had to remember how Java treats modulus v. remainder (cf. this thread) Listing switch statements without the proper break; at the end of each case - maybe something that can be seen right away, but stepping through each line would be good to visualize ...


3

Writing code is essential, and a part of that is debugging (your own) code. If you can't debug your own code, you won't get very far, unless you write perfect code the first time, every time. Debugging someone else's code introduces students to things that debugging their own can't - different styles, and different approaches to problem solving, that ...


3

I've been a software engineer for over 25 years and in my opinion, the two skills are just different. What you need to know and how you spend your time is very different when conceiving of a new design or code, or fixing something that exists. The two are both required to some extent on most projects but are very different activities. One of the things ...


3

I would say that it is helpful to have them write their own code in the beginning to better understand the processes that go into writing for an application. It gives them a strong basis and practice with finding errors in the code they're most aware of: their own. Think about it; if they already know their thought process and procedure as to what needs to ...


2

Even though I'm not an educator, I work with programming and personally I don't think that you should teach your students on how to debug (don't curse me!). What I'd do is to present them the debugger and say what it is for, followed by a practical example. Then I'd give them code with bug(s) and tell them that they should use a debugger help them find the ...


2

Neither is "better" or "worse" - just different. Writing your own code and understanding someone else's code well enough to debug and improve it are definitely distinct skills, both of which are necessary to be successful in industry. It seems like people are rarely given a lot of experience in the latter skill in college, and some curricula don't teach ...


2

There's a lot of discussion about how people who work in industry spend a lot of time working with other people's code. That's true, but in my opinion, the key skill for dealing with other people's code is skill at refactoring. If you're going to teach new developers how to work with code developed by others, a class on refactoring would be invaluable.


2

During my 4 years of school debugging was never taught to us. We were only quickly shown that if we get an error, set a break point, see where it breaks and you know where the error is. Looking back, I can understand why we didn't cover debugging and it was because there was so much material to teach that there just was not any time to cover it. As a ...


2

I would try to focus in on the kinds of errors that beginner programmers get stuck on, to imitate as closely as possible the kind of situation that they would want a debugger for. So, I might code this method, which contains exactly the sort of subtle mistake 101 students regularly make, right in front of them: public static boolean compare (String a, ...


2

I prefer not to use a debugger, myself, for the simple reason that they are frustrating and don't actually run the same program (breakpoints and such can modify the logic). There is not a lot of actual science in Computer Science, but finding out why programs go wrong is an exception to that. You have an artifact that is acting in a strange way and you ...


2

As well as pair programming, look at other agile/lean techniques. Test Driven Development. What does done look like? / definition of done (scrum). Short release cycles (scrum). Minimise work in progress (scrum/kanban). Shared ownership (scrum/XP/lean). Local product owner (XP/scrum). To teach Test Driven Development, you can start by writing the tests ...


2

As early as possible in the course, and again when appropriate examples arise, you should "round up the usual suspects." (It's a Dick Tracy reference, but that does not really help.) You could include this as a "sidebar" feature of many classes. And you could have a "crib sheet" listing the most common such mistakes. For example one frequent mistake is ...


2

You could encourage them to use tools like compiler warnings and valgrind to try to check for bugs.


1

Is this using different versions of gcc? Have the students compile with full warnings and with different level of optimizations. I wonder: could the emitted warnings be of a kind that the compiler will only warn about at a certain optimization level? Either way: making the students see the effects of this type of side-effect is very valuable in itself. Now,...


1

If you mean by "debugging" teaching students to use a debugger, I wouldn't do that. However, having students finish or repair a program that you create is a useful early exercise. In particular, you can give them a program larger than they would be expected to write themselves. It needs to have excellent design/coding. But you have either removed or ...


Only top voted, non community-wiki answers of a minimum length are eligible