Feedback on first lab report

Most of today’s class was taken up with feedback on the design reports that students turned in by e-mail on Saturday.  Overall the reports were not bad (better than the first reports last year), but I think that the students could do better.  Here are the main points:

• Anyone can redo the report to get it re-evaluated (and probably get a higher grade).
• No one attempted theV1 &V2 problem, so I reassigned it for Wednesday.
  

  The circuit I had given as an exercise, asking them to determine the output voltage V_out.

• A lot of reports mixed together two different problems:the 1kΩ–3.3kΩ problem and the optimization to maximize sensitivity of the thermistor temperature sensor.  I encouraged students to use more section headers and avoid mixing different problems together.
• Figures should be numbered and have paragraph-long captions below each figure.  I reminded students that most engineering reports are not read in detail—readers flip through looking at the pictures and reading the picture captions. If the pictures and captions don’t have most of the content, then most readers will miss it. I also pointed out that many faculty, when creating new journal articles, don’t ask for an outline, but ask for the figures.  Once the figures tell the right story, the rest of the writing is fairly straightforward.
• A lot of the students misused  “would” in their writing, treating as some formal form of “to be”. The main use in technical writing is for contrary-to-fact statements: “the temperature would go down, if dissipating power cooled things instead of heating them”.  Whenever I see “would” in technical writing, I want to know why whatever is being talked about didn’t happen.
• A number of the students had the correct answer for the optimization problem, but had not set up or explained the optimization. Right answers are not enough—there must be a rational justification for them. In some cases, the math was incomprehensible, with things that weren’t even well-formed equations. I suspect that in many cases, the students had copied down the answer without really understanding how it was derived and without copying down the intermediate steps in their lab notebooks, so they could not redo the derivation for the report.
• A number of the plots showed incomplete understanding of gnuplot: improperly labeled axes, improperly scaled axes, plots that only included data and not the models that the data was supposed to match, and so forth. I pointed out the importance of sanity checks—there was no way that anyone ran their recording for 1E10 seconds! I was particularly bothered that no one had plotted the theoretical temperature vs. voltage calibration based on the parameters from their temperature vs. resistance measurements, so I could not tell whether the voltage divider was doing what they expected it to.
• No one really got the solution for the 1kΩ–3.3kΩ problem perfectly. A number of them set up the equations right and solved for R (getting 2.538kΩ), but then not figuring out what Vin had to be.  It turns out that Vin depends strongly on R, so rounding R to 2.2kΩ or 2.7kΩ results in different good values for Vin, and the 2.2kΩ choice gives a more desirable voltage (around 3.3v, which we have available from the KL25Z boards, as it is a standard power-supply voltage).

I also showed the students how I had expected them to setup and explain the optimization to maximize sensitivity at a particular operating temperature.

After that feedback, I started on new material, getting the explanation of amplitude, peak-to-peak, and RMS voltage. I think that the RMS voltage explanation was a bit rough.  I was deriving it from the explanation that we wanted a measurement that represented the same power dissipation in a resistor as the DC voltage, and I got everything set up with the appropriate integrals, but I forgot the trig identity , and ran out of time before I could get it right.  I did suggest that they look up the trig identity and finish the integration.

I had hoped to get at least partway into Euler’s formula, complex sinusoids, and phasors, but the feedback took longer than I had expected. Those topics will have to wait until Wednesday or even Friday, since Wednesday we’ll want to do the modeling of the DC characteristics of the electret mic, and talk about how the mic works.

 

What makes teaching programming difficult?

I’ve been following Garth’s CS Education Blog for a while, and his post Teaching programming is not getting easier resonated with me, particularly the lines

In programming memorization is a trivial part of the skill set needed to succeed. The primary skills needed are problem solving, strategizing, devolving problems into sub-tasks, interpreting, and general full bore head scratching. Those are an absolute bugger to teach, especially to kids that are not all that interested in learning those difficult skills.

I am not primarily teaching programming to beginners—my bioinformatics course has three programming courses as prerequisites and my applied circuits course does not require students to do any programming—but the same issues come up in all my courses.

Even after three previous programming courses, a lot of students have not had much practice at breaking a problem into subproblems or intelligent (rather than random) debugging. The block diagrams and “systems thinking” for the applied circuits class are precisely analogous to the decomposition of a software problem into modules, classes, or subroutines. Even in the senior thesis writing course that I taught for the last couple of years, a lot of the feedback is on getting students to structure their writing—to look at the thesis as having parts that communicate different information or with different audiences and getting the interfaces between the parts to work.

Almost all engineering requires similar problem-solving skills of decomposition into subproblems, designing and debugging parts independently, and debugging the interactions between parts. Teaching these skills in any context is difficult, and many teachers end up teaching special-purpose tricks that solve one type of problem but that does not help the student learn to solve novel problems.

Garth recognizes the problem in his own teaching:

I used to be a math teacher and math has somewhat the same thinking requirements and the same issues.  The big difference is the kids would have 10 home work problems a night, 8 of which were very easy to do so they would do those and ignore the hard ones.  The result would be an 80%.  With math there are a lot of problems with incremental steps of difficulty for almost any new concept.  Those students that can do the 70 or 80% in math survive just fine.  In math I usually have several different teaching strategies for a concept.  I have multiple “gimmicks” for devolving problems to make them easier to solve.  I have other math teachers to ask for new approaches and a whole lot of cool stuff on the internet to use as resources.   Programming on the other hand has diddly.

He learned some strategies for teaching math: assigning large numbers of small problems of gradually increasing difficulty, giving up on teaching most of the students to reach mastery, and providing gimmicks for students to memorize for the common problem types. These approaches have not worked for him teaching computer science—why not?

One difference is that the computer is not very forgiving of students who get things almost right—one punctuation mark wrong and the computer does the wrong thing or rejects the student’s attempt. Getting 70–80% of the way is not enough—students have to get the details right and not just the general picture.

Another difference is the one he notes: there are a lot more math teachers than CS teachers, particularly in K–12, so there is a lot more pedagogical content knowledge (knowledge of how to teach a subject) available in math. He notes that many CS teachers rely on a rather simple pedagogy:

After watching a number (3) of programming teachers teach it seems the teaching strategy is pretty consistent: show and tell and hope.

I wonder how much of the math pedagogy is really effective, though. A lot seems to be of the memorize-this-trick form, which gets students through their standardized tests, but does not develop transferable skills in problem decomposition or debugging.

The content in math and physics courses is also much more stable than in CS courses—what is taught at the high-school level has not changed much in the last century.  The main differences have been a loss of some tools (slide rules and trig tables) in favor of tools that are easier to use and teach with (calculators). Having a stable subject to teach allows teachers and textbook writers to experiment with how to teach, rather than what to teach. Although a lot of pedagogical experimentation fails (and the field of education is not very good at separating the successes from the failures), there are a lot of techniques available to choose from.

CS, however, keeps changing what is considered essential for a first course.  Fortran, LISP, Pascal, C, C++, Java, Python, Perl, Scratch, Processing, Alice, and other languages have all been proposed as “first” languages, and the programming language is often chosen for social rather than pedagogic reasons.

What topics are taught and in what order are often driven by the choice of language.  For example, LISP makes it easier to talk about recursion early, but makes it difficult to talk about strict type checking. Java and C++ force spending a lot of time on explaining data types and data type declaration. Python allows easy handling of sets and associative maps (“dict” in Python), but makes talking about information hiding and data abstraction somewhat more difficult. Scratch allows early discussion of race conditions in parallel programs, but not of complex data structures or program syntax.

CS teachers disagree about what order is most appropriate to present the topics in—not just the week-by-week order, but even what belongs in the first year and what in the second or third year. I think that in many cases the order doesn’t matter all that much—there are several different ways to get to a similar endpoint, and different students will respond well to different approaches. In the new bioengineering curricula that I’ve proposed, different concentrations have different programming requirements, with the bioelectronics track requiring bottom-up programming that teaches low-level interfacing to microprocessors in C, and the biomolecular track starting with bioinformatics-like programming tasks in Python.

Some of the teaching practices at colleges have not been helpful for developing desired skills.  For example, automated grading programs, which look just at I/O behavior of programs, are becoming more popular in huge college CS classes (and especially in MOOCs). But with automated grading students get almost no feedback on the decomposition into subproblems and clarity of documentation—those skills that are most needed for advancing in the field or transferring the learning to other domains.

I did end up teaching a tiny amount of programming in my freshman design seminar this past quarter: Arduino programming in C for gathering information from a thermistor or phototransistor and using it for simple on-off control (Twelfth day of freshman design seminar and Sixteenth day: Arduino demo).  I did not spend enough time on the programming, and a lot of it was “show and tell and hope”, so I suspect that only one or two of the students can do any programming independently now, but several who were not interested in programming became more interested in learning, which is all I expected of the course. The 2-unit course is only about 1% of their undergraduate education, so I can’t expect to make huge changes in their competence.

Next year I will spend more time on programming and on physical prototyping in the freshman design course, as those are areas that the students identified as having the most effect on them. So I may get to the point in the freshman seminar where I’ll also be facing the challenges of teaching CS concepts to beginners, rather than just piquing their interest.

One thing I think I will do in the freshman design seminar next year is to make the students actually wire up a thermistor or phototransistor to an Arduino board early in the quarter.  Having both a hardware and a software component to a design should help students learn problem decomposition and debugging, as there are obvious hardware/software boundaries—it can’t all be just one mushy “thing” in their heads.

The thermistor is particularly attractive as it requires several changes of representation—from temperature to resistance, to voltage, to ADC reading, back to  a numerical representation of temperature. Since the course is intended for bioengineers, the notion of sensors and different representations of what they sense is an important concept to build on, and temperature is a concept that they are familiar enough with that they can easily check whether what they are doing is working. Note that the data representation here is not just a software concept—the main constraint on the design is the analog-to-digital interface on the Arduino, which only measures voltage between 0 and 5V.

Having a thermistor lab early also works as part of a build-a-physical-prototype theme. I’m not going to use lab fees and handing out a lab kit, either, but make them find and order their own parts. One of the problems this year was students not realizing that getting parts requires a lot of lead time—having them experience that early in the quarter will make them more diligent about getting parts in time later in the quarter. To reduce shipping costs, I may have everyone look for parts separately, but then have them pool the orders, if they can agree on which parts they want to get.

In the coming quarter, in the Applied Circuits course, I’ll be trying to work more deliberately on both systems thinking and information representation, getting the students into being explicit about both earlier in the quarter.  (The first lab is a thermistor lab, which I am in the process of rewriting the lab handout for, which may be why it was the example I thought of using for the freshman design course.) I’ve heard discouraging reports about how little transfer there is of problem-solving skills between different subject domains, but I’m hopeful that having students encounter the same problem-solving concepts in several different domains will help them make the transfer.

Seventeenth and Eighteenth day of freshman design seminar

On the seventeenth day of class, we broke into groups and I went around to each group answering questions (as did the group tutor, so we covered 2 out 3 groups at once).  I don’t remember now exactly what the concerns were of each of the groups—some were trying to figure out how to get their materials on short notice (I’ll have to remind people early next year that getting materials requires lead time). I did explain a number of technical things to the groups.

On the eighteenth day, I started by returning the draft design reports and telling them something about how engineering documents are usually structured, with ideas like section headers, paragraphs, topic sentences for paragraphs, and the 4Cs of technical writing.  I was going to provide a link to a 4Cs post that I wrote a few years ago, but when I looked for it, I found it was still in draft form, not finished, so I’ll include it here:

I  see a lot of bad writing.  I present to my students the “4Cs” of technical writing:

The 4 Cs are arranged as a cross, because clarity and correctness are often in opposition to each other, as are conciseness and completeness.  Good technical writing requires finding the right balance of these opposing ideals for the audience and purpose of any particular document.

The point I made today was that for design reports, “complete” and “correct” trump the others, though having all four is best.

I also explained to them that writing to the professor (as some had been doing) is a very difficult form of writing, because you are not trying to communicate the content, but some other “meta” information (like that you understand the content). I suggested that instead they should write to people like they were a few weeks ago: bright freshmen interested in engineering, and that their intent should be to provide all the information such students would need to continue the project.  I also talked about the need to include the dead-ends and how they worked around problems—as a professor, I’m not as interested in the final product as in their engineering thinking—how they tested and debugged their design.

Somewhere along the way I got into talking about doing search and what to do when you don’t know the right keyword.  For example, the centrifuge group had asked me by email to connect their Dremel tool to their rotor.  I sent them back the suggestion to use a rotary tool mandrel. What I hadn’t told them is how I chose that—I didn’t know that the part they needed was called a mandrel. So I explained, to the whole class, how I discovered that name by using Amazon and looking up Dremel tool, and finding that they had a “rotary tools accessories” category then looking through there until I found the term “mandrel”. My actual path was not quite how I described in class, and was probably a bit more efficient.  I actually started from “rotary tool cutoff”, because I was trying to remember how cutoff wheels were attached. On the first page there were several cutoff wheels and saws with mandrels, and even a mandrel by itself.  Redoing the search with “rotary tool mandrel” got me confirmation that I’d found the correct keyword.

After rambling about tech writing for a while, I let them break into groups and went to each group talking about what technical questions they had for their projects. For one group, I talked about hose clamps and angle brackets. For another group, I talked about H-bridges, and suggested they look into them as a possible alternative to using a relay (if they wanted to do PWM).  I was thinking of parts like the Infineon 5206, which I used in the HexMotor board, but I did not remember a part number to give them. Another group was wondering where to get parts around Santa Cruz.  I suggested that they try Santa Cruz Electronics, Computer Zone, or go over the hill to Frys.  Ace Hardware also came up.

They’ve got one more draft due on the last day of class (next Monday), for which I’ve promised feedback by Wednesday, with the final report due Thursday.

First college application sent

Last night my son got his first set of college applications sent off: University of California, which has its own idiosyncratic deadline and application form. UC does not ask for transcripts and does not want letters of recommendation—students have to enter all their transcript information into web forms.  The lack of letters of recommendation may be a blessing in disguise, as one of his recommenders has still not been able to get the Common App to accept her letter for him. The UC web forms are set up to be fairly easy (though tedious) for students at California high schools, since UC has a list of all UC-approved courses at each high school, but they are really a pain for a home school student.  We were lucky in that his home-schooling was done under a public-school umbrella (Alternative Family Education) that appeared on the drop-down list.  Otherwise, it would have been difficult even to say where he did his high school education.  The instructions for home-schoolers seem to be non-existent and figuring out where to tuck various bits of information was tough.

He ended up applying to 3 of the UCs (UCB, UCSB, and UCSD), though the only campuses he has visited are UCB, UCLA, and UCSC. Why the change?  Well, UCSC is too close to home—he needs to move to more independent living.  Our visit to UCLA made it very clear that undergrads in computer science there got almost no attention from faculty (unless the students were very strong at self-promotion) and acting was mostly restricted to theater arts majors. UCB was better—much better on the acting opportunities, with an attractive acting minor, but undergrads in computer science still had little research opportunity or interaction with the faculty.

We added UCSB primarily because of the College of Creative Studies (CCS) there, an honors college of about 300 students that (the website claims) has close faculty advising and is expected to do graduate-level research as undergrads. The computer science major within CCS looks quite interesting, and (if it lives up to its advertising) may represent a good compromise between the resources of a large university and the attention and nurturing of a small college. Unfortunately, we don’t have an equivalent of the Common Data Set numbers to know how selective CCS is nor does their web site really tell us what they are looking for.

One interesting point is that CCS has a supplementary application that is circulated among the faculty—we regard it as a good sign when the faculty care enough about their program to be involved in choosing who gets in, and when a university allows the faculty to have some say (most UC admissions keep the faculty completely out of freshman admissions—except for coaches at the sports-mad campuses, who seem able to get jocks in even when they don’t come close to being UC-eligible).  Note: transfer admissions at least at UCSC is different, with faculty in the intended department having final say about whether students can be admitted to the major.

UCSD was added as an afterthought, as having a reasonable engineering program while being easier to get into than UCB (38% instead of 17% for male freshmen—UCSB is even higher at 43%).  It is more of a safety school than a careful choice, but the marginal effort of doing an application to it was small—mainly trying to rank the six colleges there based on the very scanty information on the UCSD web site. If he gets in at UCSB or UCSD, but not one of his top three choices, we’ll probably end up doing another visit to southern California, to see how these two campuses feel to him.

The UC applications cost $70 per campus plus another $11.25 each to send SAT scores for a total of $243.75.  He’ll be applying to another 3–7 colleges, so I expect that application fees will end up costing around $1000.  When the cost of college visits and taking the SAT and AP tests in the first place is included, the cost of the application process rises to around $4000–5000.  That seems like a lot, but is dwarfed by the cost of college itself, which for us will be $120,000 to $240,000, depending on which college he goes to—the amount of financial aid that we qualify for seems to vary enormously from school to school.

UPDATE 2013 Dec 1: A reader just pointed out “You can have your official score report sent to one UC campus, and all campuses you apply to will receive it.” http://admission.universityofcalifornia.edu/freshman/requirements/examination-requirement/ I wish I’d noticed that buried in the instructions.  (I’d looked for it, but must have skipped over the line that said it.)

My son, like many high school seniors, has been struggling with the college application essays.  The two he produced for UC seem pretty good to me—one concentrates on the data logger project and is an adaptation of the essay he wrote for the Common Application prompt, while the other talks about why he chose to home school and what that has done for him.  Both essays managed to pack in a lot of information about him and his education, without sounding like laundry lists.

But it took him two weeks to write these essays whose combined length was just shy of the 1000-word limit.  He still has a large number of essays to write (1–3 per college application), and his writer’s block seems to get worse the more important the thing he is writing, so he’s been struggling most with the colleges he cares most about. I have the same problem—I can knock off a blog post like this one in an hour or two, but I have research papers still unfinished that should have been published a decade ago.

The huge amount of time each application takes means that there’s no way that he’ll be applying to the 100s of colleges who send brochures and postcards (most of which are getting recycled unread these days).  Occasionally one of the colleges will send a letter to “the parents of …”, and I sometimes read those for the amusement value, as most of them are so far off target as to be ludicrous.

The main limitation on how many colleges he applies to will probably be how many essays he can get done. I suppose that is why each selective college adds a bunch of essay questions to their application—not so much to find out more about the student as to reduce the flood of applicants to just those who are somewhat serious about attending. This selection process may be counterproductive though, as it would be much easier to churn out acceptable essays for schools he cared nothing about than to try to get a really good essay for a school he cares a lot about.

This weekend, I’m hoping he’ll get the essays done for one of his high-priority colleges (Harvey Mudd or Stanford, for example).

MathTwitterBlogosphere, mission 1

Sam Shah and other math bloggers have started a challenge to encourage more math-teacher blogging Mission #1: The Power of The Blog | Exploring the MathTwitterBlogosphere:

You are going to write a blog post on one of the following two prompts:

• What is one of your favorite open-ended/rich problems? How do you use it in your classroom? (If you have a problem you have been wanting to try, but haven’t had the courage or opportunity to try it out yet, write about how you would or will use the problem in your classroom.)
• What is one thing that happens in your classroom that makes it distinctly yours? It can be something you do that is unique in your school… It can be something more amorphous… However you want to interpret the question! Whatever!

I’m not a math teacher blogger—looking back over my posts for the past couple of years, I only see a few that are really about math education:

• MOOC failures in remedial math
• Hard Math for Elementary School
• In defense of programming for physics and math teachers
• Scientists need math
• Math joke
• Bad question for math classes
• AngryMath reviewed Udacity Statistics 101
• Out In Left Field: Two ways to ensure learning
• Free calculus book
• Santa Cruz Math Circle
• Awesome Math Camp

I use math all the time in my classes (complex numbers, trigonometry, and calculus in the Applied Circuits class; probability and Bayesian statistics in the bioinformatics classes), and I do reteach the math the students need, as I find that few students have retained working knowledge of the math that they need.  But it has been quite a while since I taught a class in which math education was the primary goal (Applied Discrete Math, in winter 1998).

So I fell a little like an imposter participating in this blogging exercise with the math teacher bloggers.

I don’t have any “favorite” open-ended or rich problems.  Most of the problems that I given in my classes have a heavy engineering design component, in either the circuits course or the bioinformatics courses.  Any good engineering design problem is an open-ended, rich problem.  If I had to pick a favorite right now, it would be from my circuits class: either the EKG lab (look for many posts about the design of that lab in the Circuits Course Table of Contents) or the class-D power amplifier (see Class-D power amp lab went smoothly and other posts).  But these are not the sort of “open-ended” problems that the MathTwitterBlogosphere seem to be interested in—the engineering design constraints that make the problems interesting are too restrictive for them, and a lot of them prefer videos to text (for reasons that seem to me to be based mainly on assumptions of the functional illiteracy of their students, though a few times a sounder justification is given). In any event, I doubt that any of the problems that I give to students would be appealing to math teachers, so they are not really germane to the MathTwitterBlogosphere challenge that Sam Shah put out.

It is hard to say what I do as a teacher that is “unique”. It is not a goal for me to be a unique teacher—I’d like to see more teachers doing some of the things I do, like reading student work closely and providing detailed feedback, or designing engineering courses around doing engineering design.

I may be unique in the School of Engineering in how much emphasis I put on students writing well, and how much effort I put into trying to get them to do so.  I created a tech writing course for the computer engineers and scientists back in 1987 and taught it until 2000.  More recently, I have provided many bioengineering students feedback on their senior theses, reading and giving detailed feedback on five drafts from each student in 10 weeks.   In my bioinformatics classes, I read the students’ programs very closely, commenting on programming style and the details of the in-program documentation—these things matter, but students get very little feedback on them in other classes. In the circuits course, I require detailed design reports for each of the 10 weekly assignments (though I encourage students to work in pairs for the labs and reports).  I evaluate the students almost as much on their writing as on their designs—engineers who can’t write up their design decisions clearly is pretty useless in the real world.

I’ve not done much about math writing, though a good class on mathematical writing (using Halmos’s How to Write Mathematics) would be a great thing for the university to teach. I have blogged before about writing in math classes, in my post Out In Left Field: Two ways to ensure learning, which is a response to a post by Katherine Beals: Two ways to ensure learning.  In my post, I distinguished between writing mathematics and the sort of mushy writing about mathematics that many high school teachers favor these days.

Centering engineering courses on doing engineering design is a very important thing, but it is not a unique contribution—I’m not the only professor in the School of Engineering who puts the lab experience at the center of a course design. Gabriel Elkaim’s Mechatronics course is a good example, as are most (all?) of the lab courses that Steve Petersen teaches.  In think that, in general, the Computer Engineering department does a good job of highlighting design in their courses, as does the Game Design major.  I just wish that more of the engineering classes did—especially those where it is much easier just to teach the underlying science and hope that students pick up the engineering later.

At the end of this post, I’m feeling the lack of a good conclusion—I don’t have any open-ended problems to share with math teachers, and I don’t have anything really unique about my teaching that will make math teachers want to emulate me.  I just hope that even a weak contribution to “Mission 1″ is useful, if only to make other participants feel better about their contributions.