Skip to main content

Online, peer-taught, outcome-based, and instructor-facilitated teaching

From some time I have been thinking of the right way to teach a programming course. Something I have noticed from the way I learn, as well as by having taught Java to college students and corporate participants, is that programming is not learned well if it is detached from practice and discussion. In fact, practice and discussion are the most important aspects of learning how to program. Here are some numbers from the National Training Laboratories, Maine, USA, that point to how retention rates differ for different learning approaches.

Research shows that discussion, practice, and teaching are the most effective ways to learn. My own learning experience also validates this finding. When I simply read about a programming technology, I might forget it in a few days, but when I practice it, the learning remains with me for longer, and when I teach something, I retain it for much longer, and even more importantly, I also grasp the fundamentals in a better way.

All of these concepts can be introduced in the classroom, but for some reason they do not work very well. Many students are shy to ask questions. The time we have for a lecture is fixed and there is a set agenda for what has to be completed in the lecture. There is also the problem of differing learning styles and speeds. Different students learn at different rates. In a classroom, the lecturer always has to be at a median rate, which is too fast for some and perhaps too slow for a few. In other words, the median is not really the best pace for a lecture. Practice is usually in the form of lab exercises. The purpose of the labs is to complement what is taught in class. This method of teaching does not prepare students to be good software developers. Perhaps this is the reason why people in the industry say that many software graduates know the syntax of programming languages, but they are'nt good programmers.

To help students become good programmers, the primary form of learning must be through lab exercises, using the classroom to discuss doubts, and clarify concepts. I am proposing that we invert the current method of lectures complemented by exercises and discussions, and make projects and discussiosn the primary vehicle for teaching, complementing them with lectures when necassary. We must teach programming in a way that supports experiential as well as discussion based learning. Putting the focus on practice, will also help students learn at a pace that is best for them. Another factor we commonly see in most classrooms is that the teaching is usually directed from the lecturer to the students. Sometimes technology changes so fast, that it is very difficult for one person to keep up with everything. Often, people who have work in the industry have dealt with different types of real world situations (especially fighting fires). This gives them a somewhat unique practical perspective, that goes beyond the textbook. Please don't get me wrong. I am NOT suggesting that a lecturer knows less than a practitioner. Not quite. Even among working professionals, each individual will not know everything. What I am suggesting is that a community of practitioners and academicians have a lot of collective wisdom together. This collective wisdom will be way more beneficial to students than the wisdom of just one person. By learning from a community of practitioners, students will learn not only the theory but also real world practical usage (along with pitfalls and best practices) of a technology.

If we are to facilitate courses the "peer taught" way, we need to create a network that engages students with highly experienced and motivated practitioners. Unfortunately, such people are sometimes very busy with deadlines, and very often live in different towns. How do we get them to mentor students? To enable such a network, we might have to move away from traditional face to face lectures. One thing I hear very often in relation to teaching is "nothing can replace face to face teaching" . Before I go ahead and offer my perspective, I would like to say that I absolutely agree with the benefits of face to face interaction in a learning environment. But I also believe that with the new breed of collaboration/social tools (VOIP, blogs, wikis, newsgroups), coupled with the participatory culture of the new generation, we can create a model of learning that is experiential, based on discussions, and involves mentors (along with the lecturer) from different places. I have very often come accross people who would love to teach, but are unable to travel to a university campus. If given the opportunity to teach online, they would gladly give it time and effort.

For such a teaching and learning model to work, we must first create the right infrastructure and some guiding principles that will help the students, lecturers, and industry mentors.

Let's tackle the infrastructure first, and make a checklist of things we need:

  • Place to publish course descriptions
  • Ability for students to enroll for a course
  • Mechanism by which groups of students can work on projects (source code versioning, bug tracking, forum)
  • A place where students can ask questions (and get answers)
  • A way for the students to log their learnings, progress on the projects, etc
  • Mechanism for real time discussions, lectures
  • A way for mentors to provide feedback (and grades... ughhh) to students
  • A calendar for announcing important dates, etc

If you think of more, please add them in the comments section. I will appreciate your feedback.

Because the course may involve mentors from different cities (or even countries), all of the above features must be web enabled. Most good learning management systems offer course definition, enrollment, grading, discussion forums, calendars, blogs, etc. In fact a good learning management system like Moodle, will take care of almost all the above requirements, leaving only source code versioning, project collaboration, and real time collaboration. For versioning, we can either install CVS/SVN internally or let the students host their projects on hosted services. For project collaboration (bug tracking, forums, etc) , we can use Bugzilla, and web based newsgroups. For real time collaboration, we can utilize the classroom for lecturers and mentors who can go to the institute physically, and web based tools like Skype and Yvew for voice and slides. A simple way to get started is, install Moodle, install CVS, install Bugzilla, install Skype, and create an account with Vyew. And offcourse give access to students and mentors to relevant systems. Even though this is really simple, I prefer an alternate configuration, which I will describe below.

I am a bit uncomfortable with the above configuration for a couple of reasons. I would rather that students keep their blogs on a public website. That way they can retain their blogs even after they graduate (this may not be appropriate for school students for safety reasons). I would also prefer to use web hosted version control as provided by Google, or Sourceforge. This is because they provide many more facilities beyond version control. They provide bug tracking, forums for discussing issues, file downloads, and document hosting. Also since these services are hosted on the web, students can make their work available to future employers for viewing online. My personal preference is to install Moodle, let students host their blogs (which will be used as their learning journals) on a service of their choice, and host projects on code.google.com, or sourceforge.net . One thing to remember before hosting projects with these or similar services is that the projects will have to be made available on an open source license.

Google also provides "Google apps for education". They provide very good collaboration features, but you will have to supplement it with a course management software. Incidentally, such a software is available as a hosted option.

As you can see, there are several options. A different combination of software will be suitable for different institutes. Also there may be several alternatives for the services I have mentioned. For example, I mentioned Vyew for synchronous slide sharing. However, there are other services like GoToMeeting, being one of them. Similarly, there are other learning management systems besides Moodle. Moodle is free, feature rich, and also simple to understand and use. I believe there are other free options, but I cannot recollect them at the moment.

Regardless of the software and services chosen, what's important is that we support collaboration that is synchronous as well as asynchronous, and make appropriate information available to all concerned in as seamless a manner as possible.

Once the infrastructure is in place, we have to define a set of guidelines to help the students and mentors. I suspect none will have taken or mentored a course offered in this mode. So it is very important to have a set of guidelines, nobody gets stuck on how to move ahead. I will talk about the guidelines in a future blog post.

Resources:

  • Free blog hosting is provided by Blogger, Wordpress, and several other.
  • The Shuttleworth Foundation is also doing some interesting research on peer taught software engineering.
  • Konrad Glogowski publishes an excellent blog on learning (especially using a conversational technique of teaching with blogs in the classroom).
  • Christopher Sessum also publishes an excellent blog. He talks primarily of teacher education, and the role of new media in education.


Note: This text was originally posted on my earlier blog at http://www.adaptivelearningonline.net

Comments

Anonymous said…
Bachelor’s degree programs are developed for people who are
serious about mastering diagnostic medical sonography.
Workers who are already in a health care field may find a one-year certification
program acceptable to their employer. 5 and that my reading was barely outside
of this range at 2.

Take a look at my homepage Cardiac sonographer Guide

Popular posts from this blog

My HSQLDB schema inspection story

This is a simple story of my need to inspect the schema of an HSQLDB database for a participar FOREIGN KEY, and the interesting things I had to do to actually inspect it. I am using an HSQLDB 1.8 database in one of my web applications. The application has been developed using the Play framework , which by default uses JPA and Hibernate . A few days back, I wanted to inspect the schema which Hibernate had created for one of my model objects. I started the HSQLDB database on my local machine, and then started the database manager with the following command java -cp ./hsqldb-1.8.0.7.jar org.hsqldb.util.DatabaseManagerSwing When I tried the view the schema of my table, it showed me the columns and column types on that table, but it did not show me columns were FOREIGN KEYs. Image 1: Table schema as shown by HSQLDB's database manager I decided to search on StackOverflow and find out how I could view the full schema of the table in question. I got a few hints, and they all pointed to

Fuctional Programming Principles in Scala - Getting Started

Sometime back I registered for the Functional Programming Principles in Scala , on Coursera. I have been meaning to learn Scala from a while, but have been putting it on the back burner because of other commitments. But  when I saw this course being offered by Martin Odersky, on Coursera , I just had to enroll in it. This course is a 7 week course. I will blog my learning experience and notes here for the next seven weeks (well actually six, since the course started on Sept 18th). The first step was to install the required tools: JDK - Since this is my work machine, I already have a couple of JDK's installed SBT - SBT is the Scala Build Tool. Even though I have not looked into it in detail, it seems like a replacement for Maven. I am sure we will use it for several things, however upto now I only know about two uses for it - to submit assignments (which must be a feature added by the course team), and to start the Scala console. Installed sbt from here , and added the path

Five Reasons Why Your Product Needs an Awesome User Guide

Photo Credit: Peter Merholz ( Creative Commons 2.0 SA License ) A user guide is essentially a book-length document containing instructions for installing, using or troubleshooting a hardware or software product. A user guide can be very brief - for example, only 10 or 20 pages or it can be a full-length book of 200 pages or more. -- prismnet.com As engineers, we give a lot of importance to product design, architecture, code quality, and UX. However, when it comes to the user manual, we often only manage to pay lip service. This is not good. A usable manual is as important as usable software because it is the first line of help for the user and the first line of customer service for the organization. Any organization that prides itself on great customer service must have an awesome user manual for the product. In the spirit of listicles - here are at least five reasons why you should have an awesome user manual! Enhance User Satisfaction In my fourteen years as a