Engineer's Playground
Bridging the Gaps in STEM Preparation

Members Only

Lessons and Labs

aka Yvonne’s attic

These are some of the materials that Yvonne developed throughout the years of teaching (mainly the computers science ones since St. Catherine University is still teaching some elements of the Engineering curriculum she developed with Dr. Lori Maxfield). Some may need some refreshing (e.g. those pesky software programs like to change their interfaces) but if they can be of use to others, she didn’t want to bury them.

Like what you see? Support Engineer’s Playground by sharing or buying one or more of the toys, products, or books for your friends.

Computer Skills

To be uploaded

TOOLS

  • Purpose: To provide basic hands-on model of what is being done with these productivity tools and how to them implement them

  • Observation: Doing the task by hand helps students understand what’s actually being done so they can expand upon that understanding or use other spreadsheets because they know what operation they are looking for

PROGRAMMING

  • Purpose: To show how to think about and then code basic software programs

  • Observations: Once students had basic concepts, it was important to give them time to play around with both what they knew, design on paper what they wanted to make and then figure out how to code it, and then have the syntax understanding of how to learn more with existing resources

    • Alice & intro to objects

    • HTML

    • JavaScript

    • Java (command line applications)

    • Java (applets)

Professional Development & Team Skills

To be uploaded

Student-to-Professional Assessment

  • Purpose: To evaluate students’ perspective on the role of college in their career development and to be transparent about how classwork transfers to jobs

  • Observation: Colleagues are surprised how honest students are in answering this and how much they don’t see that classwork is preparing them for the working world

    • Student-to-Professional Assessment

Team and Individual Evaluations

  • Purpose: To evaluate team cohesiveness and interdependency and to be transparent about how individuals and teams are similar but different

  • Observation: Though some students may see this as a way to complain about their teammates passively, the transparency actually informs those who respond to high praise on what they really need to do individually as well as as a team

    • Team evaluation

    • Individual evaluation

Individual Performance Evaluations (IPE)

  • Purpose: To be transparent about how students should be progressing from novice state (See NAPE below) in technical and professional skills

  • Observation: This provided a way for me to give direct feedback to student with no passive-aggressiveness to help students develop into professionals

    • for CS1

    • for CS2

Professional Development Video Lessons

  • Purpose: To ensure all students had same model of apprentice level expectations

  • Observation: While this aligned the students on what my expectations were, it also gave them the opportunity to both observe and discuss situations in an objective way

    • Lesson 1

    • Lesson 2

    • Lesson 3

    • Lesson 4

Project-based Assignments

To be uploaded

From Backbone to Features

  • Purpose: To model how to break a complex problem down to a backbone and to emphasize the importance that that backbone is done first before adding features or bells and whistles

  • Observation: By the last project, students realized that the best strategy was to race to the backbone to make sure they didn’t fail (literally). Then they were more relaxed (and therefore more creative) to add on features for the higher level requirements

    • Intro

    • CS1

    • CS2

Concept-Design-Implementation Reviews

  • Purpose: To model the review process used in industry to report in progress

  • Observations: Senior students who usually pulled all-nighters to get projects done, realized that was neither productive, efficient, or healthy. They also realized that others needed to know that the reviews were to help them stay aligned every step of the way and allow for course corrections before intense development was done

    • Concept Review

    • Design Review

    • Implementation Review

Curriculum Design

In designing the Computer Science curriculum, I used two axes: Content and Level.

Content: Parallel Curriculum Model for Computer Science

My fantastic education consulting partner and pedagogy mentor, Lori Maxfield, introduced me to the Parallel Curriculum Model (PCM) to account for the different types of knowledge that we were trying to develop for our students. My simple engineering way of thinking of it was that an expert in Computer Science would have four main areas of mastery:

  • Core Knowledge: In short, I think of this as the facts and concepts that are normally the centerpiece of college curriculum. In computer science, these would be the concepts of variables, input, output, arrays, conditionals, iteratives, objects, etc. They might also be the syntax of a particular language or the constructs of data structures or XML documentation.

  • Practice: These are the habits and techniques that are sometimes taught but sometimes assumed. In science classes, these might have been practices like titration techniques, sterilizing the equipment, or calibrating a sensor. In computer science, I found practices to include code formatting, debugging, or even testing methods.

  • Connections: These are the connections of the material in the course with earlier or later courses in the field, but also connections to other fields such as math, science, philosophy, or even art. This area often answers the “who cares” or “so what” questions that students may have.

  • Identity: These are the dispositions, habits, or talents that might make a student identify either as a computer scientist or at least identify when a computer scientist is needed to accomplish the task at hand.

This was described in more detail in the paper I presented at the American Society of Engineering Education (ASEE): Awakening and Improving Employability: A Curriculum That Improves the Participation and Success of Women in Computer Science.

Level: NAPE Charts for Computer Science

These are the guidelines I used when teaching the various computer science courses. NAPE charts were how I scaffolded the learning:

  • Novice: Each student enters the course at the novice level. After all, they came to learn something, right?

  • Apprentice: This is the essence of the course material, at the most basic level. These are expected to be the basics that students need to learn on the subject. As a result, these are explicitly taught in lecture, and lab and tested in homework, projects, quizzes and tests. Just like apprentices of old, students need to see, mimic, and do these skills and concepts on their own.

  • Practitioner: This is the next level, “journeymen” in the apprentice system. They are a level higher than a simple apprentice understanding, able to use a certain amount of judgment and work relatively independently. Mastering this level means students will provide consistent good work.

  • Expert: This is the highest level, “master” in the apprentice system—in the topics of the course, not in the profession as a whole. Mastering this level means students can extend what was learned in creative ways, handle more ambiguous or challenging situations.

TO BE UPLOADED: Intro, CS1, CS2, Architecture

Course: CS1

Java

  • See JavaScript for NAPE Analysis

STEM Consulting Tools

for early childhood, pre-school, STEMifying your work, elementary-to-high school curriculum development

  • Developing STEM PK-12: A high level summary of what the standards seem to say in developing STEM. Good for identifying student gaps and why they may be memorizing rather than building up (because they are lacking the expected pre-requisite)

  • The STEM Seed: How to leverage a child’s natural interest to develop STEM skills