Gas station without pumps

2016 June 8

End of quarter feedback

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 22:34
Tags: , ,

Before the last day of class, I sent my students an email message with some requests for feedback:

  1. The group tutor would like students to give him some written feedback on his performance as a group tutor, to improve his teaching skills.  This feedback goes only to him and does not affect his pay nor his job evaluation.
    The group tutor designed his own paper feedback forms and collected them from the students. Paper forms are a great way to increase participation in the feedback process, but I did not have the time or energy to do that this quarter. I don’t expect to see his feedback—it really was just for his benefit—unless he wants to discuss some of it with me.
  2. Parts and tools.  What parts and tools did you not use? what should have been included that wasn’t? What can be done to improve the parts kit next year?  I need to have the parts kit for BME 51A specified by the end of September, so I’ll be thinking about it over the summer.
    The students were upset at the resistor assortment not having a fairly uniform spacing of resistors. It would have been more useful to have the E6 spacing from 1Ω to 10MΩ (43 different values) than to have lots of odd sizes and nothing from  82kΩ to 1MΩ (the most useful part of the range for us). I’ll definitely be looking for a better resistor assortment next year, even if it costs more.
    I was particularly interested in whether the $10 handheld digital multimeter which I added to the parts and tools kit this year was worthwhile. A little less than half the class had used, but few felt strongly either way about including it (only 4 hands voted to drop it and only 4 to keep it—the rest were in the middle). I think that I either need to work it more directly into assignments (having students do some measuring at home in prelabs) or drop it. Best, perhaps, is to have it available as an optional add-on, but BELS is not happy with such arrangements.
  3. Lab order. When I split the course into BME 51A and 51B next year, one of the amplifier labs will end up in BME 51A.  Which one should it be?  I’m wondering whether it would be better to start with pressure-sensor lab, moving the microphone lab to BME 51B.  If I do that, what should the order of the labs be?
    Students agreed that the mic lab would not be the best way to end BME 51A, and thought that the pressure-sensor lab was more straightforward. They also would have preferred the audio labs (mic, speaker, pre-amp, and power amp) to be grouped together into a coherent unit. That may require even more radical reorganization than I had originally planned, since it would move not just 1 lab, but 2.5 labs from the first half to the second half, necessitating moving at least one more amplifier lab into the first half. That would also put many of the measurement and modeling labs (mic, loudspeaker, electrodes) into the second half, but I think we need to keep the modeling spread out.
    I can see I’ll need to give the schedule a lot of thought this summer.
    Students liked having the EKG last as a summary of almost everything else.
  4. Ideas for replacement labs.  Were there any labs you would have liked to have done that we didn’t have time for?  What should be removed to make room for them?  Is there any way to make a more “creative” lab, where students pick a design goal that is less tightly constrained than the current labs? Remember that the course is trying to serve all 4 concentrations, which means a wide variety of interests and skill sets.
    There were no comments in class on this topic.
  5. Book. I’ll be working on the book this summer. Which chapters need the most work (either new material or rewrites)?
    There were no comments in class on this topic. Email later said that most of the things they could think of were already in my to-do notes in the margins.
  6. Videos.  Was the oscilloscope video useful?  Should I make more lab equipment tutorial videos this summer? Any other short tutorial videos that might help?  (Even crummy videos take a lot of work, so I’d rather not spend a lot of time on ones that aren’t useful.)
    There were no comments in class on this topic, but I think I’m going to try to do some more videos with my son as narrator, anyway. One email later on said that the video was useful, but in-lab help from the group tutor or me was more useful. I agree with that, but it gets hard to scale up the personal contact, so I had to supplement with videos this year—I still plan to give a lot of oscilloscope direct help to pairs of students in labs, but the video is better than whole-class demos.
  7. Prelabs. Were the prelabs useful for preparing for the labs? Is there a way to make them more useful (and have a higher fraction of the students completing them)? The pace next year will be less hectic, and there should be more opportunity for lectures and questions before the prelabs are due.
    Students definitely felt the need for more time and more preparatory lectures before doing the prelabs. A lot of the prelabs were overwhelming to the students, and even I felt that the prelab before the preamp lab was much too long.  The slower pace next year and higher lecture/lab ratio should help. Those who did the prelabs found them very useful preparation for the labs, but I definitely need to rework the book to make the prelab exercises more obviously useful to the students.
  8. PteroDAQ. What improvements should be made to PteroDAQ? Do you foresee any uses for PteroDAQ in your future work?
    There were no comments in class on this topic, but a later suggestion was to add optional digital filtering to channels. That would be a useful addition, but one of the design goals of PteroDAQ was to avoid package dependencies, using only packages which were required parts of a Python installation. The scipy signal-processing package is very nice, but is not part of the standard distribution. Students with anaconda or enthought distributions (which include scipy) had more installation and update problems than those who just used the installation, in part because they ended up with multiple Python installations that had different libraries installed, and often ended up updating the wrong one.
  9. Gnuplot. Were the almost weekly lectures on gnuplot and model fitting useful?  Do you have a better appreciation of how to choose models for your data and fit the models to the data? Do you foresee using gnuplot in preparing reports for other classes or projects?
    There were no comments in class on this topic, but later email indicated that gnuplot was useful and they appreciated having freeware for high-quality graphics, but that more time needs to be spent on modeling and gnuplot—one student even suggested a full course on gnuplot and fitting models. There is a scientific visualization course being taught next year, using matplotlib in Python, though, not gnuplot. I like matplotlib also, but it requires more programming skill than gnuplot, and the model-fitting libraries available for Python are definitely far harder to use than gnuplot.
  10. Lab partners. Did the forced partner practice work for you? The intent was manifold: cutting the grading in half, having someone to talk with to reduce confusion, having someone to check your work, getting to know lots of your fellow students and their working styles (both in preparation for later group projects with them, and to get a better feel for the diversity of people you will work with in industry or academia), making sure that no one was able to freeload consistently, … .  Which of these intents worked, which didn’t?
    There were no comments in class on this topic. Later comments found the partners very useful—working alone on one lab was really tough, but that changing partners often was a good idea (one flaky partner in the quarter was enough, and being forced to have different partners lead to more of a taste of what it is like to work with different people).
  11. Lab time. Was 6 hours of lab a week enough time with the equipment?  Which labs needed more time? Is there a way to make lab time be used more efficiently, since it is a scarce resource on campus? Is there a way to move more of the lab activity out of the lab space?
    There were no comments in class on this topic. Later comments said that the lab time was enough when students came prepared, but that it was very useful to have an extra weekend lab time for overflow, especially for the soldering labs, which took more time to do and debug.  This year, having the reports due before that overflow lab time probably resulted in a number of unnecessary REDO grades, increasing both my grading workload and student stress. If I can make the reports due after students have a chance at the overflow time, things might work more smoothly.
  12. Electronics hobbyists. One of my less official goals in the course is to turn a few of the students each year into electronics hobbyists—people who will try to design or build small electronic things because it’s fun.  Did I have any success with that this year?
    As the feedback session was winding down, I had the students vote on 4 topics that I could talk with them about: motors (stepper motors, brushless motors, …), switching power supplies, internals of PteroDAQ, and resources for hobbyist electronics. Somewhat to my surprise, the resources for hobbyist electronics were the overwhelming favorite (about half the class), so I think that I did have some success in getting a number of students started on hobbyist electronics.  I don’t know how many will stick with it, but that’s ok—just having gotten them started was all I was aiming at.
    Students also suggested that the book contain more suggestions for hobbyist additions to go beyond the labs.

2015 January 2

Why doesn’t anyone comment on blogs?

Filed under: Uncategorized — gasstationwithoutpumps @ 13:27
Tags: , , ,

Nina Simon’s Muesum 2.0 blog post, What You Lose When You Become Embedded, and a Moment of Mourning for Blog Conversations, discusses how her posts start a lot of conversations that she is not privy to, and that she would really like to be included in discussions of her posts.

Problem is, I’m only part of a tiny fraction of those conversations. I’m learning less. I feel more lonely in my writing. It makes it harder to keep it up.

This “problem” disproportionately impacts only one of this blog’s thousands of users: me. For me, this content being embedded across different platforms and conversations is lovely in the abstract but frustrating in the day-to-day. I used to feel like a party host with really amazing guests. Now I feel like a street performer. I’m part of a bigger city. I supply some content but only get to talk with a few gadflies who stick close to the show (of whom I am very appreciative). One of my greatest blogging-related joys is when someone shares a blog post with a colleague and accidentally hits “reply” instead of “forward”—thus letting me in on their conversation.

This is what it means to be embedded. To not be the center of attention. To be used by someone else, somewhere else, without notification or participation. To be more important, but to feel less important.

In response to a comment of mine on the post, Nina Simon pointed me to another article about blog comments that she wrote way back in 2008, Museum 2.0: Why Doesn’t Anyone Comment on Your Blog?:

When people ask about blogging, the question of comments comes up more frequently than any other. It’s a bit strange. Why not ask more typical website questions, “why don’t more people visit my blog?” or “why don’t more people link to my blog?” There are many good ways to measure a blog’s value, but somewhere inside ourselves, we feel that comments are the thing that validate a blog’s existence. They prove that the conversation is two-way. They demonstrate that the blog is a more participatory vehicle than other kinds of media. So when people ask, “Why don’t more people comment?,” it gets me excited. It means that you are blogging because you want to hear from someone else.

In both her old post and her new one, she talks about why people don’t comment much. Although it is clear that she accepts the rather low ratio of commenters to readers, it is also clear that she would rather have more public conversations in her blog.

Me too.

The external commenting rate on my blog is about 0.6%—that is, about 6 comments from people other than me per 1000 views.  I’d like to have a rate more like 2–3%, that is, four or five times as many comments as I now get.

One of her commenters pointed out that a lot of ephemeral discussion happens on Facebook and Twitter, and that many people are intimidated by the greater permanence and public nature of blog comments.  Some of her lurkers have promised to try to comment more on her blog (though they recognized that this was likely to go the way of all New Year’s resolutions).

I don’t even have that comfort of triggering discussions on other platforms, as I doubt that my posts are getting much attention on Facebook or Twitter—the referral numbers to my blog from either is rather low. About 2/3 of my views are coming from search engine hits—people are looking for specific material that Google thinks they can find in one of my blog posts.  They may read just one blog post and not return, though I do have a (small) number of regular readers who subscribe to the blog.

One big difference, I suspect, between her blog and mine is that she has a fairly large community of regular readers on her blog, almost all of whom are interested in museum administration. They have a lot to say to each other. My more scattered posts on electronics, programming, teaching, home schooling, university administration, and random stuff that interests me does not result in a large, loyal following. People who are interested in only some of my posts may have nothing to say to people interested in other of my posts. When I put up a series of posts on one topic, I may lose subscribers who were only interested in one of the other topics.

I follow a lot of blogs (too many, actually, as it eats up too much of my time), and I try to comment on them whenever I have anything to say, because I know how much comments mean to blog writers. Even slightly stupid comments are better than silence. (I try not to make stupid comments, but I’m sure I do sometimes.) Some of my most frequent commenters are fellow bloggers whose blogs I comment on—we sometimes have blog conversations that are not contained just within the comments, but that trigger longer posts on our own blogs.  These are often quite satisfying conversations, which we are glad to share with other readers—and we invite you to join the conversation in the comments.

For those of you who don’t feel you have anything to say, here are some questions I’d like answers to: What brings you to my blog? What should I write about to keep your interest? What topics would you feel more comfortable commenting on?

I’m a bit of a fringe member of Nina’s blog community, having gotten interested in the Museum 2.0 blog mainly because of what she had done to turn the Museum of Art and History in Santa Cruz from a stodgy little provincial museum, of no interest to almost anyone, into a vital part of the community. I keep reading her blog, because she writes well and gets me thinking about things I would otherwise not consider, even if much of what she writes about has no application to my professional or personal life.

2014 August 28

PWM for incubator

Filed under: freshman design seminar — gasstationwithoutpumps @ 17:15
Tags: , , , , ,

I’ve been thinking that the freshman design seminar this year might design an incubator for bacterial cultures.  The idea would be to heat the air in a styrofoam box to try to get a constant temperature (maybe 35°C).  I got some free styrofoam boxes (interior about 16.5cm×28.5cm×32cm, or 15 liters) from someone who was getting rid of them, and I could probably get more at the monthly (quarterly?) styrofoam recycling days on campus.

The basic design would be to use a resistive heating element, a thermistor, and a simple microcontroller (probably an Arduino board, maybe the Uno32 boards that they use in CMPE 12 and 13) to do PWM control of the heater.  I happen to have a 9V 6A power supply on hand for another project, so I’ll design around that—it can also be used to power the Arduino. We’ll probably want to use a 5V processor, as most of the power FETs have fairly high threshold voltages, which rules out the 3.3V Uno32 boards.

I’ve been using AOI518 nFETs in the circuits class, but they have been discontinued, so I’m thinking of switching to either the AOI516 from Digi-key or the NTD4906N-35G from Mouser.  They are fairly similar parts with 10mΩ and 8mΩ RDSon, respectively.  The AOI516 has slightly higher resistance and slightly lower gate capacitance and gate charge, and so is probably a slightly less wide channel.  Either would work fine, and they are both 55¢—60¢ in 1s, and 24¢–35¢ in 100s.

I’d also need a high-power resistor.  I’d rather not use an incandescent light bulb as the resistor (resistance varies too much with temperature, and the light might be a problem for some cultures), so I looked at power resistors:

resistance rated power power @9V cost
10Ω 20W 8.1W $1.84
10Ω 50W 8.1W $2.53
10Ω 50W 8.1W $3.64
8.2Ω 50W 9.9W $2.25
4.7Ω 20W 17.9W $2.73
3.3Ω 25W 24.55W $3.56
50W 40.5W $2.31
50W 40.5W $3.64
1.8Ω 50W 45W $4.61

Note: resistors may reach case temperatures of 275°C at rated power (TE Connectivity SQ series datasheet, which only go up to 25W), which is above the ~240°C melting temperature for styrofoam, so it would be best to keep well below the rated power.   The temperature rise is not linear with power (looks roughly like a square root).  Based on the curves on the data sheet, keeping below 100°C would mean keeping power to about 20% of rated power.  The Tyco Electronics THS Series data sheet shows a surface temperature rise of 3°C/W for the 50W series, but is explicit that this assumes a standard heatsink of 535 cm2, 1mm thick, and is probably more related to the thermal resistance of the heatsink than any properties of the resistor.  Temperature rise without a heatsink is not given, but obviously much larger—the 50W resistor is limited to 20W without a heatsink.  (Note: TE Connectivity and Tyco Electronics appear to be two different names for the same company—Tyco Electronics appears on the older datasheet.)

Power derating curves for the Tyco THS series suggest that the 20W limit means the case temperature would be around 220°C,  since that is the heatsink temperature at which the resistor would be limited to 20W.  If we naively assume a linear temperature rise with power for the surface temperature, then 8.1W would result in about a 105°C surface temperature. But if convection is being used rather than thermal conduction, we’d expect a higher temperature rise than this—maybe more like a 150°C surface temperature (assuming power goes with the square of the temperature difference from ambient). Of course, adding a heat sink or a fan would make a big difference.

For fans, 5V and 12V fans are very common, but 9V ones are rare.  It might be possible to run a 12V fan at 9V, with reduced performance, or the fan might not spin at all.  The students would probably want to design around 12V.  They might need to add a series resistor to drop the voltage a bit before powering the Arduino board.  Assuming about 35mA for the Arduino board, a resistor to drop the voltage to 8V would be around 120Ω.  The Arduino could probably draw 45mA before the IR drop would be enough to start causing problems with the LDO voltage regulator on the Arduino board.

Fans are rated by air flow and static pressure, which correspond roughly to the short-circuit current and open-circuit voltage of  a linear circuit:  putting a straight line between the air flow at 0 back pressure and the back pressure at 0 air flow gives a reasonable approximation to the behavior of the fan under different conditions.  Even a very cheap fan will provide 10.7 cu ft/min with no back pressure and 1.4 mm H2O at 0 flow running at 12V.  In reasonable units that is 5 l/s and 13Pa (a very low back pressure—this is a wimpy fan). Another cheap fan will provide 37CFM (17.5 l/s) or 0.15 in H2O (37Pa) at 12V, and its data sheet claims that it will start and can run on as little as 4.5V.

So stirring up a 15l box means a full circulation about every 1–10s—a veritable windstorm!  Even if the back pressure and low voltage cuts the flow rate to a third it is still plenty. Of course, if there is too much air flow, we could use PWM on the fan as well—full power to start it, then adjust the duty cycle to adjust the air flow. For $5.14 I could get a fan with tachometer feedback (useful for teaching students feedback control) and for $7 I can get a fan with both tachometer output and built-in driver for PWM (just needing a logic-level input).

I’ll want to order some parts to try out the designs, to see if there are some hidden problems that I’ll have to prepare students for. For power resistors, Mouser seems to have better prices than Digi-key, but Digi-key has them beat on prices and variety of fans.  DigiKey also has the better parametric search capability—I can tell the 3-wire fans (with tachometer) from the 2-wire ones at a glance or search for them, without having to click through to each fan for the spec sheet, as I would on Mouser or Jameco sites.

I think that the biggest problems for students will be in getting the control loops to work.  On-off control will have a huge swing, because of the delays in getting temperature changes at the sensor after power is applied to the resistor.  Proportional control will be a bit better, but they’ll probably have to go to PI (proportional-integral) control, which could be challenging for freshmen who’ve not finished calculus.  I don’t think we’ll even try for PID (proportional-integral-derivative), because of the difficulty of tuning the derivative term—but I’ll probably try that myself.

The project should probably start with making a thermistor-based thermometer (like in the first circuits lab) and seeing how fast the temperature rises in the box with various power levels to the resistor (probably by adjusting voltage and current, but maybe by adjusting PWM).  Seeing how fast the box cools from a given temperature would also be important.  We’d probably want the fan running continuously for these experiments, and both the fan and the resistor mounted on a piece of wood, hardboard, or MDF (medium-density fiberboard), to avoid the resistor coming into contact with the styrofoam.

Then they could try on-off control to see how much overshoot they get in response to a setpoint change, or in response to a disturbance (like opening the box and closing it again).

After that they could see whether proportional control gets less overshoot (but probably observe droop, where the setpoint is missed).  Finally we could add integral control to correct the droop.

At the same time that they are working on getting the control loop working, they can be building mechanical parts for the incubator (shelving, baffles for improving air circulation, external air for cooling?, control panel, … ).

2014 April 7

Feedback on first lab report

Filed under: Circuits course,Printed Circuit Boards — gasstationwithoutpumps @ 17:11
Tags: , , , , ,

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.

    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 (cos(\omega t))^2 =\frac{1}{2} (1-cos(2 \omega t)), 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.


2013 November 12

Grading programming assignments

Filed under: Uncategorized — gasstationwithoutpumps @ 09:48
Tags: , , ,

In Critiquing code, I mentioned that I spend a lot of time reading students’ code, particularly the comments, when grading programming assignments.  For the assignment I graded this weekend, I did not even run the code—grading students entirely on the write-up and the source code.

The assignment is one that involves writing a simulation for a couple of generative null models, and gathering statistics to estimate the p-value and E-value of an observed event.  Running their code would not tell me much, other than detecting gross failures, like crashing code.  The errors that occur are subtler ones that involve off-by-one errors, incorrect probability distributions for the codon generator, or not correctly defining the event that they are counting the occurrence of.  These errors can sometimes be detected by looking at the distribution of the results (particularly large shifts in the mean or variance), but not from looking at a small sample.  The students had available plots of results from my simulations, so they could tell whether their simulation was providing similar results.

So I read the write-ups carefully, to see if the students all understand p-value and E-value (this year, sadly, several still seem confused—I’ll have to try again on improving their understanding), to check whether the distributions the students plotted matched the expected results from my simulations and previous years’ students, an to see whether the students explained how they extracted p-values from the simulations (only a a couple of students explained their method—most seem to have run a script that was available to them without even reading what the script did, much less explaining how it worked).

Whenever I saw a discrepancy in the results, I tried looking for the bug in the student code.  In well-written, well-documented code, it generally was fairly easy to find a bug that would explain the discrepancy.  In poorly written, poorly documented code, it was often impossible to figure out what the student was trying to do, much less where the code deviated from the intent. Even when the results appeared to be correct, I looked for subtle errors in the code (like off-by-one errors on length, which would have been too small to appear as a change in the results).

There was only one program so badly written that I gave up trying to figure it out—the student had clearly been taught to do everything with classes, but did not understand the point of classes, so he turned every function into its own class with a __call__ method.  His classes mostly did not have data in the objects, but kept the data in namespaces passed as arguments.  The factoring into classes or functions bore little resemblance to any sensible decomposition of the problem, but had arbitrary and complex interfaces. The result looked like deliberately obfuscated code, though (from previous programs by this person) I think it represented a serious misunderstanding of an objects-first approach to teaching programming, rather than deliberate obfuscation.  I instructed the student to redo the code without using any classes at all—not an approach I usually take with students, but the misuse of classes was so bad that I think that starting over with more fundamental programming concepts is essential.

Some of the students are now getting fairly good at documenting their code—I don’t seem to have any superstar programmers this year, but there are a couple of competent ones who are likely to do good work on their theses (assuming they don’t discard the documentation habits I’m enforcing in this course).  Some of the students who started out as very poor programmers are beginning to understand what it takes to write readable, debuggable code, and their programs have improved substantially. Many of the students have figured out how to separate their I/O, their command line parsing, and their computation into clean separate parts of their code, without sacrificing much efficiency. Even several who were writing very confusing code at the beginning of the course have improved their decomposition of problems, simplified their style, and improved readability of their code enormously.

In one comment on Critiquing code, “Al” commented “I would guess it has more to do with grit and the ability for a student to stick with a tough problem to find a solution.” I rejected that interpretation in my reply: “some of the worst programmers are putting in the most effort—it is just not well-directed effort. The assignments are supposed to be fairly short, and with clean design they can be, but the weaker programmers write much longer and more convoluted code that takes much longer to debug. So ‘grit’ gets them through the assignments, but does not make them into good programmers. Perhaps with much more time and ‘grit’, the really diligent students could throw out their first solutions and re-implement with cleaner designs, but I’ve rarely seen that level of dedication (or students with that much time).”

Now I’m not so sure that my reply was quite right. Some of the biggest improvements seem to be coming from students who are working very hard at understanding what makes a program good—when I complain about the vagueness of their variable descriptions or their docstrings, they improve them in the next assignment, as well as redoing the programs that elicited the feedback. But some of the students are falling behind—neither redoing assignments which they got “redo” on, nor keeping up with the newer assignments.  So there may be some merit to the “grit” theory about who does well—it isn’t predictive for any single assignment, but it may help distinguish those who improve during the course from those who stay at roughly the same level as they entered the course.

Next Page »

%d bloggers like this: