On Teaching Technology Lessons Learned
01 Feb 2021 - Wyatt Johnson
One of the benefits of 2020 was it gave us the opportunity to investigate how we do things in technology education (admittedly whether we wanted to or not). Social distancing requirements forced technology teachers to try new approaches and some definitely worked better than others.
Here are the top “lessons learned” from Gateway Community College’s IT program field tests over the past year. My hope is if your job requires you to do some teaching/training, this might make your life a bit easier.
Students having the Access to Resources necessary to be successful has been a concern for years. The good news is there are many options available to help fill gaps. Internet access can often be made available with hotspots and there are multiple organizations available to help students gain access to some sort of computer at home.
All these variables are now something that we must take into account when designing courses. There might be multiple people video streaming on a limited bandwidth connection. Also, some students may be accessing course material with a budget-minded tablet, smartphone, or Chromebook, which provides marginal performance. Using pre-recorded lectures, followed by a WebEx or Zoom-based separate discussion time for questions and demonstrations, is one way we successfully address this issue. If this will not work for your course, be sure to communicate the technology needs of the class with students upfront. That way, they know the requirements and you can design a workaround, if necessary. Our campus IT folks just set up a remote desktop solution for students off campus who need access to a “real computer” to do things such as VirtualBox OS installs or run software that requires significant resources. This should be a big help in the coming semester.
Alignment is a key when it comes to preventing the cardinal sin of confusion in a class.
Tell students explicitly why they need to know what they are learning, topic by topic. Then, after you cover the material, have activities that allow students to work with the content. Follow this up with a way to assess the learner’s understanding of the material. Students should never be asking “what is the point” of any part of a class.
One example of this is when the students in introductory security classes learn about symmetric vs. asymmetric encryption. After discussing both options, the learners receive access to both types of encryption tools and the chance to use both and explore how they work. Their assessment is to send the instructor email messages using both types of encryption. The symmetrically encrypted email attachment is usually not a challenge but working with a two key system often gives students moments of clarity that makes how asymmetric encryption really functions “click”. In every security class I have taught, inevitably there are students who do not really understand how the system works until they actually try to use it and have that “ah-ha” moment.
This leads right into Hands-On Learning. Once you understand what to do, nothing beats doing it.
Some up-front information is usually necessary for context so that students know what is going on and have a reason to care. Also, provide enough scaffolding so the students know they are at least headed in the right general direction, but must choose how to get there.
A good way to approach this is to think of yourself as a project manager for the student’s project, there to offer support. For example, all students enrolled in our Cisco networking course are required to do a final project. We spend weeks looking at how routers and switches work and are configured one step at a time. The students then must design, build and document a small business network. Some of the steps given to the students for building the LAN portion of the network include:
Build a base “generic” LAN configuration that meets the shared requirements of each sub-network.
Modify as needed, then implement the base LAN config to each piece of the business’ network.
Test the LAN segments (ping the router, switch, and default gateway within each LAN) and troubleshoot issues as you find them.
This gives students clarity on a process where they are not yet an expert while still making it their responsibility to figure out what commands to type in to make everything work, design a topology that makes sense, etc. However, we do want to avoid making a student feel “totally stuck” without knowing how to move forward. That is when students tend to give up because success seems utterly unachievable.
As for Testing, stop and consider if a given exam could be replaced with a project of some kind. Perhaps give students a base on which to build. The foundation is laid but they must pull ideas together to finish the project. This has the added benefit of making it harder for students to successfully cheat. These days, the answers to most multiple-choice questions can be found with a quick web search so multiple-choice test results can be an indicator of search engine proficiency more than actual understanding of the material.
Ultimately, much teaching success relies on providing students with opportunities for failure. Filling the right answer in a blank is of little value compared to troubleshooting actual problems. A student’s ability to simply memorize is not something I am all that interested in exploring. Certainly, it can sometimes be one step of a larger process, but not our end goal. Bigger, more open-ended projects that require a student to create something or work with actual situations are more interesting for everyone.