How to organize a programming course?

Question

I've been given the task to train our manual testers to become developers in test (write test automation!).

Some have basic programming knowledge (either dabbling in PHP or reading stuff) and some who have no experience. Note that I do have teaching experience, but with real students, not employees, and one concern is that they will not put extra hours except the 20% management gave them for the transition.

Language to be taught and used: C#

We have 8 hours per week to do this and should decide if they will make it in 2 months. I am thinking of a combined approach:

• use a manual such as Head First C# (although I'm not happy with the labs, they're mostly games and I don't want to add UI complexities)
• have them read from the manual
• do labs with them, solving more and more difficult problems and explain the theoretical stuff as well
• have them do a bigger project towards the end

Some questions:

• do you have a better suggestion as far as manuals go?
• do you have a better approach? Focus less on labs?
• what kind of assessments should I use and how often?
• should I let them do a bigger project (bank system or small game) and how much time should I invest in that?
• ideas on labs?
• other resources ?

Any other tips would be most welcomed!

Thanks!

Answer 1

Make the whole "class" project-based, not just the end.

Figure out what you want the project to be, and then piece it apart into sections you can turn into lessons. Each lesson having an assignment which ends up being used directly, or involved in the final project.

For each area, Do not provide them with all of the necessary info, at least easily (aka make sure they learn that google is their friend). Give them enough so they don't feel overwhelmed, not but enough so that they can complete all of the assignments/projects using the information you provide. It is very important that they pick up the same skills we use everyday in our work (knowing when to check manuals, forums, SO, etc...)

Also, consider making at least the final project a group project. People think differently. Group members can help fill each other's gaps in terms of their knowledge.

Good luck! I've taught programming in various roles during my time in uni and it had a very big impact on how I approach the subject matter.

Oh! and students-are-students, the only different here being that your student's motivation might be more directly financial than the norm (which is not to say regular students motivation's aren't financial; I attended uni during the dot-com boom)

Answer 2

I'm a big fan of the pattern of teaching used by Ruby Koans. They give you a bunch of broken ruby tests and have you progress through the tutorial by running them, watching them fail, then fixing each one as you go. I've reviewed it myself and used it to acquaint a few friends with the Ruby language with notable success.

I would recommend creating a similar battery of tests using your language/framework of choice. Each "class" would consist of you covering the basics by fixing basic tests via the lecture to give them an idea of the basic concepts for that lesson. You can have them working along on their local system to fix the tests as you fix them. At the end of the lecture, you can have them repair a separate-but-related test file, asking for assistance from you as necessary.

Not only will this teach them the language, but they'll also be learning how to write tests as a consequence.

Answer 3

I would do something that motivates them. I don't think reading a book will, it doesn't work with my students, and I believe it only works with self-teaching people, which is not the majority. Determining what motivates them seems tricky in your case.

My approach would be to do lab sessions with them and repeat the following cycle:

1. Explain something briefly (like 20-25 minutes). The explanation should be like a screencast, with you writing code and compiling, and running it. That is, you "doing" something useful. In your case, useful might mean something related to their job (but not always).

2. Propose some exercises that you know they can do easily with what you have explained. The first exercise could be simply to replicate what you have done. And the next to extend the solution in certain ways.

3. Spend time with everyone to see how they are doing, and then spend more time with the ones that are not following so quickly (and give the good ones more work so that they are not bored).

If you know the subject well, this is an approach that works very well for me. The idea is always to try to do something useful during the class. I'm sure Head First C# contains some ideas, but I haven't read it.

As an example, the other day I did the following (my class is C++, and I was teaching STL containers, and efficiency). I gave the students two text files: a book from Project Gutenberg, and a complete word list for the language of the book (in my case Spanish). You can find both on the Internet. The idea was to produce a list of those words that appear in the book that are not in the word list, like names of people, places, whatever. It was not perfect, since the word list in Spanish doesn't contain conjugated verbs, and therefore a lot of wrong stuff came out in the solution, but the idea is that it was a small project for the session (2 hours), and the students were a little curious about what would come out. The best students will do it quickly, and the others will often be driven by envy, and work harder just to catch up with the others. That is always a good motivation, I exploit it a lot.

Now, for this you would need to think about 4 simple 'projects' every week. While thinking about the problems, I suppose you will see connections between them and could make them last a couple of classes or more, and end up with something more substantial. To put another example, in this course I mentioned already, we ended up writing a simple SRT (subtitles) editor in Qt. Nothing fancy, but they found it useful, and that counts a lot.

In summary, any programming class needs motivation and I think there is no better motivation than to reveal the computer as an incredibly powerful tool to do repetitive and automated stuff. If you can quickly show that to them, everyone will notice and they'll be interested. By the way, at no point I did say this was easy.

Oh, one last thing: avoid the Fibonacci series and the primes, they bore everybody except the nerds.

Answer 4

With limited time, you should do many small examples on all important things, and the most conmon pitfalls. For the rest, You better assume, they are intelligent beings.

Answer 5

The biggest issue I see here is that your developers aren't writing unit tests before a check in occurs. Its great to have that pseudo-whitebox testing that occurs here, but I think you are going to see a lot of unit tests written by the team look like this:

public void testApple(Object apple) throws Exception{  
return;  
}

Just to satisfy the requirements of a passed test, this is equally true for developers. I would recommend having them read the documentation within the classes that they are writing tests for and if it doesn't make sense then the developers need to re-write the documentation. Also showing them how to execute a unit test via a script and integrate it into CruiseControl or whatever build tool you use would be of the most benefit.

Answer 6

Plan on replacing 1/2 of them with experienced DTEs (development test engineers). Start recruiting the DTEs now. Some people are just not capable of writing code, or at least code that makes any sense. You need to practice group code reviews for each test before they check them in. I would create a number of test templates where you copiously explain what you are doing in each step.

Answer 7

Try out with something simple and then increase the level of complexity, make sure simple things are understood before going for complexities because complex things evolve from simple things.

Answer 8

You could also get a subscription to TekPub.com, they are starting an excellent series on C#, presented by the Chuck Norris of StackOverflow - Mr Jon Skeet!