Skip to content

Two keys to a failed CS education

I think there are two keys to why I was a successful electrical engineer, when I did not (initially) succeed as a computer scientist—despite being more interested in the latter, to begin with, and despite wanting to pursue the latter now.

The first key: invisible struggle, no displays of fallibility

I went to the University of Virginia as an undergrad. I transferred into the Engineering School a year in, which put me approximately one semester behind my peers. I chose Electrical Engineering (EE) instead of Computer Science (CS), even though it was a CS major who convinced me to switch. You see, I fell for a lot of the misconceptions laid out in Unlocking the Clubhouse: despite evidence to the contrary (I earned a high enough grade in the class to be hired as a teaching assistant for CS 101 in my second semester of college), I didn’t believe I could compete* with people who had been programming for their whole lives; and I vastly over-estimated how many people really fell into that bucket.

Also, because nobody told me that programming is hard for everyone when they start, I didn’t think CS was a field where I could be successful. I didn’t see everyone around me struggling, the way I did in my first EE class (which, to be fair, was pretty hellish).

Classic blunders.

I think that points to an important difference between my EE and CS education: I saw other EEs fail as often as I failed. Although it sounds that way, this isn’t me being modest, or feeling like an impostor, or anything else; I worked very hard and did very well. But I also know that a large part of my success comes from my peers and me taking time outside of class to teach each other the things the faculty didn’t see fit to impart; the homework assignments were too hard for us to do otherwise, because we were (deliberately?) not taught how to solve our homework problems in class. This is a common experience in engineering and, apparently, in physics — this Medium article does a fantastic job of explaining what’s wrong with teachers refusing to teach (though it comes with a trigger warning: it was written in the aftermath of a professor sexually harassing students).

So, one key to how my EE experience differs from CS is that I got to see my peers struggling, and it got me past my initial concern that they had all been tearing apart VCRs and putting them back together since the age of 10. (It was a very specific fear: I remember, it was VCRs, specifically, not watches or robots or anything else. Perhaps that points to a lack of imagination on my part.)

In CS, all of the assigned work was individual, and the focus on the school’s Honor Code meant that we were afraid to work together. I saw other CS students in the computer lab, but I didn’t know they were struggling as hard as I was. Even after working as a TA and helping people through their struggles, it took me more than a decade to internalize the fact that CS, like most things, is hard for beginners.

So, key one: In CS I kept believing the “everyone has been programming forever” lie, combined with the “I am not naturally good at this, and other people are” lie. In EE it was actively disproven, pretty much immediately.

The second key: starting with ‘hello world’

Not a great place to start
Not a great place to start

But there was one other key to my success as an electrical engineering student: I took the “intro to EE for non EEs” course that they were piloting at the time—even though, unfortunately (for them), most of my colleagues didn’t join me in taking it. In that class we got an introduction to the broader field, with short descriptions of the various sub-fields of EE and beginner-level introductions to concepts we would later be taking in-depth classes on. The portion of the class dealing with information theory and signal processing gave me the background to understand several really difficult subjects when they were introduced (poorly) in 300-level classes, and that confidence (bolstered by the experience of explaining it to some of my peers) ultimately led me to double-specialize in “Communications” (by which I mean wireless engineering, signal processing, etc.), along with “Computers/Digital” (processor and chip design, etc.).

I would probably not have become a wireless engineer without that experience.

CS, on the other hand, had nothing like that. CS 101 was “Hey, here’s how you program really simple stuff in C++. Also, ignore half of what you’re typing.” It wasn’t “Here are the sub-fields of computer science,” or “Here are introductory-level explanations of some of the important stuff we’ll talk about later,” both of which would have been better.

CS 101 should be an introduction to the field of computer science and computer programming, not a first programming course. It should consist of a little Boolean logic, maybe some control flow (i.e. loops), and some basic information about data structures; then, “here’s what an algorithm is”; then, some high-level information about computer networks; then, maybe slip in something about software testing and/or version control; and, finally, it should definitely include an exploration of the differences between web programming, DevOps, middleware, and math-heavy CS research. Not only would that class help people understand the field and how they might like to be part of it; it would also improve interview questions, later on. (Seriously, front-end developers don’t need to know how to implement QuickSort!)

There are lots of important changes we should be making to the way CS is taught, but when we’re looking at how to find and retain students for a four-year major, I think adding a high-level class before beginning programming would help tremendously. It’s certainly better than the then-popular (and, I sincerely hope, now-outmoded) practice of making the second programming course into a “weeding” class—a course so hard that half the students quit or fail, then change majors. And I think that, in the process of designing the intro course’s curriculum, the CS faculty might find themselves rethinking the whole major. So, yes, you could say I’m proposing a band-aid, and I agree; but it might also be a first step to structural change.

*In an environment where grades are issued on a curve, education is a competition. Assignments and tests were so hard at UVA’s engineering school that one time I got 38% on a midterm, and that translated to an A. (back)


Published incommunicationengineeringfailsprogrammingteaching and learning


  1. Mariecris

    I agree. I always felt it was language that cs people just new. It was easy for them.

  2. I feel similarly about CS 101.

    When I was an undergrad, a semester of CS was required, and there were 3 options – CS 5 (intro programming), CS 6 (intro programming for people with a bit of background), and CS 60 (the first “real” course in the major; intro to computer science, a sophomore course generally taken by a dozen or two freshmen with an AP CS background or similar). I did CS 6, which was a very well-taught version of a very traditional intro programming course that did not make me for a moment consider majoring in CS, even though I did very well. (Why, hello, clubhouse.)

    Now there’s still 3 options, but they are –

    * the CS 5 equivalent – an intro programming course for people with little/no background, focusing on real-world problems and teamwork (a section is cotaught with the biology department, and of course with today’s toolchain they can build awesome stuff in a semester that we couldn’t back in the day – also, it’s Python, not C++)

    * the CS 6 equivalent – an intro to computer science, not programming, for people with some programming experience, but not enough for CS 60

    * and CS 60.

    So today, I’d have been in an intro to computer science class…which I think would have played much more to my interests. Also, of course, I’d be in a department which has spent years systematically unlocking clubhouses. I really wonder how that would have turned out.

Leave a Reply

Your email address will not be published. Required fields are marked *