I recently had the opportunity to develop an upper-year course at Fleming College about advanced operating system usage. While the course was called Operating System Theory, I quickly transitioned away from the namesake. A focus on theory in a college environment seemed counter-intuitive. I took the approach of looking at common industry OS problems and developing an outline/learning outcomes based on them. It was an experiment, where the stakes were high. Reinforcing key skillsets which would allow the students to exit the course confident in facing almost any system administration issue.

I didn’t stop there, however; I reached out to as many people as I could across all different sectors to get their feedback on topics. In addition to that, I asked if there was anything specific they would love to have covered as a skillset. Their feedback was amazing, and I could tell most of them were eager to see how this would turn out. I cannot thank those that responded enough for their contributions, it was a thing to see.

I am in no way classically trained as an educator. Nor do I have any certifications in the area of education. I did attend a post-secondary institution (Trent University), however opted to dropout and pursue my career (didn’t everyone?). So, all of this, while based on my own independent research is merely my thoughts and opinions.

Fleming Tradition

The typical lab setup I’ve seen so far at Fleming College is that students attending a class are given a sequence of steps to follow. Some questions along the way are asked to engage the student in what they were doing. The material, for the most part, would be covered in a lecture prior to the lab, if the scheduling worked out. This method/arrangement has been around since the dawn of time, or maybe I should say education. There are merits in it, but for an upper-year course, I felt that a more real-world approach would be more beneficial in getting the students ready for workplace requirements.

I feel as if I need to be explicitly clear, the existing method of content delivery has been around since before I was born and has a proven track record in educational faculties around the world. I am in no way saying it is wrong, bad, negative, or dated even. I am, as always,  trying to improve and innovate on anything I touch. Naturally coming into an environment such as this, I would look at what I can bring to the table, and what I can do to enrich the education of my students.

Many Thanks

Like anything I do, I try to do my best.  I also recognize this whole education thing isn’t exactly my typical space. This was one of the driving forces behind consulting with other faculty as well as different departments at Fleming College in producing my outline/lab content. I cannot thank each and every one of them enough for their input and time. From identifying my course outline as a “scaffolding” approach to my “flipped” classroom approach, having the support of the different departments felt amazing. I’ll save talking about the outline for another post.

The “Big Ask”

What if I treated the lab like an interaction with a boss or a client? Give the students an “ask”, but make it big, bigly even. Something that would need them to figure out multiple steps and decipher what exactly is necessary to be done. I was flipping the sequence method on its head and reinforcing what it’s like to work in the real world. Honestly, there is nothing new about this method, it’s being done at numerous schools around the world. It is even used in some courses outside of the programs I teach in at Fleming. It got me excited just thinking about the possible experiences that could be given to the students with this method.

The First Lab

I was extremely worried about what would happen with such a drastic change in the expectations of the students.  Even though the course was in their final year, from my initial probing, I could tell that the students had long since forgotten about Linux administration and were lacking exposure to basic things like Git. At one point I spoke with my superior at the college (the chair of the program) about what I would do if no-one was able to complete the lab. Thankfully, he was supportive of my attempt to create meaningful experiences instead of just throwing content at the students and hoping it stuck.

The big day came, the students filed in, not knowing what shit-show they were about to encounter. I gave them a bit of a primer talk mentioning some topics that might trigger some thought during the lab, as well as some basics about operating system components (trying to bridge the lack of basic Linux administration). Then I dropped the bomb. I walked them through the lab, and on the surface, it sounded easy to them, but they never expected the trouble buried beneath the surface.

Experiment Requirements

For this first lab, I wanted to engage with a wide variety of system administration skillsets. What better way, then to get the students to have to build out a Linux kernel with some customization. Knowing that outcome, I was able to create a set of requirements in reverse to guide them through this process. As an added bonus, I threw in the requirement to have a students name be part of the kernel signature. Why? It makes cheating nearly impossible. After seeing first hand the extreme problem with academic integrity in some of the other courses I was involved in, I was not willing to make those same mistakes in a course that I controlled. Every lab moving forward, the students would be required to either use their previous kernel or modify a new one to have their name attached to it.

1. Use Ubuntu image found on vSphere OR download your own local copy to work with.
2. All working files must end up under the /home/comp237/lab1
3. Retrieve a clone of latest kernel code via from the master GIT repository.
4. Compile and configure a replacement kernel as necessary with the following requirements met:
   1. Kernel’s version signature must include your first name and last name in it.
5. Replace the old kernel with the new kernel and verify

The Ticking Time-Bomb

When I started planning out the lab, I had the intention of just keeping it simple. The point mainly to check what previous knowledge they had retained, so that I could plan out future labs accordingly. However, the lab took on a life of its own as I started doing it myself.

Over the years, the kernel source had grown, and the space needed to compile it had grown beyond my wildest dreams. This presented an interesting problem when it came to the image I had prepared for the students. It only had 20gigs allocated as hard drive space, therefore something was going to have to be done. This immersive problem created a great learning opportunity for students to experiment with virtualization and its ability to change on the fly. Coupled with the fact that the existing drive was a Linux volume, the students would need to troubleshoot and resolve multiple issues before proceeding. There were a few other little touches that emerged from the lab, like how the network device name changed depending on the hosting platform.

Again, because I was concerned about the difficulty level of the lab, I attempted to provide hints during the introduction to the lab, as well as while the students were attempting it during class. Providing meaningful feedback to stimulate thought, without giving them the answers directly. I am a believer that to learn something, you need to do it.

The Postmortem

They did it! After delivering the lab to the students on a Friday, I came home hopeful, but still a bit concerned. As the weekend drew to a close, I sent out a “how is everyone doing?” email just to see if there were any questions from the students that I needed to discuss. Monday night I got my first response from one intrepid student who indicated he had completed the assignment. WIN!

I started prepping for one of the most important postmortems I will have ever lead. My pitch to Fleming College was breaking away from the norm. To run a postmortem after the students had done in the lab. To go over everything and highlight best practices (and masochistic approaches) and address all the questions that came up during their actual performance of the lab. This sort of arrangement isn’t something you typically find in today’s educational space, but it is something becoming more and more common in the industry.

Above is just a sample of some of the topics covered in the lab, as well as things discussed in addition during the postmortem. I’ve made a knowledge base article around this lab and the postmortem report associated with it. Check it out!

Student Feedback

Coming from industry I knew the benefits of running a postmortem on a project, so I was eager to discuss with the students what they thought of this method of teaching. Generally speaking, there was nothing but a positive response to this method of teaching. It could have been the drastic difference in the delivery of content, but my hunch is that it was genuine.

My concern about the difficulty of the lab was warranted, but as the students indicated to me it was appropriate. It forced them to start thinking differently about how to solve technical hurdles. With so many ways to solve the lab, and so many possible permutations of the problems it presented, the time it took students to complete the lab varied. In the postmortem, I showed the students some of the different ways to carry out what was asked. From the 2-hour way of resolving the issue to the 30-minute easy method.

Conclusions

This experiment/lab was the start of something bigger and better. I am hopeful that I will be able to create meaningful change at Fleming College in the future. I wasn’t trying to overwhelm the students with this lab, merely get a baseline of where they were at. The lab following presented similar results in creating awesome experiences for the students and again pushed their limits. Everything I had hoped to have come from this lab, and so much more happened. More on this in the future!

Many thanks to the awesome students of COMP237 who went on this journey with me.