Gas station without pumps

2018 September 23

Learning outcomes for my electronics course

Filed under: Circuits course — gasstationwithoutpumps @ 17:15
Tags: ,

Faculty at UCSC are required to write “learning outcomes” for any new course they want to teach, and these outcomes are vetted by the Committee on Courses of Instruction, as part of the approval process for new or revised courses. I was on that committee for a couple of years, and most of the learning outcomes I saw were vague, generic statements about students understanding the content of the course—a rather useless expression, as “understanding” is not a measurable concept.  For memorize-and-regurgitate courses, there may not be any learning outcome beyond “knowing” a set of facts, but I would not want to teach such a course, nor am I aware of good ways to determine what students know.

Another common set of learning outcomes were very vague statements about reading, writing, or thinking that could be applied to almost any course at the university—general statements of desired outcomes of a university education, with no specific relationship to the course.

A good learning outcome should be something observable, not something internal to the student, even if what we are attempting to achieve is indeed an internal change of state, and a good learning outcome should be specific to a particular course (and perhaps even to a handful of assignments in the course). The hard part is coming up with good, observable proxies for the real learning we want students to acquire.

For my applied electronics course, I have a lot of different goals for students: to think like engineers, to work together effectively, to meet deadlines, to write well, to design and debug, … .  But listing these broader goals as learning outcomes would be too vague, as they do not define what this particular course is doing, nor do they provide ways to measure whether they have been achieved.

The course is split into two halves (51A and 51B), with the following (cumulative) goals for the second half:

Students will be able to

  • draw useful block diagrams for amplifier design.
  • use simple hand tools (screwdriver, flush cutters, wire strippers, multimeter, micrometer, calipers, … ).
  • hand solder through-hole parts and SOT-23 surface-mount parts.
  • use USB-controlled oscilloscope, function generator, and power supply.
  • use python, gnuplot, PteroDAQ data acquisition system, and Waveforms on own computer.
  • do computations involving impedance using complex numbers.
  • design single-stage high-pass, band-pass, and low-pass RC filters.
  • measure impedance as function of frequency.
  • design, build, and debug simple op-amp-based amplifiers.
  • draw schematics using computer-aided design tools.
  • write design reports using LaTeX and BibTeX.
  • plot data and theoretical models using gnuplot.
  • fit models to data using gnuplot.

Note that these outcomes ask for observable skills, not internal states of the student’s mind—I ask that students draw schematics, not that they understand schematics, I ask that they design, build, and debug amplifiers, not that they know how to.

These learning outcomes are very specific for this course—indeed, for just the most recent offering of the course, as we did not use SOT-23 components or USB-based instruments until 2017–18.  They are also all evaluated repeatedly during the quarter (though some tools, such as the calipers, are only used once).  In order to pass the course, students have to have done all these things, at least at a minimal level, and the student’s portfolio of work for the course shows ample evidence of their skills.

I’m also convinced that students who show that they can do all these things in the course as it is structured have also met the vaguer goals of thinking like engineers, working together, and meeting deadlines.

For my readers who design courses: what have you come up with for listing learning outcomes?  Are there ways that I could improve the list I have?


Blog at

%d bloggers like this: