Gas station without pumps

2014 June 22

Internships in engineering

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

There has been a lot written in the past year about unpaid internships and how they are (mostly) illegal ways of skirting labor laws.  Internships in engineering have not been that way as long as I can remember (which means the last 40 years in this context).  More typically, internships in engineering fields pay entry-level wages and are treated like entry-level jobs, except without the expectation of long-term employment. Companies often hire from their pool of interns, though, so the internship is something like probationary hiring.

Here is an example of a (somewhat poorly written) ad for an internship opportunity at a local company that is part of the game-design industry.  I’ve left off the company name and contact information, because I don’t know how widely they were circulating the internship offer. I also rearranged some lines that seemed to have been scrambled in the e-mail copy I got of the job announcement.

Internship Highlights:

  • 3–6 month duration, full-time during summer, p/t an option in the fall
  • $20-$30/hr salary range, depending on experience
  • Seeking CS students with the following backgrounds and interests:
    • Data friendly—most of what they do centers around data of various types
    • Statistics friendly—same as above
    • Don’t require lots of pre-existing knowledge
    • * Do require the ability and desire to learn
  • Ongoing development in three areas:
    • Web App—they have a python (django) based web-app; HTML & Javascript
    • Client work—they have client libraries that run on phones and tablets. This is actually more about client libraries like Unity or Corona than it is about core device programming
    • Server work—they’re a java shop on the server side. 
  • In all areas, students with prior experience are preferred (i.e. client engineers who’ve used a game development framework before; server engineers who’ve written Java code, etc.)

Note that this internship favors experience, but it not calling out “must-have” specific platforms or languages. The (fairly small) company uses Python, Javascript, and Java all on the same project, with multiple different libraries—it remains useful for students to have learned several different programming languages and frameworks.

Also interesting is the specific request for students who know statistics—something that CS departments have historically not bothered teaching.  Even with the recent emphasis on “big data”, the CS degree at UCSC requires no statistics, only a course on probability. If I were advising CS students, I’d suggest that they take the statistics course which is the followup to the probability course they are required to take.  Currently, their list of approved electives doesn’t even include the statistics 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 March 22

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.

2014 February 19

Twelfth day of freshman design seminar

Filed under: freshman design seminar — gasstationwithoutpumps @ 23:12
Tags: , , ,

My counts of which days were which in the freshman design seminar were all messed, so three of my blog posts were misnamed:

date which day of class blog post
Mon 2014 Jan 6 1 First day of freshman design seminar
Wed 2014 Jan 8 2 Second day of freshman design seminar
Mon 2014 Jan 13 3 (Baskin lab tour) Third day of freshman design seminar
Wed 2014 Jan 15 4 Fourth day of freshman design seminar
Wed 2014 Jan 22 5 Fifth day of freshman design seminar
Mon 2014 Jan 27 6 Sixth day of freshman design seminar
Wed 2014 Jan 29 7 (Biomed lab tour) Biomed lab tours and online discussions
Mon 2014 Feb 3 8* Seventh day of freshman design seminar
Wed 2014 Feb 5 9 no post (ill and group tutor ran class)
Mon 2014 Feb 10 10* Ninth day of freshman design seminar
Wed 2014 Feb 12 11* Tenth day of freshman design seminar
Wed 2014 Feb 19 12 Twelfth day of freshman design seminar (this post)

Today we started by having the students turn in their Arduino programming homework, then start writing the program as a group. I told them that I particularly wanted those who had trouble with the assignment to provide input—I’m trying to get them to realize that questions and confusion are normal, and that the right action to take in college is to ask questions, rather than to hide ignorance.

This particular assignment was expected to be hard for them—I had not done the scaffolding for it that I had originally planned, but threw them into it with very little preparation. I told them that, but also that I was trying to get them used to looking things up and figuring them out, rather than waiting to be told exactly what to do. Again, I’m trying to get them out of the “regurgitate what the teacher said” mode that K–12 education has trained them into. If I accomplish nothing else this quarter, I hope to increase their willingness to ask questions (of their teachers and of the things they read).

We did get the program written, with some digressions into the difference between “==” and “=” in C++ and the convention in C and C++ that 0 is false and any other value is true. I also managed to work in the importance of good variable names to tell people what things meant, though this particular program doesn’t need any variables.  The students now have the notions of serial execution, conditional expressions, if-statements, digital I/O, serial communication (we had a digression into baud rate), and the Arduino setup/loop structure, which may be enough for their projects—they may also need analogRead(), which I should be sure to demo on Monday.

I then typed in the program we had created together and demoed it with Arduino. I had deliberately left in a bug that I had spotted (no space between the printing of the different fields), and the class spotted it and came up with a reasonable correction when the first output came out.

We only had about 10 minutes left, so I gave them feedback on their project proposals:

  • Type homework for college classes!  Two of the groups had turned in hastily scribbled notes.
  • Give explicit specifications for the project.  How big an incubator? How precisely does the temperature need to be controlled? How fast does temperature have to change for PCR? What temperatures are needed and how precisely? How many tubes need to be run through the PCR machine at once?  How much acceleration does the centrifuge need to produce? How precisely does the speed need to be controlled?
  • Provide a block diagram giving all the components of the system (power supply, motor, fan, rotor, temperature sensor, … ) and lines showing the connections.  I talked about the importance of specifying the interfaces between components so that people could work simultaneously on different parts, and the need to renegotiate interfaces if the initial specification of them caused problems.

We talked a bit about prototyping—I want them to build something and learn enough to make an improved design, even if they don’t get a fully functional prototype.

For Monday, I assigned them the task of fleshing out the specifications for their project and producing a block diagram, filling in as many details as they could.  The group tutor is going to try to find time to meet with each group for an hour before then, to help them with flesh out their designs.

 

2014 February 2

CS is not a foreign language

Filed under: Uncategorized — gasstationwithoutpumps @ 07:40
Tags: , ,

The Computer Science Teachers Association recently had a blog post about a recent development in high school CS teaching, Why Counting CS as a Foreign Language Credit is a Bad Idea.

When these policy makers look at schools, they see that computer science is not part of the “common core” of prescribed learning for students. And then they hear that Texas has just passed legislation to enable students to count a computer science course as a foreign language credit and it seems like a great idea.

But all we have to do is to look at Texas to see how this idea could, at the implementation level, turn out to be an unfortunate choice for computer science education. Here are the unintended consequences

  1. If a course counts as a foreign language course, it will be suggested that a new course must be created.
  2. If a new course is created, chances are that it won’t fit well into any of the already existing course pathways for college-prep or CTE.
  3. This new course will be added to the current confusing array of “computing” courses which students and their parents already find difficult to navigate.
  4. There will be pressure brought to ensure that that course focuses somehow on a “language”. For the last ten years we have been trying to help people understand that computer science is more than programming. Programming/coding is to computer science as the multiplication table is to mathematics, a critical tool but certainly not the entire discipline.
  5. If this new course is going to be a “language” course, we have to pick a language (just one). And so the programming language wars begin.

I agree that computer science should count as a math or science credit, not a foreign language credit.  CS and foreign language use different mental skills. For one thing, the “grammar” taught in programming languages is deliberately very much simpler than natural language grammars—so much so that there is little transference between learning on and learning the other.  Also, foreign language courses include a lot of memory work (particularly vocabulary, but also conjugation and declension patterns in many languages), while beginning computer science courses are more about learning how to design and debug—that is, to develop problem-solving skills, not memory skills.

Foreign language instruction is also very important, and replacing it with computer science would not be helpful for the cultural understanding and ease of relations between different countries that is an important reason for teaching foreign languages. Decreasing foreign language to make room for computer science is short-sighted.

The most sensible classification for CS (if it needs to be classified in the narrow categories that guide secondary school administrators) is with math.  The reasons for learning CS are much the same as the reasons for learning algebra, both in terms of the underlying set of mental skills that one hopes would transfer to other fields (but usually don’t) and the usefulness as a base for future study in STEM fields.

I think that the claim “Programming/coding is to computer science as the multiplication table is to mathematics” is a bad analogy.  Closer would be “Programming/coding is to computer science as algebra is to mathematics”.  Programming is a much larger and more complicated skill than multiplication, and it underlies most of the rest of computer science. Multiplication is primarily a memory skill (multiplication tables and a simple algorithm), while programming is primarily a problem-solving skill.

I also agree with the concern that making CS a “foreign language” skill will put even more pressure on high schools to adopt a common programming language.  The College Board AP test has already blessed Java, which I think is a poor choice for a first teaching language (though I know that many computer science professors like it as a first language, for many of the same reasons I dislike it).  I prefer Scratch followed by Python, as I’ve explained before on this blog.

Standardizing the way computer science is taught would be a moderately bad thing, as there is no “one true path” that produces great programmers and computer scientists. I see value in having a variety of different pedagogical approaches to teaching programming (and computer science), as the first few programming languages one learns tends to color the way one things about programs for several years.  I believe that a diversity of different approaches to programming is important to the health of the computer science both as an academic pursuit and as an industry—and different initial programming experiences is as important to that diversity as different people are.


Note: I tried to post a comment on the original post, but I kept getting

Server error!

The server encountered an internal error and was unable to complete your request.

Error message:
Premature end of script headers: mt-comments.cgi

If you think this is a server error, please contact the webmaster.

Error 500

You’d think that the Association for Computing Machinery could keep a blog running, but I guess their disdain for mere “programming” extends to the programmers who set up their website.

« Previous PageNext Page »

%d bloggers like this: