Are We Training Our Customers to Be Dumb?

February 16, 2010

tags:
3 comments

During the past few years at Sela, I’ve authored several courses and participated in the development process of several dozens more. They covered a great deal of topics – ranging from the gory inner workings of Windows and the CLR, through new technologies like LINQ and Windows 7, and all the way to introductory courses to C# programming. I’ve also had the experience of designing and developing courses in a variety of styles – the “Sela style”, which focuses on the brilliance of the instructor delivering the course and slightly deemphasizes the minute details in student handbooks, the “standard international courseware style”, which is all about attention to detail and greatly elaborate lab instructions, and some combinations of the two.

I always preferred concise exercises and labs that emphasize the student’s ability to think and process the material, over exercises that involve straightforward typing or copy-pasting code from the lab manual into Visual Studio and seeing it compile. And I always wondered if it was just some mentality thing here in Israel, or a personal preference I have because I like teaching difficult courses to an audience of highly experienced developers. I also wondered if the reason some customers prefer and training companies encourage the drill-down, copy-paste labs was a matter of dumbing down the lab and making sure everyone in the classroom is capable of finishing it within the allotted time; not to mention that a short and concise lab definition might seem vague and lacking in detail to some audiences.

But one thing just occurred to me. Take a look at this exercise from an introductory mathematical analysis course, one of the first things I found by looking up “mathematical analysis homework” on Google:

Let f be a monotone function on an interval. Prove that f is continuous iff its image is an interval.

Can you see what I’m getting at? OK, here’s an example of an exercise I used a few weeks ago when teaching a concurrent programming course:

The reader-writer lock design shown in class uses two mutexes and an event.  Convert this design to use only a single semaphore. Prove that there is a possible deadlock if multiple writers attempt to acquire the lock. Fix the problem by introducing a mutex (additionally to the semaphore).

Compare and contrast to this hypothetical example from today’s typical software industry “courseware”:

In this task, you will implement the IComparable interface so that instances of your class can be sorted by external sort algorithms. Open the MyClass.cs file in Visual Studio, and navigate to the MyClass class definition. (To open a file, click File –> Open.)

Declare that your class is implementing the IComparable interface using the interface implementation syntax, as follows:

internal class MyClass : IComparable {

Implement the CompareTo method. To compare the parameter to your object, cast the parameter to an instance of MyClass. Next, compare the values of the X and Y properties of the parameter to the values of the X and Y properties of your instance (this).

[…several pages later…]

Congratulations! In this exercise, you have implemented the IComparable interface so that users of your class can compare instances of it without being aware of your class’ implementation details. For more information about the IComparable interface, consult the MSDN documentation at […]

It’s mind-numbing to read just this passage, not to mention the 30+ pages of standardized jargon it is usually surrounded by. Are we deliberately dumbing down our training materials and by extension the developer community? What’s the ultimate objective of having every step of the way explained in excruciating detail? How is it possible to learn anything without even trying to perform the task on your own before copy-pasting code from the student manual?

I’ve officially given up trying to understand this phenomenon. But I do know this: Given the choice between short and concise instructions and a 30+ page lab document, I would choose the former over the latter even if it were a million times harder.

I feel that a good litmus test for a properly designed lab exercise would be the following relation:

Lines of Text in Lab Manual / Lines of Code Written by Student < 0.1

Add comment
facebook linkedin twitter email

Leave a Reply to Sasha Goldshtein Cancel Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

3 comments

  1. Niall ConnaughtonFebruary 17, 2010 ב 12:24 PM

    I don’t suppose you ever do labs in the UK?

    Reply
  2. Brian FeuchtFebruary 17, 2010 ב 5:22 PM

    Perhaps each example is catering to different people’s learning styles… Some people learn by thinking and other learn by blinding copying code from a book?

    I prefer having my boundaries pushed and learning through discovery, but I have plenty of coworkers who learn by copying and pasting code. Most people have a preference on who they would want on their development team I suspect 🙂

    Reply
  3. Sasha GoldshteinMarch 28, 2010 ב 1:34 PM

    Frankly, I don’t quite see what you can learn by blindly copying code out of a book. After completing this kind of lab, you can’t repeat the same task on your own. Isn’t that the purpose of learning?

    Reply