Chris Lambacher <[EMAIL PROTECTED]> wrote: > On Sun, May 07, 2006 at 11:57:55AM -0700, Alex Martelli wrote: > > > [1] I'm considering introducing bugs or misdesigns that have to be > > > fixed > > > as part of training for the purposes of this discussion. Also the > > > > Actually, doing it _deliberately_ (on "training projects" for new people > > just coming onboard) might be a good training technique; what you learn > > by finding and fixing bugs nicely complements what you learn by studying > > "good" example code. I do not know of this technique being widely used > > in real-life training, either by firms or universities, but I'd love to > > learn about counterexamples. > > When I was learning C in university my professor made us fix broken programs. > He did this specifically to teach us to understand how to read compiler > warnings/errors and also how to debug software. The advantage of this in the > tutorial setting was that the TAs knew what the error was and could assist the > people in finding bugs in a controlled environment. When I later worked with > people who did not go through this training I found many of them had no clue > how to decipher the often cryptic C/C++ compiler warnings/errors (think > Borland Turbo C or MS Visual C++, GCC is pretty good in comparison) or where > to start looking for a bug (an affliction I do not possess).
Great to hear that SOME teachers use this technique. I think it would be about just as valuable with any language (or other similar piece of technology). Alex -- http://mail.python.org/mailman/listinfo/python-list
