The Great Programming Debate

Over the last few years, I've noticed a pattern that keeps repeating in Internet forums and blogs:

1. Someone asserts that programming is or should be for everybody, usually misrepresenting it as a glamorous and easy job full of benefits and no drawbacks, like this.
2. Someone else posts an emphatic counterpoint, like this.
3. A third person tries to point out that a certain degree of "programming literacy" should be required and goes on to point out that everyone knows (or should know) how to read and write, like this.
4. The discussion devolves into polite bickering, because at this point most people are usually past their threshold for completely unbiased discussion and are invested in their own point of view.

I happen to have my own point of view, but it usually gets lost in the noise, since I invariably try to contribute it in a discussion during step 4. Looking back, I can see I've weighed in on both sides of the debate and I think it might be interesting to try to share a more balanced view and, perhaps, bring the people from the two extremes a bit closer.

Why Programming Should Be For Everybody

As I pointed out recently, in a similar discussion, I got into computers when I was 7 years old. Back then, "getting into computers", at least in my country, meant getting something like ZX Spectrum or Commodore and either playing games or learning how to code. Games were in English and a lot uglier than their arcade counterparts, so it should come as no surprise that most kids who had computers went on to learn how to make them "do tricks". That's the real allure of programming for a kid: you're typing in seemingly incomprehensible stuff and the machine does something. It's magic!

Not everyone had a computer, mainly because we were living in Communist Yugoslavia and it was not easy to import one, but nobody told us that computers are "not for everyone" and that only trained professionals can program. It was a slightly weird hobby to have, but it grew into some of the best years of my life: I grew up believing that the world would be transformed and that I would be part of it. Some days I felt like a combination of a wizard, secret agent and super-hero; other times I felt like a rebel straight out of Mentor's Hacker Manifesto.

At no point did I feel like a kid who's playing at being adult and should leave it to professionals.

You might think I'm attacking a straw man here, but this sort of elitism seems to be increasingly more prominent in discussions nowadays:

Sorry, but those things are technology and should be worked on by technologists because there's literally no on else who can work on them

That choice quote came from a discussion on Hacker News and it's the kind of extreme point of view that provokes people to react with very emphatic counterpoints.

Why Programming Isn't For Everybody

The problem with emphatic counterpoints is that they tend to go to the opposite, equally unhealthy extreme. If you've watched "What Most Schools Don't Teach", then you know that the intentions and goals behind the video are laudable. You probably also noticed that programming has been grossly misrepresented.

If you didn't know better, if you were the stereotypical impressionable youth, you might have walked away from that video believing that programming is easy if you know addition, subtraction and multiplication tables and that working as a programmer is a lot of fun, where you get free gourmet food, play video games and jam with a band inside an awesome office. You might also get an impression that you would be programming flying robots, self-driving cars and medical equipment.

As much as I agree that programming should be taught in schools -- and I'll get back to that later -- the fact is that programming is not easy and good programming is damn hard. To make things harder, good programming is a lot more important today, precisely because computers are so widespread. Bad code does have the power to ruin lives. I'm not talking about medical equipment or space shuttle systems here: a bad credit report won't kill you, but it might ruin your life for years; a badly programmed system might incorrectly match you as a terrorist.

When conveying a positive message in service of a good cause, you must take care not to go to extremes. Nobody tells kids that being a doctor is as easy as putting on a stethoscope and learning which side of the body holds the heart and which the liver. By simultaneously downplaying the difficulties of programming too much and painting a glamorous picture of it, you're setting kids up for disappointment:

We’ve all been raised on television to believe that one day we’d all be millionaires, and movie gods, and rock stars. But we won’t. And we’re slowly learning that fact. And we’re very, very pissed off.

-- Chuck Palahniuk, "Fight Club"

Incidentally, you're also bruising the egos of everyone who has worked their ass off for more than ten years trying to get closer to being a master programmer. While that's the most forgivable mistake, it still merits being mentioned, because you're alienating the very people you need the most.

Shades of Grey

In the end, it all boils down to recognizing that things aren't black and white. Putting the programming on a pedestal, unreachable by all but a select few, is as wrong as representing it as a glamorous job where anyone can be a rock star if they only try.

I agree that all schools should teach a certain level of programming, just as they teach literacy and a certain level of mathematics. In our society, computers are everywhere and everyone should be brought up to understand them and be reasonably proficient at manipulating them.

On the other hand, even though everyone is taught reading and writing, not everyone ends up being a writer. Even those who do are not necessarily successful. Likewise:

• Knowing basic biology does not make you a doctor.
• Learning how to play an instrument well enough to play it professionally requires constant practice and even then you might never get to be famous and hugely successful.
• Getting into NBA requires more than being able to run the length of the basketball court.
• Being able to prepare scrambled eggs or even come up with a recipe or two of your own doesn't make you Jamie Oliver.

Are these analogies exaggerated? Yes, but so are some messages we offer about programming. Let's face it, not everyone will have the aptitude to take make programming more than a hobby.

The important thing is that people of all ages need to be free to try it and we need to welcome them. However, it's equally important to make sure it's okay for them to fail. Our industry needs all the good hands it can get, but it's hard enough as it is without adding tons of bad, unhappy programmers who were promised the world and tricked into believing they could get it by wishing upon a star.

Uneducational Crisis Pt. 3: Approach

Most of the things I wrote in the previous two posts can be disputed with counter-examples: not every professor is a Prima Donna; not all things they teach you at the university are irrelevant; there are great places where smart and likable people teach you good stuff; everything else is just "bad luck" and you "have to take the good with the bad". Let me tell you what I think about that:

I don't buy it.

There's a big problem with education as a system in general, not just in the CS field. And that problem involves the relevance of what we learn, from kindergarten to university. How many things did you learn in the ground school that you have completely forgotten? Let's face it, as a society we are doing a shoddy work of teaching our kids.

Why is education so bad? There is probably a variety of factors that enter the whole equation, but I think there are only two of major importance. One of them is the fact that teaching is not the number one motivation behind the existence of schools. Paul Graham has put it succinctly in his essay "Why Nerds are Unpopular":

Teenagers now are useless, except as cheap labor in industries like fast food, which evolved to exploit precisely this fact. In almost any other kind of work, they'd be a net loss. But they're also too young to be left unsupervised. Someone has to watch over them, and the most efficient way to do this is to collect them together in one place. Then a few adults can watch all of them.

The other major factor is that the basic approach to teaching is wrong. And that's what I want to explain here, so let's delve into it.

What Do You Want to Be When You Grow Up?

Whenever someone asks me how I came to be so obsessed with computers and programming, I tell them to blame my dad. No, he didn't teach me how to code, nor did he teach me anything important about the computers beyond turning them on and off and washing my hands before touching the keyboard. In fact, he can't code to save his life, which is perfectly fine, because he's a writer. What he did do, though, is much more important: he introduced me to computers.

How did he know I would like computers? That's the whole point: he didn't. When I was 5 or 6 years old -- I don't remember clearly anymore -- he started showing me the basics of photography. I found it entertaining, but I didn't take it too seriously. Then he tried with cinematography and the results were more or less the same. But then he showed me a computer and since that first look I am completely and totally fascinated with computers and the programs they run.

Why am I telling you this? Because I think I was extremely lucky. From that moment on, I knew what I wanted to be when I grow up; I had an interest that didn't pass and fade and I always had a new goal to achieve and a new way to improve myself.

I do know a few other people who have a passion in their life. I also know many more who never discovered anything they really like and lead largely disoriented lives. It sounds harsh, but it's true: having a spouse and kids cannot replace the feeling of having your own dreams. You can share your dreams with your family and complement one with the other, but in the end they are not interchangeable.

Nosce Te Ipsum

Here's the interesting part: I think everyone can and should have the chance to discover what they like. That's one of the most important things in our personal development and we usually don't have much help with it.

That's why most of the stuff they teach us at school is useless and irrelevant. How do you know something is relevant? You don't. You have to discover it. It's not something you can be taught, it's something you have to find out yourself. But that doesn't mean you shouldn't have help.

Educational institutions are ostensibly there to impart knowledge we will need in order to be useful and productive members of the society. But we don't know where and how we fit into that society. And the society doesn't know it either, so they just try to pour all sorts of stuff on our developing minds, hoping that after a while we'll get an idea where to head and how to specialize.

Optimism is good, but that's not optimistic: it's plain ridiculous. Imagine you had to pick what kind of food you want for your wedding party and the way to choose is to first learn by heart the recipes for a whole lot of different dishes and then use that to decide.

Yes, you will have an idea what each dish tastes like and yes, you might even make a dish or two to check out the taste. You might even get lucky and choose well. But if you made a mistake, there's no turning back: your wedding party will have food you don't like and that's it. You might get married again later and have another wedding party, but this one is gone for good. And the food sucked.

Of course, in real life you can get help from dedicated experts who specialize in that sort of stuff.
Imagine if you could get help with discovering your own talents and interests. Imagine if you could get that kind of help from people who specialize in it. Wouldn't life be a whole lot nicer?

Rat Races

Instead of that, what do we have now? We have to assimilate a considerable quantity of knowledge in a fixed time period, at the end of which our performance is rated and, if it is found satisfactory we can proceed to the next period and the next batch of knowledge.

There's a name you can slap on that description: competition. Our educational paradigm is based on competition and that makes it not merely misguided, but downright harmful. Instead of helping to find what our kids can do well, we force them to become "good enough" at doing a bit of everything. Worse, after passing through our educational maze, the kids are still not really good at doing anything of real worth.

Consider the most notable effect of our educational model: cheating. I really like how Wikipedia hit the nail on the head in their article:

A common venue for cheating is in education settings, where it takes a number of forms.

Of course it does. If you're competing for something that could bring you a gain you can clearly perceive, you might be tempted to cheat. But if you're forced to compete at something that you don't even perceive as lucrative (and nobody else really believes it either), you won't be tempted to cheat, you will consider it a natural option.

I'm not against the competition in education. Competition can be good, because it fosters a drive towards self-improvement. But you have to want to compete. And that happens either when you're competing at something you like or for something you perceive as lucrative.

Silver Bullet?

Of course, the solution is certainly a lot harder to implement than to propose. And I didn't even propose a complete solution, I just gave an idea. And I'm probably not the first to have it or even to voice it. And it certainly wouldn't solve all the problems and cure all the diseases and stop all the wars.

But don't you think it would be nice to try it?

Uneducational Crisis Pt. 2: Subject Matter

When I think about these last four years, I don't usually think about the university. Much more important and interesting things have been happening in my life. I think that says something about the quality of education as a life experience: you only consider it important when you're forced to do it during the better part of your day.

But when I do think about the university, the first thing that comes to mind are the professors. I've had a few excellent professors who were a pleasure to study with, but the rest ranged from merely disinterested to downright inept. In my previous post, I covered this topic in detail.

The second thing that comes to mind is what I learned. Or rather, what I was supposed to learn. Now that the things are drawing to their unceremonious end, it's amazing to look back and see just how many things I've been told were

• misleading
• wrong
• obsolete
• stupid
• some or all of the above

With a lot of real-life experience in software industry, you can afford to be told such things because your brain will reject them automatically after a brief examination. But the reason I started writing about the educational problems in CS is not because I feel cheated out of my money, but because of the kids who go to the university to try to learn.

You see, I love programming and I like doing it for a living. And I enjoy the company of other people who do it. Sure, school might not matter if you're good enough (and infatuated enough). The knowledge is out there and you can learn it all by yourself. But you might not find it soon enough and you might get the wrong ideas at school and you might come out of it all utterly confused or frustrated or suffer some other damage. There's enough stuff in real life that will confuse and frustrate you, no need to start out like that.

So what's wrong with the stuff they teach you at the university?

Obsolescence

I agree that learning about the past is important. You need some context if you want to understand not only the how, but also the why of the things you see today. But that's no excuse for teaching obsolete stuff.

Take waterfall model, for example. For a big enough project, as most of real-world projects are, it simply does not work -- there are too many things that can go wrong and will go wrong. And yet the universities insist on teaching it as the way to execute software development projects.

Another good example is the insistence on Design Flow Diagrams. I'm not implying that DFDs are obsolete. Nor am I saying the same about any other concept from SSADM. Had any of our professors bothered to teach us SSADM well, I might have learned enough to compare it to what I'm used to working with.

As far as DFDs go, I find them stunningly imprecise and uncomfortable, compared to UML. This, of course, is a topic for a discussion that goes beyond the scope of this post, but it's also a bit beside the point. The point is that if the course is called Systems Analysis and Design, I don't think it can stay locked in time forever, covering SSADM in depth and merely mentioning the existence of UML and iterative processes and the myriad of other techniques that evolved in the mean time.

Scope

The problem with SSADM vs. UML is just an specific case of a bigger and more general problem: the scope is all wrong. If you are going to give an OOP course, you should take care to explain what OOP is, what OOP isn't, why it's been invented, how it works, etc. Sounds reasonable, but it doesn't happen. What you get instead is a Java course, where in the first few classes you get a very brief, confused and inaccurate summary of OOP concepts and then you delve into the language specifics.

I love learning new languages. As Kevin Kelleher notes, each language tries to solve some problem. That means that each new language you learn might teach you about a new class of problems or a new class of solutions. The thing is, you have to realize what the problems are and why they are problems before you can benefit from learning a new language. Otherwise you're just learning syntax.

You could do it the way I did it: learn a new language, compare it with the one you knew before and gradually become aware of the new problems. After enough time and enough new languages, you'll be able to think of languages in terms of problems and solutions. Indeed, nothing can completely replace the process of learning from your own experience. But that doesn't mean you aren't entitled to decent formal education.

It's like your parents telling you not to play with fire. You might heed their advice and still get burned by something you didn't know was hot. Or you might disregard their advice and get burned. But if they didn't tell you not to play with fire you would surely get burned out of ignorance.

Specialization

The problem of scope is what you'll see on the individual course level. But when you take a step back and examine the entire course curriculum, you'll find yourself facing the opposite extreme: breadth. The sheer breadth of subjects covered combined with the scope of each course makes you wonder why you got yourself into this at all.

Here's a bit of news for the guys who design the educational program: most of the software developers don't need to know about the implementation specifics of the datalink layer in ISDN. Nor do most network experts really need to know how to design a database in the third normal form.

I understand why the universities do this. It's a lot more manageable to have your courses flow sequentially and give everyone who survives the same diploma. Teach them all and let job sort them out. The question is, should ease of management excuse the poor results? Let's put it to a test: what would you think of a manager who told you, before the project started, that you'll have to implement a web-based user interface, a Swing GUI and an interactive textual interface, because it's easier to plan the project that way than to plan for capturing the UI requirements?

Relevance

All of the problems I've described here could be easily summarised in one word: relevance. Obsolete subjects are irrelevant to what you'll be doing. Courses with wrong scope teach you irrelevant things. Lack of specialization ensures you'll be learning a lot of irrelevant stuff. I postulate that every problem with the subject matter in CS education can be filed under relevance.

So how do we solve this? I hate doing this, but I'm afraid I have to do a Robert Jordan and leave you hanging. By now I've built enough context to engage in a discussion that I wanted to start from the beginning, but that discussion merits its own post. Therefore, I have no choice but to say RAFO.

At least I promise to finish in the third post.

Uneducational Crisis Pt. 1: Human Factor

If there's one thing worse than a bad programmer, it's a failed programmer turned professor. I don't know how common this is in United States, but here in Chile you see it a lot. And try as I might to pretend that I don't care, it's actually driving me nuts. Quite understandably, too: I could be doing interesting things instead of trying to guess what the latest in a row of brain-dead dilettantes wants me to write as a solution to his "ingenious" exam exercise.

On the other hand, this way I get the first-hand insight into the problems with education in CS field. Some of these problems, I suppose, are local and owe their existence to a variety of economic, political and technological factors, but I'm convinced that some are universal. Nonetheless, I shall not discriminate: I'll go over them all and a plague on both their houses.

This article, the first in the series, deals with the professors themselves.

Two Roads Diverged in a Yellow Wood...

Over the time, I learned to distinguish two types of CS professors:

1. The Geek. This guy knows his stuff, because he actually works in computer industry and does his job well. Sometimes he is motivated by a genuine desire to teach new generations, but often he is teaching just to make a bit of money on the side or to lend a bit of academic weight to his name. More often than not, he is wonderfully inept at imparting his knowledge to the students, because he's a computer geek, not a teacher. All in all, he's guaranteed to be relaxed, easy-going and flexible. Mostly harmless.
   
2. The Prima Donna. Who needs knowledge when you have Orwellian authority? This is the guy who will typically boast at least 20 years of experience in computer industry, who has a prominent consulting company and is certified by Carnegie Mello [sic] University. His classes are pure poetry. Vogon poetry, to be precise.

The Prima Donna is the type that does the most damage, so he merits detailed dissection.

Spot the Prima Donna

A Prima Donna professor is rather easy to recognize. He will exhibit a combination of several seamlessly coupled behavioral patterns from the following list:

• Smugness. Usually one of the first signs that you're dealing with a Prima Donna is that self-satisfied attitude aimed to make you feel that some day, with lots of effort and a divine intervention or two, you'll get to be as good as this guy.
• Hand Waving. One of the most valuable techniques for explaining the unknown is the hand waving. To those who came to learn, it seems that the Prima Donna is making a herculean effort to explain the concept and that they are simply too dumb to understand him.
• Stating the Obvious. A good presentation slide will show only the key concepts and leave the explanation to the presenter. A bad presentation slide will show all the information in a pile of text you won't bother to read. In both cases, the Prima Donna will repeat the contents of the slide, with lots of Hand Waving, and you'll be left no wiser than before.
  
• Exasperation. Sometimes a braver student will ask the Prima Donna to clarify something previously "explained" by Hand Waving and Stating the Obvious. If the Prima Donna is not in the mood to do it all again, he'll inform the audience that he explained it several times already.
• Selective Hearing. If there's a student willing to press the issue despite the Exasperation, the Prima Donna might choose to answer another student's unrelated query or to simply go on to the next topic.
• Condescension. You never know when you might get lucky: sometimes a Prima Donna will even give away unearned points when correcting an exam. But don't worry, he will make sure to inform you about it.
• Objective Subjectivity. He might be teaching you how to solve problems that have more than one correct solution, but you better make sure you solve the problems the way Prima Donna taught you to do it.
• Asserting the Authority. The Prima Donna will make sure you don't forget that he's the professor and you're the student, which means you owe him certain respect. He'll be especially sensitive about certain forms of disrespect, such as disagreeing with him.
• Showcasing the Merits. In case you don't seem to be convinced of the Prima Donna's authority, you'll be informed of one or more of his certifications, nominations, recognitions, citations, publications, you-get-the-idea-tions.
  

Occasionally, you might get really unlucky and wind up with an embodiment of the archetypal Prima Donna. If there is an option to get the authorities to replace him, go for it.

Damage Done

It's becoming increasingly popular to be a nerd. Sure, you're still going to be bullied in school, but at least now you know you might be in store for a bright future. And those around you know it too. People tend to pay attention to things that might make them rich and when one of the richest persons in the world is downright nerdy, you can bet it won't go unnoticed.

The net result is that you get a lot of CS students who are in it for the glory and riches. These people don't know a lot about computers, but that's okay, because they're there to learn. The problem is that a lot of them also lack the talent. They're simply not good at computer science or any natural science at all.

Imagine all these people trying to learn about pointers from a Geek professor. Confusion abounds, chaos reigns supreme and in the end a lot of them will either fail the course (and hopefully change major) or pass the course having learned nothing.

Now imagine them trying to learn about pointers from a Prima Donna. Apart from becoming utterly frustrated and dejected, they'll learn a lot of garbage. The things that will stick the most are the parts that the Prima Donna invented or misinterpreted, because those are the most vivid explanations the Prima Donna will offer. That's the core of what makes him an "eminence" in the "computing world".

And now imagine yourself working with them on a project. Imagine working on a piece of code that has to traverse a tree with a co-worker who believes that "recursion is for programmers who have no style." Imagine hunting down an interoperability bug caused by bad handling of character encoding in a code written by a person who has been taught that "ASCII table is physically implemented in the microprocessor." Imagine writing business logic that has to use a database designed by someone convinced that a transactional database must satisfy the fifth normal form.

Not a cheerful thought, is it?