To be fair, we all have to start somewhere when we learn how to program, but many teachers of programming are only familiar with programming in the small, how to solve tiny problems.

I once read Donald Knuth talking about computer science.  To him, computer science was not about programming, per se, it was about thinking algorithmically.  But he’s wrong, or at least, partly so.  We can solve some algorithms isolated from everything else, but really, people usually program much large problems.  We’re not interested in quicksort by itself.  We’re interested in solving a problem which has a tiny component requiring sorting.

The hardest part of developing software, other than solving the problem at hand, is deciding what should be solved and evaluating whether the solution, given time and other constraints, makes sense or not.

In principle, this is what software engineering purports to teach.  While I realize that teaching software engineering to students who don’t know how to program is analogous to talking about plot and character development before someone understands the grammar of a language, it’s still important enough to consider.

Here’s an exercise for you to try.  Ask yourself what you think a good software engineer needs to learn.  Then, pretend you are chair of a department with a good deal of power.  Decide which courses students should take, and which courses will cover the content needed for them to succeed.  Compare that with your current curriculum and see how well it aligns.

Software development is a work in progress, and as such, teachers of programming need to understand where the state of the industry is, and decide whether what we teach can be better aligned to what the industry needs.

Since computer science uses the word “science”, it makes some sense to follow what’s been done in other sciences. In particular, many sciences have labs. The reason is simple. How many people have chemicals in their dorms? Or frogs? Or a voltmeter? This equipment is not only expensive, but some of it is downright dangerous. It makes sense to keep this equipment in a lab, and let students use it with supervision.

This is the model some universities took to teach computer science. At one point, this made some sense too. Computers were, at one point, very expensive, costing 2000 dollars or more. The earliest Macs were nearly 2500 dollars. And this was in 1984! This was a significant investment by parents, even if they were savvy enough to realize that having a computer might help students move ahead. Some PCs were above 3000 dollars or more.

Universities bore the brunt of this cost for many years, and it didn’t become really affordable until about 1995, when thousand dollar computers became more commonplace. While a thousand dollars is still pricey, realize 15 years had passed, and people were that much more wealthy, and so this represented a smaller chunk of change than it did in 1980.

Still, universities often lag, not looking at the world outside their ivory towers, and keeping to the same standards that they have kept for years and years and years. Do labs even make sense? Many universities now assign projects outside of class, expecting students to devote 10-20 hours (or more!) a week to their programming assignments. These are times far in excees of a typical 3 hour lab, but the experience gained from this is invaluable.

I have no numbers, but I believe the initial steps of learning how to program have a steep learning curve. It requires, even among the best programmers, some time to make mistakes, work through debugging, and so forth, to get proficient. Much like riding a bike, you don’t usually get it right away.

To get to the point, I want to say that the lab was created at some universities for computer science majors because they used a tried-and-true principle. Copy what seems to work. Labs seemed to make sense in the early days of computer science, but make a lot less sense now, because most students own their own computers. It’s sad that such an investment needs to be made to be successful as a computer science major, but these days, that’s what it takes.

But, there’s another more profound issue. How do we teach computer science majors how to program? Many computer science professors were not truly programmers. They were mathematicians. They believe the pinnacle of computer science is solving hard problems, typically involving math. Anything that appears to require brute force coding is seen as mere engineering, meant for grunt workers.

Of course, most of this was a defensive reaction, in an effort to avoid learning how to program. The problem is that these people are also the same folks that are teaching our kids to program. Perhaps no other major has those who teach so unwilling to learn what they are teaching. Fortunately, this is changing. As new professors come in, they have been trained to deal with the frustrations of programming. And yes, programming in frustrating.

Now, teachers are supposed to be teaching, thus sharing some of the student’s pains. They decide that some aspects of programming are indeed far too painful, for too menial, so they use their superior skills at programming, and hide details from the students. Students therefore don’t install compilers, they don’t deal with bad documentation, they don’t have to upgrade their software, and so forth.

All of this is perfectly fair. If you introduce all these challenges too early on, students will lack the skills to succeed, when they think someone else, someone smarter, will take care of these difficulties for them. Computer science is strange that way. The average computer science major must pick up a lot of stuff about computers on their own, everything from what is a USB port, what is Ethernet, what is HTML, what is CSS, to some basics of installing software. These are things that are not taught in computer science because they are deemed to be unimportant, and more critically, to be transient. The difficulties of today may not help you solve the difficulties of tomorrow. When HDMI replaces component, when USB replaces RS-232 or serial cables, all this technology simply becomes obsolete mere years after they were first introduced. Can you even get a laptop that will let you hook up to your phone line anymore?

But all of this is hidden from students. Why? For one, maybe the people teaching it lack this knowledge. For another, it helps the weaker students get by. Yet, is it enough for them to make a living? Ask yourself when you teach what does a programmer need to be successful?

In the end, the answer is not a specific skill like programming in Java, but the willingness and ability to learn despite poor resources to do so.

These days, I can point to the following skills that students should have, but probably don’t.

• Debugging using a debugger (and how to do so)
• Version control, and how it works
• Related to that, branching/merging
• How to profile both time and memory
• How to learn to use a new piece of software or a library
• How to design a solution and weigh pros and cons of that solution
• How to use a bug tracking system. How to report a bug.
• How to test.

Most of this is rarely taught. If a student is lucky, it’s covered in a decent software engineering program.

Ask yourself, what does a computer science major need. The list may be longer than you think.

I believe academic programming languages need built in profiling, both memory and runtime performance.  I know, I know.  If students can’t get their heads around basic programming, then why bother with these topics?

Still, in the real world, you need these features, and yet, they are not designed from the beginning.  If they were, I think you’d find a lot of cool things about your program, in very practical ways.  I know languages like Java like to hide how much memory is used, but to be fair, so does C++.  Indeed, finding how much memory objects use is hardly a straight-forward task.  If such monitoring were easily available, say, in a debug mode, you’d be able to point this out to students.

I also believe that languages need to separate out printing and debugging messages.  Java does this, somewhat, by letting System.out.println be for standard printing and System.err.println be for error printing.  Of course, most people say you should use logging, which, for my money, still needs to be greatly simplified, at least, when you look at the log4j model.

I suppose, if polled, you’d find most people wanting to teach some functional language or some such, to allow for greater semantics, but always near and dear to a pragmatic programmer’s heart is how fast things run, and how much memory it consumes.

Because I learned emacs, I never really learned vi. I know enough to quit out of vi, and that’s it. I knew a friend who started in vi, and was quite proficient. He forced himself to learn emacs, though, and while he liked emacs and could appreciate its power, there were things he could still do faster in vi than emacs. Each editor had its strength.

vi, in case you don’t know, is the default UNIX editor. In the past few years, it’s been replaced by the more powerful vim.

vi/vim are modal editors, meaning sometimes you are entering commands, and sometimes you are entering text. emacs, on the other hand, is not-modal. It uses control characters to maneuver around the keyboard, where vi uses the letter h, j, k, l (when it is not in text mode) instead of cursor arrows.

Now, this takes the new user a long time to learn, and initially, they can’t stand it. It’s too much work. But if you learn patience, you can eventually learn it. For example, I wanted to learn (once upon a time), how to use Windows shortcuts. I didn’t know how to cut and paste in Windows, thinking it should use the emacs model.

But I forced myself to learn, to work hard at it, so it became second nature.

It’s this kind of unintuitive learning that we do all the time in the computer field. It’s like a Westerner learning to use chopsticks. It requires a great deal of patience, but eventually, you get adept at it.

There’s really two aspects of learning an editor. First, especially for editors with steep learning curves like vi/vim, you need to get to the point where you don’t think about the editing actions explicitly. That itself can be hard. Second, you need to learn the various features. Many students live with a tiny subset of what is actually possible. If they would devote a bit more time, they would become proficient at it.

I suggest the way to teach this is through some kind of “game”. Perhaps you give various levels to proficiency, like they do in martial arts. Of course, this may only appeal to those that like competition, but still, it’s more focused than forcing people to learn for its own sake (even if a game is more or less just that, except it appeals to people’s competitive drive).

Although I’m talking about an editor, I could be talking about any program that students use when coding.  It takes time to learn and become proficient, and even more to become an expert.  So many choose not to become an expert because of how much work they perceive it takes.

Once you know you’re willing to do this work, you’ll find it easier to learn.

But I would have to imagine that education blogs are about the education business, with topics like vouchers, educating in poor neighborhoods, and so forth, being common topics.  The actual act of educating is not discussed much, which is rather amazing.  The closest analogy I can think of this is a newsgrou, which I recall was devoted to fitness and bodybuilding.  However, most of the discussion centered on performance enhancing drugs, which, while relevant, seemed to miss the central point.

Similar, pedagogy seems to be a topic that’s rarely discussed.  Articles dance around the act of educating, and focus on the infrastructure of education.

I wonder how hard it would be to simply blog about education and educating.

Many books teach programming by teaching syntax and control flow. After all, programmers do need to learn this.

However, it’s not everything. As time passes, I think we’ll learn to see programming like writing, even if some of us would like to believe that programming is like mathematics, just cranking away at a problem until we have an answer.

Programming is far more creative than that. I’d liken it to architecture. A reasonable problem for an architect is to design a building with some constraints. Beyond that, there’s a great deal of room for creativity.

But really, I should liken it to writing a story. A good story makes decisions about character, plot, but even down to word choice, allusion, and so forth. Many decisions are made to keep the reader engaged.

The criteria in programming is different. There, maintainability, extensibility, ease of testing, ease of reading, are all factors that affect coding. The folks who are into refactoring say that code has bad smells. This community is perhaps the first to make it a point to explain that coding is more than simply getting something to work, but getting it to work right.

I was reading a book about the history of astronomy. In particular, it was once believed that the Earth was the center of the universe, and everything revolved around it. This made us feel important. Yet, there were planets, in particular Mars, that would appear to move backwards then forwards. Some astronomers, unwilling to give up that planets had circular orbits, imagined these planets travelled in circles upon circles. It was complex, but it allowed circles, considered perfect, to still exist.

While others began to hypothesize that the sun was at the center, then to speculate that the planets traversed in ellipses, not circles, some clung to elaborately complex solutions.

Both notions exist in programming. On the one hand, people have elegant and ornate code that is perhaps too complex for the problem at hand, while others are far simpler, far easier to follow.

Both camps in astronomy had a view of the universe. One sought perfections in circles and an Earth-centered universe, even if it meant making circles upon circles, which were hideously complex, while the other sought the simplest explanation that fit the facts.

Programmers sometimes lack these worldviews. They’re concerned with getting stuff to work, and don’t think about how good or bad their code is.

As teachers of programming, we need to discuss quality of code more. I read code and sometimes feel that it’s not the right way to code it up, even if it behaves correctly. I don’t mean silly stuff like whether we should use camel case or not, or whether we should use parallel braces or not. I’m talking about how to pick public methods, and whether to use interfaces or not.

For example, because of Java, I’ve become a huge fan of interfaces. I use them everywhere, even in C++, because I think they buy you flexibility. Over time, I’ve discovered they also buy you decoupling of code. Code now depends on interface, rather than the implementation. This comes at a cost, though I believe it acceptable. The cost is the method must be looked up at runtime. This is called dynamic dispatch (although, frankly, I’d rather call it runtime method lookup). This is slower than knowing the method call at compile time.

In Java, this is not so problematic as you have no choice but to use runtime method lookup. In C++, you can avoid this if the method is not virtual.

In any case, as one develops as a programmer, one builds taste in what is good and what is not, and this is something we need to start worrying about. But it can be quite difficult, because unlike writers and English majors, we’re not trained to evaluate code, whereas English classes always discuss writing. Even if it’s subjective, it’s not completely random. You build up experience deciding what is good and bad, and while there is no consensus, people can often judge one writing relative to another.

In programming, two criteria exist. One is speed. This used to be of overriding concern for those who loved C. All sorts of tricks were done to improve speed, at the expense of pretty much everything else. The other is maintainability, extensibility, readability. I tend to fall in the second camp.

This issue is more complex than I have time to explain because I should show a few examples. But hopefully, it’ll give you something to think about.

This teacher thought he was teaching at this level, so he assigned a binary search tree as a project.  Part of the problem was that he didn’t seem to consult anyone about what level to teach this class.  As traditionally taught, this senior level data structures course covered advanced data structures such as B trees, but also spatial data structures (meant to store coordinates, lines, etc. in 2D and 3D).  There are other complex structures, such as Fibonacci heaps, and even data structures so complex that algortihms researchers generally talk about the data structure, rather than implement it.

There’s some level to go up, if you want to get really complex.

The teacher’s mistake, one of not consulting those who taught the course, was a problem. It’s certainly possible, given the unique nature of this course, that he didn’t know about these other data structures, and either was embarassed over the fact, or, even as a Ph.D. unwilling to learn the nuances of the data structures and implement it.  After all, it’s so much easier to teach something you already know, even if it’s been a while since you’ve seen it, than to teach something you have to learn.

More than likely, if you’re teaching for the first time, you’ve been given a book and a syllabus from the course taught before.  You can look at exams to get a sense of the level of difficulty, then decide how difficult the course should be.

Difficulty can be measured in different ways.  For example, you can make the course “easy”, at least conceptually, but be a hard grader.  You can make the course intellectually challenging, but make the grading easy (or hard).  You can make the programming aspects lengthy, requiring thousands of lines of code, or shorter, but requiring some advanced knowledge.

All of this can be put under the umbrella of “who should you teach to”?  The best students in the class?  The average student?  (Rarely, does a teacher say they will teach so even the worst students will understand).  Perhaps take a two-tiered approach?  That is, teach some things everyone should learn, but a few things only the best should learn?

Some people prefer to teach to the very smart.  It has one huge benefit.  It takes less work.   One could argue that it’s the mark of a good teacher to make a poor student learn.  However, many teachers don’t aspire to be that good.  It takes too much work.  Imagine you’re presenting the best explanation you can possibly think of.  And still someone says “I don’t get it”.   That has to be deflating, as you feel you’ve done your best, and still, it’s not simple enough.

Teaching to the smart has another benefit.  They’re the ones most likely to use that information well.  Even so, it can be hard to teach well, even to smart people.  You can cover a complex topic in some abstruse way.  Sure, the best students will work hard to learn it, but it doesn’t mean you’ve done a good job.

In the US, you can get various kitchen tools, such as can openers, peelers, ice cream scoops, and so forth, by a company named Oxo.  Oxo makes grips that are largish, round, and rubbery.  These tools were originally aimed at those with arthritis who wanted bigger handles.  However, even those who were perfectly fine liked these oversized handles.  Without the non-elderly, non-arthritic majority, Oxo would not have been as successful as they have been.

Similarly, if you teach well even to the average student, it can benefit the best student to.

My suggestion is to teach both to the average and to the best student.  Doing so may be difficult.  Some people have no idea how to teach to a really good student, not being really an expert.  Some have no idea what average means.

Indeed, that’s my last point to make for this entry.  What is average and excellent depends very much where you are.   Teaching to the average at one university may be just fine, yet too advanced for another, and far too simple for another.  You have to learn to adjust your teaching to your audience, which means you need to know your audience.

Thus, I leave you with this thought.  Figure out your audience.  Figure out who you want to teach to.

I haven’t programmed in Pascal in quite a while, so you’ll have to forgive me if my recollection is a bit rusty. Pascal is a procedural language. There was no notion of objects with Pascal. In that sense, it resembled C.

Pascal had a few features that C didn’t have and vice versa. For example, in Pascal, there are two ways to pass a value to a function. Either you pass by value (a copy of the value is made) or you pass by reference (essentially, a pointer to the value is sent). Passing by reference in Pascal is similar to C++.

C exposes pointers everywhere. You can take the address of practically anything in C. In Pascal, you can only use “new” (or whatever the equivalent was in Pascal) to create dynamically allocated structures. You couldn’t take the address of anything.

Pascal allowed for functions nested inside other functions. If function Inside was nested inside of function Outside, then Inside has access to Outside’s parameters. Only Outside could make calls to the nested functions. They were not accessible by functions outside of Outside.

Pascal makes a distinction between a procedure and a function. In C, a procedure would be called a void function, i.e., a function that does not return a value. A function returns a value.

In C, for a function to return a value, you use the return statement, and return the value back with it. In Pascal, there’s a special variable named after the function, having the return type of the function. You assign this special variable to the return value. Unlike C, where the code of the function is complete once the return statement is run, Pascal runs the code until the end of the function block, even if you have already assigned the function variable.

To illustrate, suppose you have a function foo. This function is supposed to return an integer value. At some point, you’d be expected to assign the variable foo inside the function to an integer. In principle, you could assign it several times. Whatever value the variable has when the function block is complete, that’s the return value of the function.

Pascal was designed by Niklaus Wirth to be a teaching language, not meant to be used in the “real world”.  Perhaps its chief deficiency is the lack of separate compilation (though later versions may have fixed that).  This meant everything had to be in one file.  I suppose it may have had a limited library (thus stabilizing the language).

In fact, the key feature of a teaching language is one that doesn’t change because industry demands this feature or that.

But let me not delve too deeply into Pascal.  What I want to get at is what we think programming is.

When I was teaching programming, we spent a good deal of time talking about control flow, arrays, variables, functions, and pointers (we taught C).  Notice one topic I didn’t cover deeply, and the one that might be of greatest controversy is algorithms.

Why didn’t we cover (much) algorithms?  I was teaching at a public university in a major that was non-selective.  Anyone could be a computer science major.  And, unlike engineers, these majors require far less math to graduate.  We required two semesters of calculus (or was it three?), a semester of stats, and a semester of linear algebra.  Even so, all you need is a grade of C to pass, and that isn’t a particularly high standard (to be fair, there are excellent programmers that are awful at math).

Algorithms require some mathematical maturity to properly understand them.   Many Ph.Ds have been so good at math for so long that they can sometimes scarcely believe that some folks are bad at it, or that those that are bad at it would even contemplate majoring in computer science.   Yet, many students can become good programmers without math (I personally believe you can’t be great without some knowledge of math, however).

Some intro teachers focus on problem solving and algorithms rather than features of the language, believing that this transcends specific details of programming languages.  In other words, you simply have to think algorithmically, not in any particular language (though resembling Pascal, perhaps).  The niggling details of this language or that is merely a distraction, preventing you from solving a problem.

This is why many a professor has stopped programming for real.   Those details are a pain.  And why bother commiting them to memory.  The proof for the undecidability of the halting problem is so much more elegant than the mundane overloading of the term static in C/C++, which can mean “having file scope”, “having static storage”, “being a class variable”, depending on where this keyword is applied, or remembering that a compare operator doesn’t always return -1, 0, 1 (instead returning negative, zero, and positive).  After all, there are no syntax errors in proofs.  You can write in stylized Math English, and have a great deal of latitude in the proof.

Still, these represent the two competing (possibly among many) ideas in teaching programming.  In the one camp, which is the majority, teachers say syntax is irrelevant.  The details of the syntax can be looked up, so look them up when needed.  On the other, syntax is very important, because how many people are really going to look things up (not many, in my experience), but then syntax is often the first thing students forget.

Let’s compare this to English writing.  Many a English teacher are grammar sticklers.  There is a right way to write.  There is a wrong way.  Bad grammar is seen as an offense to man and God.   However, more recently, some have advocated getting students to get their ideas across coherently, regardless of grammar.  Getting students to write is more important than the niggling details of the language.

There is something to be said about this approach.  Grammar is difficult to master.  I recall a professor, who wanted to become chair of the EE department, who complained about foreign students and their lack of good English.  He felt foreign students needed to be good at English (even as many native speakers are bad at it).  I would guess that he had no good idea how to teach good English, nor how hard it is to master.  I’d have more respect (but only barely), if he’d attempt to learn the grammar of another language (preferably Asian), and see just how challenging it is.  Naturally, this person assumed that someone else (the student) would take care of this problem.  If they had truly cared for foreign students to get good at grammar, they might have either hired someone to help out, or simply make acceptance into the program based on grammar.

The point is that English teachers used to stress the importance of grammar, but computer programming teachers somehow dislike this aspect of programming.  And I think, as onerous as syntax is, it insulates students from real world programming.

The question of this essay is to ask what is programming, because once we have a semblance of answer to this question, we can then ask, how do we best teach programming?  How do newcomers to programming fail to understand the ideas of programming?  How is one beginner different from another?

In hindsight, when I was teaching programming, I stressed syntax.  Occasionally, I discussed problem solving, but honestly, not that much.   That was a mistake.  I needed to strike a balance between the two.   Indeed, even if a student never learns how to program “properly”, learning to solve problems in an algorithmic way is still of value.

How common is this task?

For a class of computer science/programming teachers, the tasks he had to do may have been beyond belief.  I know of professors who would simply yell at the tech staff.  Professors don’t need to fill their brains with useless arcana of Linux.  Get the d**n thing to work.

But what my friend went through is starting to become typical.  Computer science types need to know how real systems work (and more often than that, how they don’t work).

What’s my point?

How much should we insulate students from this kind of mess?  Computer science teachers like to present a pristine programming world where every worry is confined to a clean language that is unchanging and sensible.  For example, the student doesn’t worry about installing a compiler.  They don’t worry about the operating system.  They just think about loops and functions and objects.

I recall, as a kid, watching a science television show, called 3-2-1 Contact.  It was on PBS.  Its goal was to teach young viewers a love of science.  Of course, it lacked one key ingredient.  Math.  Yup.  The thing that most scientists must know well is math, and yet, these shows basically show the glamor of science, without any of the difficulties.

Of course, students that lack talent in math are weeded out pretty quickly, and so it’s not as if we waste students’ time by giving a candy coated vision of science.

We do try to present this vision of programming however.  I’ve read that the Computer Science AP folks, who write college placement exams for high school students across the United States, want to make a core Java, that is insulated from the changes in Java, so students won’t be scared away by a language that is still evolving.

I don’t know exactly what I feel about this.  On the one hand, I think it’s a shame that the computing industry evolves as quickly as it does, and that it takes an incredible amount of work to make things simple, whereas it takes almost no work to make things complex, and that most software developers have to deal with complexity.

At universities it’s common to have specialization.  Professors learn advanced math and some advanced programming, but ignore the evolution of Linux, clinging to the permanence of the knowledge they have, while deriding the fleeting fad of the real world.  If a computer doesn’t work, the sys admin takes care of it.  Specialization.

Maybe the software industry will become extremely specialized, with people isolating other people from differing levels of expertise.

For example, it takes a certain skill set to simply write code, but takes another to optimize.  Most programmers would say optimization is simply the next level up, that a good coder eventually needs to know how to optimize, otherwise they aren’t so good.  (By optimization, I mean make the code run faster, or make the code use less memory as it runs).

Would this skill ever be specialized enough that someone would come in and do that work?  Certainly, there are people specialized in, say, internationalization, and focus on getting applications to work in different character sets, while insulating others from having to know anything about this.

I know this is an old topic, but I believe we tend to focus on intro courses where we inspire students to the world of programming, but the same people that do that are often loathe to discuss the messy stuff, partly (perhaps mostly) because they don’t know how to teach the messy stuff.

I can’t say I know how to teach it either.  It’s the messy stuff that drives students away (heck, even debugging drives students away).   Programming takes a good deal of patience.

It was once thought that two semesters were all that’s required to master the basics of programming.  CS1 would cover the basics of the language: if statements, loops, functions, structures.  CS2 would cover basic data structures: linked lists, stacks, queues, binary search trees.

Although this was a perfectly good way to teach programming when the language was Pascal, it’s increasingly obvious that it’s not enough for any object-oriented programming language.  Indeed, I’d argue that we need four semesters of programming, rather than two.  Object oriented programming is that tough.
This is just another indication of CS faculty not properly paying attention to what they’re teaching.  Of course, there was a pragmatic reason to keep to two semesters instead of four.  That’s two additional courses that don’t need staffing.  And believe me, staffing is a big issue.

There’s many an academic professor who don’t want to teach introductory courses.  Too many students sign up for programming that don’t really have a head for programming, and the teachers often lack the patience when students don’t understand basic concepts like array indexing.  When professors want students to use continuations and lambda expressions, the thought that simple loops can confound a student is scary.

So imagine the horror if they had to teach not just one, not just two, but four courses.

Of course, you’re now waiting with bated breath, wondering what four courses I think are important to teach.   It’s not terribly surprising.  First course is OO programming one.  This covers basics objects, loops, functions, etc.  Basically, object-based programming.  Not so much inheritance.  Second course is OO programming two.  This would include inheritance.  It would also discuss some basic design patterns.  Course three would be data structures, and some basic software engineering.  Course four would be design and software engineering.

When I taught at Maryland, we had three courses.  First course was C.  Second course was C++.  Third course was C++.  Even with three courses, the drop/fail rate was pretty high.  Since then, they’ve changed the curriculum to two courses in Java, and a third course in C.  The C course was set up to teach systems level programming (low-level programming).  My four courses admittedly misses that.

I found it interesting that Maryland would teach three semesters of introductory programming taking fifteen weeks per semester (or 45 weeks total), while the University of Washington, on a quarter system, would take two quarters (or about 20 weeks total) to cover traditional CS 1 and CS 2.  Maryland spent more than twice as long to cover intro programming.

How did UW manage to avoid awful programmers in their system?  Simple.  They have a selective major that removes more than half the eligible computer science majors.  When you’re willing to teach 200, but only want 70-80 majors, those who survive the cut are likely to be good, no matter what you did in the first courses.  It would be seriously scary if 140 students were allowed through, as it is in Maryland.

Imagine if every major did that.  Many students would simply not graduate.  Of course, computer science professors (and companies recruiting top students/programmers) love this because it means you don’t have people struggling with the basics of the language when you want to address math or some higher level concepts in operating systems.

Ultimately, where we’re failing students is our ability to give appropriate feedback, and large universities are worse than small ones.  English departments, for example, value feedback so much that they force small sizes when they teach.  At one point, I had to teach a course where each grader had to grade nearly 100 students.  Clearly, they had no time to look at their projects to see if it was any good.  They had to check the basics, and move on.  Our resources were that limited, and the department did not see it as a travesty.  English professors and graduate students would have been up in arms.   We were not.

We need to adopt a model that’s closer to what the English department (and similar majors) do when it comes to teaching coding.  It’s amazing that good coders develop, even in a system that doesn’t necessarily evaluate good vs. bad coding.

One reason I decided to be a software developer was to see coding in a real environment, and see how development was done (at least, someplace).  It’s been an eye-opener, especially during code reviews, and it’s something that computer science departments need to adopt.