First and foremost, time is going to be an issue. I taught the class in addition to my full-time job, and it took place during business hours. Luckily I had the support of both my department, team, and boss. So in addition to class and preparation time, I also needed to make up for the time I missed in the office. Even though I knew from talking with other adjunct professors that it was going to take a lot of prep, I still wasn’t prepared for how much time it actually took every week to prepare class outlines, quizzes, projects, code examples, etc. And that doesn’t count grading projects afterward.
Whether we realize it or not, we use A LOT of jargon in our industry. Be careful that whenever you use an acronym or term that’s new for the students, take some time to explain it. I would recommend keeping a list of terms and definitions somewhere easily accessible to the class of any term you explain. And then when a student asks about a missing term, add it to the list.
The course took place over twenty-eight, 1.25 hour classes. Grading was based on the following:
The quizzes were used to make sure the students completed their reading assignments. Each one consisted of three multiple-choice questions based on the material we were to cover that class, and were based on the reading. Quizzes were administered at the beginning of class with a 4-minute time limit, and were open-book. So while it was certainly possible for a student to skip the reading and just try and look up the answers during the quiz, the time limit made it practically impossible to do so and get them all correct. I went with open book because it’s simply not possible to memorize every technical issue in web development. If you’re a developer, just stop and think how often you hit the search engines to look up some minutia of our craft that you can’t quite remember. But if the student did the reading, and couldn’t remember a technical issue exactly, they should be able to find it quickly enough to confirm their answer.
Projects were used to allow the students to practice what was covered in class in a practical way. This allowed the students to take what was just discussed and apply it in some way that could help them understand it in more depth.
In retrospect, I would probably drop to 20 projects, make quizzes worth 20% and projects worth 50%.
The only required materials for the course was Learning Web Design, 4th Edition by Jennifer Robbins. This book covers most of the basics needed for the aspiring web developer. It has enough on each topic to provide a good intro on which we could expand in class. All other topics not covered were supplemented by articles freely available on the web.
I allowed the students to pick their own text editor for the class, but I provided a list of recommendations. I required all students use Chrome for testing. With Chrome’s aggressive auto-updates, I could be fairly certain we’d all be on the same version. So that way if the code worked for the student, it would work for me when grading projects. Chrome also has excellent support for modern HTML/CSS and (arguably) the best developer tools.
All students were also required to open Codepen accounts and GitHub accounts. Codepen for simple testing and tinkering, and GitHub for later the semester when we covered source control.
For projects, students hosted all files on their university provided “webfile” spaces or Codepen. I learned after the class ended that GitHub offers students free private repos. Next time I will definitely go that route. We didn’t cover source control or GitHub until near the end of the semester, and in retrospect, this should be moved into the first or second week. Some students had a workflow of creating multiple copies of a file when trying new things. With Git they could simply create branches. Couple that with the private repos and we could end up with a nice workflow for assignments.
Below are the topics that we actually ended up covering. I had to cut some from my original list due to others taking longer than I had planned.
I allowed the students to come up with a concept of their own choosing with the requirement that certain features/functionality be implemented.
I found this approach had a couple of advantages. First, since the project was of their own choosing, it gave the students the opportunity to work on a topic that they enjoy. Some of the submissions included history and rules of various sports, a Harry Potter fan site, a Halo fan site (on which the student successfully Rick-rolled me), and an overview of a Humans vs. Zombies game that’s played on campus. The second advantage was that this approach saved my sanity. Since I had twenty-eight students, grading this final took a lot of time. So the variety of sites was extremely welcome. It was also interesting to learn more about the interests of the students I’d spent so much time with.
I’ve had great discussions with other developers on campus that teach classes at Notre Dame. The concensus is that the first attempt is definitely the hardest. There’s an incredible amount to learn about how to structure and conduct a technical class. And even after having numerous discussions with them prior to the start of class, there’s still a lot I had to figure out on my own. But in the end, I’m very glad I took the risk and time to teach. It’s amazing how the process of teaching your craft really makes you break down the what’s, how’s, and why’s of our everyday.