Gas station without pumps

2014 October 26

Critical thinking

In a comment exchange on the Cost of College post Trying to teach the enigmatic and increasingly popular skill of critical thinking, CSProfMom and I were discussing the relationship between critical thinking and the various modes of thinking used in CS and engineering.  I’ll pull out some of the highlights of the discussion to set the stage for this post, but I’m leaving some things out, so go read the original post and comments.

Grace, the author of the post, presented some of the definitions of critical thinking she had found, and CSProfMom replied with

I do not like these definitions of critical thinking because they are only based on verbal reasoning. Mathematical and computational problem solving are utterly ignored; yet I think more critical thinking goes on in those areas than in fields like literary analysis.

Grace defended the definitions, and CSProfMom responded with CMU’s definition of computational thinking:

Computational thinking means creating and making use of different levels of abstraction, to understand and solve problems more effectively.

Computational thinking means thinking algorithmically and with the ability to apply mathematical concepts such as induction to develop more efficient, fair, and secure solutions.

Computational thinking means understanding the consequences of scale, not only for reasons of efficiency but also for economic and social reasons.

http://www.cs.cmu.edu/~CompThink/

I weighed in with

I think that CSProfMom’s point is that “critical thinking” is generally defined rather narrowly and generically, and so misses the important thinking styles that are crucial to some fields. “Computational thinking” is one that is missing. One I see students not getting in most of their college classes is “engineering thinking” or “systems thinking”—dividing difficult problems into simpler subproblems with clearly defined interactions between the subproblems. Although one can argue that these specific modes of thinking are somehow subsumed in “critical thinking”, classes that purport to develop critical thinking skills don’t generally develop these important modes of thinking.

CSProfMom responded with

I think there is a lot of overlap between “computational thinking”, “mathematical thinking”, and “systems thinking”. Abstraction and decomposition are key skills in all three. Your description “dividing difficult problems into simpler subproblems with clearly defined interactions” is absolutely critical in computer science. Maybe computational thinking is simply systems thinking + algorithms?

In any case, because the “critical thinking” term does not include this idea of systems thinking, we see students arrive into our engineering/CS programs utterly unable to think in this manner. I believe that is a major reason why we see the terrible attrition rates in these programs.

The rest of this post will be an expansion on the comment I left in response to this.

There are several different terms floating around in our discussion, and I’d like to pull them out for closer examination:

critical thinking
This seems to be a subset of the medieval trivium (grammar, logic, and rhetoric), leaving out the grammar and being a bit light on the rhetoric. It doesn’t even cover modern mathematical logic, but only the simplest Aristotelian logic. The Wikipedia article on the trivium even points to the critical thinking article, which collects nine conflicting definitions of critical thinking, none of which include the other concepts that I list below, except in the vaguest ways.
mathematical thinking
Mathematical thinking is about setting up formal systems of rules and examining their properties very closely. Proofs are a major component of mathematical thinking, which has a much more formal and unforgiving definition of proof than other fields. Computation has created a lot of new formal systems to study, and has been a fruitful area recently for mathematicians, just as physics was in previous centuries. Theoretical computer science is basically a branch of mathematics, involving primarily mathematical thinking.
scientific thinking
Scientific thinking studies the real world, constructing models of how it functions and testing the models empirically.  Different branches of science differ in how much they are model-driven and how much they are data-driven. Physics is highly model-driven, with the models often coming out 40 or 50 years in advance of the data (see Higgs boson).  Biology is highly data-driven often with non-quantitative  verbal stories as the models.  The key concept throughout science is empirical validation of predictive models.
engineering thinking
Engineering is about designing new things.  An engineering question is more of the form “how can I make this work?” rather than the science question “how does this work?”  I’ve talked about the distinction between science and engineering in one of my early blog posts, so I won’t belabor the point here.  Although scientists and engineers often wander back and forth between scientific and engineering thinking, the two are really distinctly different modes of thought.
systems thinking
Systems thinking is an important component of engineering thinking, consisting of dividing difficult problems into simpler subproblems with clearly defined interactions between the subproblems.  But systems thinking cuts across many fields, including mathematical thinking and scientific thinking. 
Computer programming is one of the best subjects to teach systems thinking in, because computer languages provide formal (though still inadequate) ways of representing the modules that encapsulate the subproblems and the interactions between them.  Electrical engineers try to do the same thing with their block diagrams, but these formalize a little less of the interactions, relying on English-language descriptions that are often omitted or poorly written. 
Unfortunately, many of the lower-level computer science classes have the faculty or textbook authors do all the systems thinking for the students, so that the students never learn to do it themselves. The scaffolding put in place to help the students find good solutions is where all the systems thinking happened, and descaffolding so that students have to learn to subdivide difficult problems into easier ones is an essential, but often missing, component of teaching programming.
The “multiple levels of abstraction” mentioned in the CMU definition of computational thinking is really about systems thinking, as each subproblem gets broken down into still smaller problems. 
algorithmic thinking
Algorithmic thinking is coming up with very precise recipes for doing things—not just flailing around trying things, but having very specific methods that can be shown to work (and work efficiently). Algorithmic thinking is really a branch of mathematical thinking, interested in provably correct manipulations in formal rule systems.  Originally it was applied to computing numerical functions, first manually and later by machine, but now has been expanded to cover many different types of data that can be represented in computers.  This is the second part of the CMU definition of computational thinking.
computational thinking
I don’t like the CMU definition of computational thinking, as they seem to have picked up definitions of mathematical, systems, and algorithmic thinking, and missed the computational part entirely. Computational thinking, to me, involves using computation to solve problems (data analysis, algorithmic solution of symbolic problems, numerical simulation, …) and may not involve much systems thinking or algorithmic thinking—someone else may have done that for you to enable you to use a computational tool.  Using Google to search for information is computational thinking, albeit at a rather low level.
statistical thinking
Statistical thinking is distinct from all of the above, though it is often important in scientific thinking.  Statistical thinking involves reasoning about data that comes from random processes, or that can be modeled as having been corrupted by random noise.  Notions of probability, sample size, statistical significance, multiple-hypothesis correction, correlation, and causation are all part of statistical thinking, which has applications to decision making in all aspects of life.

Obviously, there are overlaps and intersections between these different modes of thought (proofs done with the aid of a computer are a combination of mathematical and computational thinking, for example), but there are important differences also.  For example, Engineering thinking is not just systems thinking, but includes attention to fine details in the edge conditions (a hallmark of mathematical thinking), making allowances for variations in manufacturing (statistical thinking), testing how the device works in the real world (scientific thinking), and, very often these days, figuring out how to use cheap microcontrollers to do tasks that traditionally were done with more expensive analog devices (computational thinking).

The UCSC general education requirements (see my blog post on general education) recognize mathematical reasoning, scientific inquiry, and statistical reasoning as distinct parts of general education, adding textual analysis and cross-cultural analysis to cover what is often lumped under “critical thinking”.  They did not include anything that guarantees exposure to systems thinking, and they tossed in a few other things, some of which seem to me to be more politically expedient choices or fashion following than fundamental modes of thinking, but a general education system is always a compromise between different beliefs about what a university education should mean.  I think they did a better job of defining the basis for their general education system than most universities manage.

There have been a lot of calls for more education in “critical thinking” lately.  I’m not really happy with these calls, because teaching only a weakened version of the medieval trivium instead of more powerful modern forms of thinking does not educate students properly.

 

 

2014 September 25

Details matter

Filed under: Uncategorized — gasstationwithoutpumps @ 11:57
Tags: , ,

In a comment on Mark Guzdial’s blog post Pushback in California on Computing in Schools, “lizaloop” wrote

2. While I support the effort to bring programming into schools I’d like to see us also emphasize the concept of each person taking charge of his or her own learning. Because programming languages change so rapidly anyone who intends to do serious coding will have to repeat the learning process over and over. Our introductory CS classes need to focus more on “learning how to learn” than on the specifics of any one coding language.

While it is certainly true that programing languages go in and out of fashion (where are the COBOL programmers of my youth now?), and it is also true that people need to keep learning if they want to remain in any technical field for long, that doesn’t mean that intro CS courses should give up on teaching specifics and instead tackle the nebulous goal of “learning how to learn”.

In fact, one of the things that distinguishes computer programming from many other courses of study is that you must learn the specifics of the programming language and tools you are using if you are to get anything done.  “Big picture” thinking does not get programs written.  It does you no good to “learn how to learn”, if you then don’t learn any of the details.

One of the major things that students new to computer programming (and to other engineering fields) need to learn is that details matter.  The specifics of the computer programming language they are learning matter—not forever, since they might never use that particular programming language again—but while they are doing what they are doing right now, the details matter.  That is an enduring, transferable lesson, but it depends on having a course in which the specifics of the coding language are viewed as important.

Of course, this does not mean that the teacher has to spend a lot of time on the details—the compiler or interpreter will make it abundantly clear to the students that details matter.  But the teacher can strengthen or weaken that lesson by their own example and by their grading.  Teachers who only do sloppy pseudocode on the board, never filling in the missing details or correcting mistakes, will convey the impression that the details are unimportant.  Teachers who don’t mark down sign errors, punctuation errors, and off-by-one errors in quiz or exam answers also give the impression that “close is good enough”, which is emphatically not the case in real programming.  Teachers who never read their students’ programs, but only do crude I/O testing to grade programs, will give the impression that documentation doesn’t matter.

On the other hand, teachers who spend all their time fussing over semicolons and never talking about the bigger ideas of algorithms, data structures, problem decomposition, and program documentation will produce low-quality copy editors, not programmers. One reason I like Python as a pedagogic language is that the syntax is simpler than many other languages, so that I can get the details right without having to spend so much time explaining the details (and the students can spend more time on more interesting debugging than chasing down punctuation errors).

But I’m not trying to dump on lizaloop’s ideas entirely.  Computer programming courses are a good place to teach students to “learn how to learn”, though not by ignoring the specifics and following some sort of touchy-feely metacognition curriculum.  Indeed, it is because of the specific details that students must master to get anything done that programming is such a good subject for learning how to learn.

Those specifics are essential to the task at hand (not some nebulous future need that is all most math or science classes manage), but they are easily looked up in on-line documentation with generic Google searches.  Try googling things like python reverse string, HTML color, or c++ function pointer to see how easy it is to get online tutorials and documentation on specific details.

It is completely reasonable for a teacher to give students concepts and keywords, but expect them to look up some of the details for themselves.  For example, a teacher might explain RGB color space and how colors are often encoded as three one-byte numbers in hexadecimal format, but not give any specific color codes, expecting students to find the codes they need either by experimentation or by on-line search.

In the approach I’m suggesting, the students are still focused on the details of the coding language, but they are also learning how to learn (at least at the lowest level of learning how to look up specific facts).

Teaching students how to learn more complex concepts on their own (like how to choose which color space to work in) is probably a forlorn hope, but getting them to learn to look up specific facts (like how to transform from HSV color space to RGB color space) and low-level details (like HTML color codes or how to reverse a string in Python) is certainly a reasonable expectation for an intro CS course.

2014 June 20

Male- and female-dominated fields

In Percentage of Bachelor’s degrees conferred to women, by major (1970-2012), Randal S. Olson posted the following image:

History of gender balance in different fields in college.

History of gender balance in different fields in college.

He makes the point that there is no “STEM” gender gap. Indeed, the sciences and math are doing fine on gender balance. There are, however, large gender gaps in the engineering and computer science on one side and health professions, public administration, education, and psychology on the other. The post with this graph talks mainly about the computer science and engineering gender imbalance, which is somewhat larger than the gender imbalance on the other side (particularly if you take into account that about 60% of bachelor’s degrees now go to women).  He talks about the other side of the gender imbalance in The double-edged sword of gender equality, though without shedding much more light on the subject.

Computer science is a particularly strange case, as it has seen more fluctuation both in raw numbers of students (data not shown here) and gender balance than any other field. Other fields have seen large shifts in gender balance, but they have generally been gradual and nearly monotonic—not reversing course in the early 1980s.  It seems to me that the biggest drops in the ratio of women in CS came at times when the overall number of students in CS was dropping (like after the dot-com bubble burst in the 2000).  When CS grew, the number of women grew faster than the number of men.  When CS shrunk, the number of women shrunk faster than the men.  Perhaps if CS education had had a steady growth, rather than the boom-and-bust cycles that have plagued it since the late 1970s, it would not have had such a mysterious rise and fall in proportion of women in the field. The boom-and-bust cycles are not driven by the real need for CS degrees, but by media hype about relatively small shortages or excesses of personnel.  I believe that the demand for CS degrees has been stabler than the supply (unlike most other fields, where the supply has been steady even as demand has fluctuated).  Sorry, I don’t have statistics handy for that, and I’m too lazy to spend hours going through the government databases trying to match up labor market information with degree information.

Fixing the gender gaps so that most fields can draw from the full population will be difficult. Getting more men into the health professions and education could probably be solved fairly easily by paying more—and there is no societal need for more psych and public administration majors than are currently being produced. But, because CS is already a high-paying field for which there is more demand than supply, the difficulty of getting more women to choose and complete the major is a societal problem that seems difficult to address.

Some people have suggested that eliminating H1B visas for importing temporary CS workers (who are predominantly male) might help.  I don’t think that the number of H1B visas is large enough to make that big a difference, though I support replacing the H1B visas with green cards.  If there aren’t enough American workers in a field, we should import the workers on a permanent basis, not with a temporary indentured-servitude system that just serves to export the technical expertise when the workers are sent home.

Some people have suggested that a big part of the problem is the disrespect women are treated with in some workplaces—which would help explain the “leaky pipeline” phenomenon, but not why female high-school and college students are not entering the field. Student choices in high school and college are shaped much more by peer pressure and mass media than by anything about the future workplaces—so the problem is one of changing the culture in high schools and colleges—a difficult task.  There has been some success at some smaller schools (like Harvey Mudd), but a large part of that has come from aggressive admissions policies that aim for gender balance in the field at admissions time—a route not open to public schools, who can’t apply large differences in admissions based on gender.

I’m currently in charge of a bioengineering program, whose graduating class was about 36% female (13/36), and a bioinformatics program that is so small that statistics are pretty meaningless (only 2 graduates a year, both male this year). I would like to see the number of women in majors increase, particularly in the concentrations that lead to higher paying jobs (the concentrations that are further from MCD biology).  We get a few students switching to the bioengineering from MCD biology, but not many, as those students don’t take the rigorous math and physics needed for the bioengineering degree—we really have to get our students in the first year.  I’m still trying to find ways to reach those students who would be good engineers, but don’t realize it until too late.

 

2014 May 21

Establishing the habit of writing

Filed under: Circuits course — gasstationwithoutpumps @ 09:19
Tags: , , ,

In Preparing for AP Physics 1: establishing the habit of writing Greg Jacobs writes

I’m in the infant stages of planning my AP Physics 1 course. The big trick is going to be establishing my students’ ability and willingness to write their reasoning, to get them to focus on communication rather than on getting a correct numerical answer. Once it’s clear that they are not taking a math course—once they see that the solution to a problem looks much more like what they’ve done in biology or economics than in calculus—I think the students will be able to move along quickly and enthusiastically through the material.

Students must get comfortable with calculation. However—as was correctly pointed out to me at the AP consultant meeting in April—if we start the course with lots of pure calculation, students will think that getting the answer is the holy grail of physics problems. If instead we begin the course demanding description, explanation, and all sorts of prose, students may become accepting of the idea that a numerical answer is merely the result of careful reasoning.

If this change in AP Physics actually works (something I’m always skeptical about in any curriculum reform, particularly at the high school level), it may help engineering students in college. Engineers do far more writing than most professions, with far less training at doing it.

I don’t think that a prompt that just says “In a clear, coherent, paragraph-length explanation, describe how you would figure out …” is going to do the trick, though. If they could already write clear, coherent paragraphs about how they would figure something out, then they would not need the curriculum change—they might not even need a physics class at the level of Physics 1.

I’m struggling with this problem in my applied circuits course, in which I require weekly design reports for the circuits they design and build. The students are staying in lab until they finish the designs and demo them, so they are clearly capable of doing the work (though not always as quickly as they should). But only a few students can explain their computations for the design parameters (like gain, corner frequency, and component values) clearly—others put down any nonsense that has a few of the right buzzwords in it.

The top students have gotten better at their explanations as a result of feedback, but the bottom students are still often producing word salad. Although there is some indication of a general writing problem (lack of topic sentences, poor grammar, and misused vocabulary), the problem is most pronounced when they are trying to explain how they selected component values. The more steps that there are in the underlying math, the more jumbled their explanations, even if the problem is just a chain of multiplications.

From time to time, I’ve suspected that the students don’t produce coherent sentences about how they computed something may not have actually done the computation, but “borrowed” the result.  This is not an explanation I believe in strongly, though, as the students have been (mostly) coming up with different solutions to the design tasks, so there isn’t simple copying going on. I’ve also seen the design process the students use, as they have been doing their pre-lab work in lab (instead of at home), so I hear them discussing the problems.  They do ask each other not just what answer they got, but how to get the answers, so they are trying to learn the method.

In looking at the pre-lab homeworks that were turned in on Monday I realized what part of the problem is—the students keep absolutely awful design notes. What the students turned in on Monday (even the top students) was mostly incomprehensible scribbling of numbers, with no indication where the numbers come from or what they were attempting to compute.  Half an hour after writing down the notes, I’m pretty sure that they could not reconstruct their reasoning—hence the often magical methods in their design reports, where they copy numbers out of their notes (some of which are correct), but can’t put together a coherent chain of reasoning that leads to those numbers. On the long multi-step computations needed to figure out what gain an amplifier needs, they can usually do each step (though often needing coaching on one or two of the steps, either by me or by one of the better students in the course), but they don’t record the meaning of each step or even what the sequence of steps is, and the “answer-getting” mentality causes them to flush the process from their minds as soon as they have a number.

I’ve seen a lot of lab exercises for other courses that try to scaffold the process by providing worksheets that give the step-by-step process and have the students fill it out as they go along. I don’t think that this is helpful though, as it encourages students to solve one step at a time and then forget about it—the scaffold prevents the students from exercising the very skill that I most need them to learn. Showing them worked examples, as I have done in class, doesn’t seem to help much either—they can follow along as I break the problem down with them, and think they understand, but then not be able to do the same thing themselves.  Again, the scaffolding prevents them from exercising the skill I most need them to learn—identifying problems and them into subproblems.

For next year, I’m probably going to have to come up with some exercises which get students to organize their thoughts external to their heads. So far, the only thing I’ve thought of is to have them create a fill-in-the-blank worksheet for each lab (like an income tax form), and turn in the blank worksheet and try filling out each other’s worksheets.  If they get in the habit of writing down the steps as steps, it may help them be able to reconstruct their work when they convert it into full sentences for the final reports. It may be too late for me to do anything formal this year (only 2.5 weeks left), but I’ll suggest it to the students anyway.

The advice I’d give to Greg Jacobs is to leave the “clear, coherent paragraph” until later in the quarter—get them to create worksheets first.

I’d welcome any suggestions from my blog readers on ways that I can get students to learn to organize their thoughts in a way that they can present them coherently to others. Block diagrams alone don’t seem to be enough, and vague things like “mind maps” are likely to do more harm than good.

2014 April 20

Designing courses to teach design—draft 4

Today I tried practicing my talk for Wednesday with my son as an audience (I figured I could get some useful feedback from him based on his years of theater experience). He asked me a number of good questions about my audience and what effect I wanted to have on them (the same sort of questions I ask my students, but often have difficulty applying myself). He gave me some good advice about changing the tone of my talk, making it more conversational and less lecturing.  (I’m good at that in my usual improvisational lecture style, but I know that I couldn’t keep to time if I tried to be extemporaneous with this material.)

After getting his suggestions, I rewrote the talk and delivered it to him again.  It runs about 9 minutes, and my target is “under 10 minutes”, so I think the length is about right. I welcome suggestions from my readers also—the talk isn’t until Wednesday, so I may have time to make more revisions.

Because of the time constraints, I’m going to read my talk—something I’ve never done before, so forgive me if the presentation is a bit awkward.

I want to talk to you today about two courses I created in the past two years. These courses were in part a reaction against the University pressure to create MOOCs. University education is not supposed to be mega-lecture courses, but students getting detailed feedback on their work from experts.

The courses I’m talking about are not easy, cheap fixes (like was claimed for MOOCs)—they are high-contact, hands-on courses, which take a lot of time to create and teach, and so are expensive to offer.

Designing the courses started from goals and constraints: “what problem was I trying to solve?” and “what resources were available?”

The two problems I was trying to solve were in the bioengineering curriculum:

  • students weren’t getting enough engineering design practice (and that mostly in the senior year, which is much too late) and
  • too many students were selecting the biomolecular concentration, where we were exceeding our capacity for senior capstone and senior thesis projects.  The other concentrations were under-enrolled.

The main constraints were that

  • there was no room in the curriculum for adding more required courses,
  • there were no resources for new lab space or equipment, and
  • all existing engineering design courses had huge prerequisite chains.

Because I couldn’t ask someone else to create and teach a new course, the content had to be something I already knew or could learn quickly. So, no wet labs!

The first course I’ll talk about is a replacement for the previously required EE 101 circuits course. The EE course is a theory class that prepares students to do design in later courses—but most bioengineering students never take those later courses, so were getting prepared for something they didn’t do. (That’s a general problem in the bioengineering program—“creeping prerequistism” in the 8 or 9 departments providing courses results in the students always preparing to do stuff, and not getting to the doing until senior year.)

The goal of the new Applied Circuits for Bioengineers course is to have students design and build simple amplifiers to interface biosensors to computers. We work with a range of sensors from easy ones like thermistors, microphones, and phototransistors to more difficult ones like EKG electrodes and strain-gauge pressure sensors.

The goal is for students to do design in every lab, even the first one where they know almost no electronics, and to write detailed design reports on each lab—not fill-in-the-blank worksheets, like they get in other intro labs.

The course was designed around the weekly design projects, not around topics that must be covered. Themes emerged only after the design projects were selected—the class comes back again and again to variations on voltage dividers, complex impedance, and op amps with negative feedback.

There wasn’t a textbook available that covered things the way I wanted, so the students use free online materials instead. The savings on textbooks is used to justify a lab fee of  about $130 for tools and parts. They don’t get just a few parts, but 20 each of 64 different sizes of resistors and 10 each of 25 different sizes of capacitors, along with a microprocessor board and lots of other tools and parts. I don’t want their designs to be multiple-choice questions (“there are only 5 resistors in the kit—so one of them must be the right answer”).

Coming up with usable design exercises was hard—I tried lots of them at home, rejecting some as too hard, some as too easy, and tweaking others until they seemed feasible. I even designed three different custom printed circuit boards for the course: a board for pressure sensors, a hysteresis oscillator for soldering practice, and a prototyping board for their two instrumentation-amplifier projects. (pass boards around)

By the way, PC board design has gotten very cheap—I used free tools for doing the design, and the boards themselves cost only 50¢ to $1—it would have cost thousands to have done custom boards like this when I was first hired at UCSC.

Developing a hands-on course like this is not quick—creating the course took me almost 6 months of full-time effort!—so we’re probably not going to see huge numbers of such courses being started. But they’re worth it!

To make it somewhat easier for someone who wants to create a similar course, I posted all my notes on designing the course on my blog—over 100 blog posts before class even started! There are now around 240 posts (the URL is on the quarter-page handout, along with the URL for the course syllabus and lab assignments).

The course was prototyped last year as BME 194+194F “Group Tutorial” before being submitted to CEP for approval. Incidentally, I highly recommend prototyping before submitting the paperwork for new courses—there were a lot of changes that came out of the prototype run. For example, the lab time was increased from 3 hours to 6 hours a week.

That change has a high cost—not only am I spending over 10 hours a week of direct classroom and lab time, but I’m spending every weekend this quarter rewriting all the lab handouts—splitting the material between the lab times and adding at-home or in-class design exercises between the two parts. Even with the extra lab time, some labs ran over this quarter, so I’ve got still more tweaking to do for next year.

It isn’t just the design of a new course that is expensive—each time the course is offered takes a lot of faculty time. In addition to the 10 hours a week of direct contact, I have office hours, grading, prep time for both labs and lectures, and rewriting the lab handouts.  If I have 2 lab sections next year, I’ll have 16 hours a week of direct contact. Just providing feedback on the 5–10-page weekly design reports takes about 15 minutes per student per week (half an hour per report).

But enough about the circuits course.

The other course I want to talk about is one I created last quarter: a new freshman design seminar in conjunction with the student Biomedical Engineering Society. This course has no prereqs, is only 2 units, and does not count towards any major or campus requirements (it might get a “Collaborative Endeavor” gen-ed code).
I’d not taught a freshman class in over a decade, having taught mainly seniors and grad students, so I had no idea what skills and interests the students would bring to the class. With no prereqs for the course, I couldn’t assume that students had any relevant skills, though it turned out that all this year’s students had had biology, chemistry, and at least conceptual physics in high school.

Because I didn’t know what to expect, I didn’t choose the projects ahead of time, but tried to adapt the course on the fly to what the students could do and what they wanted to do.  (They wanted to do more than they could do in the time available, of course.)

I did try out three or four projects ahead of time, looking for design projects with a low entry barrier. But all the projects I tried assumed some computer programming skills, and only one student had ever done any computer programming—a big hole in California high school education.  Even more concerning for engineering majors is that only a few had any experience building anything. (AP physics classes were the most common exposure to building something.)

On the first-day survey the students indicated an interest in learning some programming and electronics, so we did a little programming with an Arduino microcontroller board—I’ll try to up that content next year, adding some more electronics.

The class started with generic design concepts using a photospectrometer as an example. The concepts include such basics as specifying design goals and constraints, dividing a problem into subproblems, interface specification, and iterative design. The photospectrometer turned out to be too complex and unfamiliar to students, and I’ll probably start with a simpler design (perhaps a colorimeter) next year, and have the students design, build, and program it before they start on their own projects.

One positive thing—the course had more women than men, and at the end of the course they indicated that the course had made them more likely to continue in engineering!

I could go on all afternoon about these courses, but I’m running out of time, so I’ll leave you with these take-away messages:

  • The value of University education is in doing things and getting detailed feedback from experts, not sitting in lectures.
  • Students should be solving real problems with multiple solutions, not fill-in-the-blank or multiple-choice toy exercises.
  • Hands-on courses require a lot of time from the professors, both to create and to run, and so they are expensive to offer.
  • Failure to teach such courses, though, makes a University education no longer worthy of the name.

UPDATE 2014 May 2: video available online (as a 784 Mbyte downloadable .mov file) from So you think your lecture course is better than a MOOC? April 23, 2014. I was the second of six speakers.

 

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 276 other followers

%d bloggers like this: