Gas station without pumps

2014 October 13

Say this, not that

Filed under: Uncategorized — gasstationwithoutpumps @ 17:00
Tags: , , , , ,

This summer I bought my son a book to prepare him for college: Say This, NOT That to Your Professor: 36 Talking Tips for College Success. He read most of it, and found it to be reasonably well-written, somewhat poorly copy edited, and worth reading once. Most of the advice in the book he felt was just common sense, but that only means that he has been raised in an academic culture.  What the child of a professor sees as common sense in dealing with professors may seem arcane for someone coming from a different culture—perhaps the first in their family to go to college.

For the past 3 years, over half of our admitted students are first in their family to go to college. So what my son finds “common sense” may be the cultural knowledge of academia that many of the students at UCSC are missing.

After my son left for college, I decided to read the book for myself, to see if it was worth recommending to students at UCSC.

The author, Ellen Bremen, apparently teaches communication at a two-year college (Highline Community College in Des Moines, WA, about an hour and a half south of University of Washington by public transit), and some of the advice she gives seems to be more directed at two-year college students than research university students.  For example, she provides no advice on how to ask a faculty member if you can join their research group, because most 2-year college faculty have no time to do research, but she provides a lot of information about what to do when you miss half a quarter’s classes.

Her example students also seem to be a bit more clueless than the students I see at the University of California.  Perhaps this is because of the stricter admission criteria to UC, or perhaps she has selected the most extreme cases to use as illustrations. Or maybe I just haven’t dealt with enough freshmen—I generally see students in their sophomore through senior years, after they’ve had a chance to get acculturated to academia.

About 3/4 of Bremen’s book is dedicated to what students do wrong, and the last quarter to how students can deal with professors who screw up—about the right ratio for a book like this. Although the actual incidence of student mistakes and faculty mistakes is a larger ratio (more like 10:1 or 20:1), the student mistakes tend to fall into the same sorts of things over and over, with only the players changing names, so a 3:1 ratio is reasonable.

The advice she gives is generally good, though she recognizes only the teaching role for faculty, and assumes that all faculty have as much time and desire to meet one-on-one with students as she does.  At UC, many of the professors see their research role as more important than their teaching role (and the promotion process, summer salary, and publicity about faculty activity clearly favor this belief), so faculty are a little less willing to dedicate 10 hours a week to office hours or meet with students at random times outside office hours. I’m doing a lot of additional appointments this quarter, and it really does break up the day so that I can’t carve out a chunk of time for writing papers or programming.  In previous years I’ve kept one day a week free for working from home, free from student interruptions and meetings all over campus, but this quarter I’ve not been able to do that, so my research time and book-writing time has dropped to almost nothing.  Just coping with the pile of email from students every few hours eats up my day.  I find that a lot of student requests can be handled more efficiently by e-mail than by scheduling meetings—the extra non-verbal communication that Ellen Bremen is so fond of often gets in the way of the actual business that needs to be transacted.

Overall, I think that Bremen’s book is a good one, even if some of the advice is slightly different from I would give.  I think that she would do well to work with a second author (from a research university) for a subsequent edition, to cover those situations that don’t come up much at 2-year colleges.  Despite those holes, I still recommend the book for UC students, particularly first-in-family students.



2014 September 25

Details matter

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

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

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

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

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

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

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

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

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

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

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

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

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

2014 June 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 April 11

Arthur Benjamin: Teach statistics before calculus!

I rarely have the patience to sit through a video of a TED talk—like advertisements, I rarely find them worth the time they consume. I can read a transcript of the talk in 1/4 the time, and not be distracted by the facial tics and awkward gestures of the speaker. I was pointed to one TED talk (with about 1.3 million views since Feb 2009) recently that has a message I agree with: Arthur Benjamin: Teach statistics before calculus!

The message is a simple one, though it takes him 3 minutes to make:calculus is the wrong summit for k–12 math to be aiming at.

Calculus is a great subject for scientists, engineers, and economists—one of the most fundamental branches of mathematics—but most people never use it. It would be far more valuable to have universal literacy in probability and statistics, and leave calculus to the 20% of the population who might actually use it someday.  I agree with Arthur Benjamin completely—and this is spoken as someone who was a math major and who learned calculus about 30 years before learning statistics.

Of course, to do probability and statistics well at an advanced level, one does need integral calculus, even measure theory, but the basics of probability and statistics can be taught with counting and summing in discrete spaces, and that is the level at which statistics should be taught in high schools.  (Arthur Benjamin alludes to this continuous vs. discrete math distinction in his talk, but he misleadingly implies that probability and statistics is a branch of discrete math, rather than that it can be learned in either discrete or continuous contexts.)

If I could overhaul math education at the high school level, I would make it go something like

  1. algebra
  2. logic, proofs, and combinatorics (as in applied discrete math)
  3. statistics
  4. geometry, trigonometry, and complex numbers
  5. calculus

The STEM students would get all 5 subjects, at least by the freshman year of college, and the non-STEM students would top with statistics or trigonometry, depending on their level of interest in math.  I could even see an argument for putting statistics before logic and proof, though I think it is easier to reason about uncertainty after you have a firm foundation in reasoning without uncertainty.

I made a comment along these lines in response to the blog post by Jason Dyer that pointed me to the TED talk. In response, Robert Hansen suggested a different, more conventional order:

  1. algebra
  2. combinatorics and statistics
  3. logic, proofs and geometry
  4. advanced algebra, trigonometry
  5. calculus

It is common to put combinatorics and statistics together, but that results in confusion on students’ part, because too many of the probability examples are then uniform distribution counting problems. It is useful to have some combinatorics before statistics (so that counting problems are possible examples), but mixing the two makes it less likely that non-uniform probability (which is what the real world mainly has) will be properly developed. We don’t need more people thinking that if there are only two possibilities that they must be equally likely!

I’ve also always felt that putting proofs together with geometry does damage to both. Analytic geometry is much more useful nowadays than Euclidean-style proofs, so I’d rather put geometry with trigonometry and complex numbers, and leave proof techniques and logic to an algebraic domain.

2014 January 1

Technical entitlement—is it a thing?

Filed under: Uncategorized — gasstationwithoutpumps @ 18:49
Tags: , , ,

I learned a new buzzword yesterday: “technical entitlement”.  I encountered the phrase on  the blog On Technical Entitlement |, though apparently Tess Rinearson originally wrote it in June 2012 and also published it on

I’m the granddaughter of a software engineer and the daughter of a entrepreneur. I could use a computer just about as soon as I could sit up. When I was 11, I made my first website and within a year I was selling code. I took six semesters of computer science in high school, and I had two internships behind me when I started my freshman year of college.

Despite what it may seem, I’m not trying to brag—seriously. I’m just trying to prove a point: I should not be intimidated by technical entitlement.

And yet I am. I am very intimidated by the technically entitled.

You know the type. The one who was soldering when she was 6. The one who raises his hand to answer every question—and occasionally tries to correct the professor. The one who scoffs at anyone who had a score below the median on that data structures exam (“idiots!”). The one who introduces himself by sharing his StackOverflow score.

That’s technical entitlement.

“Technical entitlement” seems to be the flip side of “imposter syndrome”. In imposter syndrome, competent people question their own competence—sometimes giving up when things get a little difficult, even though an outside observer sees no reason for quitting.  “Technical entitlement” seems to be blaming those who have both competence and confidence—as if it were somehow deeply unfair that some people learned things before others did.

Certainly some things are unfair—as an engineering professor I’ve been able to provide opportunities for my son to  learn computer science and computer engineering that would not be available to a parent who knew nothing about those fields.  And some of the characteristics she lists would apply to my son—I can see him correcting his professors, and although he’d never introduce himself by sharing his StackOverflow score, he did include it in some of his college essays, as evidence that he was knowledgeable and interested in sharing what he had learned.

But Tess Renearson goes on to say

It starts with a strong background in tech, often at a very young age. With some extreme confidence and perhaps a bit of obliviousness, this blooms into technical entitlement, an attitude characterized by showmanship and competitiveness.

While my son has confidence in his abilities and “perhaps a bit of obliviousness”, neither showmanship nor competitiveness are big factors in his behavior.  I think that Ms. Renearson has confused a personality trait and stereotypical US male behavior (showmanship) with early technical education. I see the arrogance as a bad thing, but the early technical education (which she herself had) as a good thing.

The rest of her post goes on to talk about ways that Amy Quispe and Jessica Lawrence managed to increase participation (particularly by women) in tech events.  But the analysis there really addresses imposter syndrome more than it does “technical entitlement”.  She quotes Jessica Lawrence: ‘“There is,” she said, “an under-confidence problem.” But Ms. Renearson then says

Sound familiar? Yep, it’s exactly the kind of self-doubt that can arise when there are so many technically entitled people around.

Somehow blaming “technically entitled people” for the under-confidence of others seems to be imposing blame where none is warranted.

Now imagine someone starting out as a college student taking their first CS course. Imagine how the technical elite make them feel.

I can understand someone being intimidated when entering a new field if they are surrounded by people more skilled in the field—but that is hardly the fault of the those who are skilled.  Newcomers anywhere are going to feel out of place, even when people are trying to welcome them. The “technical elite” are not making the newcomers feel intimidated.

If Ms. Renearson’s point is that some of the tech communities are not sufficiently welcoming of newcomers, I agree.  I’ve seen snarky comments in places like Stack Overflow that offered gratuitous insults rather than assistance.

But Ms. Renearson seems to assume that anyone who is more experienced than her is automatically trying to put her down, and that this is the way that everyone should be expected to feel.  When one starts with that assumption, there is no remedy—no matter what those more experienced or more skilled do, they will be seen as threatening.

Perhaps she has not identified those who should be getting blamed precisely enough.  I don’t think that it is “The one who was soldering when she was 6″ who is a problem, but those who refuse to give children an opportunity to learn (no public school in my county teaches computer science, except one lottery-entry charter) or who force students who’ve been programming for 6 years into the same classes as those who have never programmed, as many college CS programs do, providing no way for more advanced students to skip prerequisites.

Unfortunately, identifying the problem as being “technical entitlement” makes the problem worse not better, as it encourages public schools to suppress the teaching of technical subjects, rather than expanding them.

If she means to attack the arrogant culture of “brogrammers”, mean-spirited pranks, and other unpleasant culture that has emerged, then I support her, as I’m not happy with some of the culture I see either.  But don’t blame it on the kids who learned tech early, nor on the parents who taught them—the late-comers are more likely to be the arrogant bastards, since that arrogance is mainly a defense mechanism for incompetents.  The competent tech people are much more likely to be eager to share their enthusiasm with newcomers and help them join in the fun.

Next Page »

The Rubric Theme. Create a free website or blog at


Get every new post delivered to your Inbox.

Join 276 other followers

%d bloggers like this: