I thought it might be interesting and helpful to share some of my best and worst experiences of teaching ICT or Computing. The Visual Basics for Applications (VBA) story I am about to relate definitely ranks as one of the best and most enjoyable.
I was teaching Year 10 (15 year-olds) and I set them the following problem:
Imagine you have been commissioned to set up a system for a clothes shop. The way the system works is that if a person spends over £100, they get free delivery. From time to time the shop runs a special offer, like buy one item and get the second at half price. Sometimes the company has to re-order stock too, so it has stuff on the shelves!
Your job is to set up a system that can handle these requirements. You can use whatever application you like: a flat file database, relational database, spreadsheet, Visual Basic, or VBA. You have 2 hours to complete the work.
The students got in with it, working in pairs. Some had chosen to tackle the problem using Access, Microsoft's relational database, while others opted for Visual Basic or a spreadsheet. Two boys who had decided to use a spreadsheet called me over. They had an idea for a macro that would perform tasks X, Y and Z. They said they didn't know how to get this to work, and asked me how they could do it.
"No idea", was my less than helpful reply.
But it was true-ish. I had a couple of vague notions about what sort of coding would work, but was not certain by any means. So the boys and I set to finding out. It was my habit to bring in books I had been sent to review, and a couple of these were mighty tomes concerned with functions, formulae and programming in Excel. Between us we consulted those, online help (which was sparse in those days) and Excel's built-in help. After experimenting with snippets of code we discovered what would be the best way to go, and I left them to it.
The thing that struck me while this was going on was that none of the other students raised an eyebrow at the fact that I didn't have the answer at my fingertips. They just carried on working.
Why was the lesson successful?
I regarded the lesson as highly successful because it had the following elements:
- The students were engaged in solving a problem that, while made up, was exactly the kind of problem shops have. So in that sense it was authentic.
- The students learnt (yet again) that there are several possible applications to use when solving a problem.
- They had to evaluate the advantages and disadvantages of each sort of application before embarking on the work itself -- because they knew from experience that I would be asking them to justify their choice.
- The students I worked with and I were collaborating as equals.
- We worked like real programmers do: came up with an idea, then tried bits of code, then refined the code in the light of testing results, then put it all together in the form of a working solution.
- The hidden curriculum message was that it is OK to not know. Nobody has to be a walking encyclopaedia, but you do have to know what you need to ask and how to ask it.
The difficulty with a lesson like this is assessing individual students. My approach tended to be to ask them to write up a report that answered the following questions:
- What did you do?
- Why did you adopt that approach?
- How does your solution work?
- What worked well?
- What didn't work so well?
- What would you do differently next time?
- List what each of you did in this activity.
I also had each pair of students talk me through their solution and demonstrate it in action, and then, once they had written up their reports, talked to them to find out more about the depth of their knowledge.
You might think that assessing the students whom I worked closely with might pose a challenge, but my view was that they were the ones who came up with the idea in the first place. All I did was point them in the right directions and made a couple of suggestions.
The prerequisites for a lesson like this are:
- Introduce students to a range of different applications, and their relative advantages and disadvantages. Obviously this takes time -- in this case I had spent the previous couple of months doing that.
- Establish an atmosphere in which it is OK for even experts to not know something straigt away.
- Use project work. See 7 reasons to use project-based learning and 9 challenges of project-based learning.
- Use authentic scenarios as far as possible. See 7 ways to make IT real.
Did you find this article useful? Do let me know!