Archive for June 6, 2012
Who knows why meme’s start, but one of the big ones in the Computing Education blogosphere today is “Let’s not call it ‘Computer Science’ if we really mean ‘Computer Programming.’” Based on Neil Brown’s excellent response, I suspect that it’s the UK “Computing at Schools” effort that is leading to this question. If you’re going to define a computer science curriculum, you’re going to have to define “computer science.” Both Neil and Alfred Thompson do a great job of helping us define kinds of computing and understand the goals of the different kinds of curricula.
I’m more interested in the assumptions in the original blog about what the “regular people” are going to do. Jason Gorman claims that 99% of people involved in computing are just “users.” ”I believe that what’s needed is a much more rounded computing education for the 99%, with IT blending seemlessly and ubiquitously into everyday lessons as well as home life.” They need computational thinking, but not programming, argues Jason. Jason sees that only 1% of students should get programming. “For the remaining 1%, of whom some might become software developers, we need programming in schools (and out of school). Lots of it. “
That sharp distinction is not how people work today. Chris Scaffidi, Mary Shaw, and Brad Myers explained this in 2007. For every software developer in the world, there are four more professionals who program, but aren’t software developers, and there are another nine other people who are programming, but don’t recognize that.
- A lot of Jason’s 99% are going to write SQL queries. That’s where much of the world’s data lives today, and lots of people need to get to that data. SQL queries require variables, conditionals constraints, an understanding of data abstraction, and oftentimes, a model of iteration. Looks like programming to me.
- A lot of Jason’s 99% are going to create spreadsheets: Same variables, conditionals, models of iteration. Oh, and testing. One of the common themes in all the end-user programming literature is that new programmers don’t realize how many things can go wrong in writing programs, and how much time they’ll waste in debugging if they don’t develop good testing practices. There is a real economic cost to all those end-user programmers losing productive time to bugs. Is testing in the “Computer Science” side or the “Computer Programming” side?
- All scientists and engineers will program: Maybe just in Excel, many in MATLAB or R, and a surprisingly many in both. Greg Wilson just sent me a great paper yesterday about all the ways that scientists and engineers code. They’re not professional software developers. They use programming to achieve their goals.
Jason’s worldview has this giant country of “Computer Users,” and this tiny Lichtenstein of a country called “Computer Programmers” next to it. The problem isn’t that the border between them is thin, porous, and maybe more gray than well-defined. It’s a really fat line, and that’s where most professionals will live. It’s really another whole country, lying in the border, and it swamps the other two.
What people do with computing is changing, and growing. Programming is a medium, a literacy, a form of communication and expression. More and more people will use it. Jason also raises the issue that self-taught programming is just fine. Someone yelled at Alfred in his blog for not recognizing the greater value of self-taught programming. Neil Brown called it right: Emphasizing self-taught programming is another way of shutting women out of computing. I look at the issue from a literacy perspective. Some people can teach themselves to write on their own, but you can’t count on that to achieve literacy in your society. If a literacy is worth knowing, teach it. Computer programming is a literacy, and everyone should be taught it — and computer science, too.
Think of computing as a pyramid. At the base, we have computer users, who will probably make up about 99% of the pyramid. The next level up is people who write software (let’s ignore people who make computers – that’s electronic engineering, which a CS education won’t help you with), and they might account for the next 0.9% of the pyramid. Finally, at the top, are computer scientists – people who advance the concepts, design the programming languages and “push the envelope” for the 0.9% of us who write software day-to-day.
Nice blog piece from Cay Horstmann on the legal judgment in the Google and Oracle case. In the end, what won the day is that the judge knew something about coding! Cay explains why this is a big deal.
Now, here is the other interesting aspect. When you read through the history of copyright lawsuits, you’ll be struck by how clueless the courts can be. Look at those dueling dental programs. Those judges, about as clued in as the senior managers who watch our demos, totally equate user interface with program structure. If two programs have similar screens, surely one must have ripped off the other.
But Alsup cuts right to the chase. Why? Because in a prior life, he wrote some code!!! He knows that rangeCheck isn’t rocket science because he has coded something like it before. He told the Oracle attorney that he should be ashamed at himself, making a mountain out of a molehill, because deep in his guts he knew. Those judges looking at the dental programs didn’t.
Two recent blog posts that are pointing out an interesting need.. First, from “Gas Stations without Pumps,” a discussion about how teaching writing and programming are similar in importance and the difficulty of doing it well.
There is a strong temptation to throw the problem over the fence to a small group of experts (writing instructors or computer science lecturers) teaching first-year classes. That happened in most universities to writing instruction over the past 2 decades, with the result that students write very few papers after their freshman year in most majors, and almost never get detailed feedback on them. It is happening in computer science also, except that the freshman CS courses already do not provide any feedback on programming style other than whether things compile and work on a few test cases. (That’s like checking English papers for word count, word length, and sentence length, but not for content—sort of what scoring of SAT essays is like.)
Next, from a new blog that I just discovered: A post from “Run(),” which talks about how Udacity is helping a long-time programmer become a better programmer. The first post is pointing out how formal education is failing future programmers, because it’s not providing enough to develop real expertise. The second post is agreeing, but pointing out that maybe that’s the role of Udacity. I’m not arguing that Udacity or Coursera is dealing with teaching novices to code well — maybe it’s possible to do that via crowd-sourcing, but I don’t really see them filling that role now. I do see the possibility of Udacity of filling other holes in formal computing education, like seeing multiple languages, which doesn’t happen much now.
It showed to me that there are many people out there programming without truly understanding the essence of programming. I would bet that there are many out there just like Rick, who dabble in programming or are self-taught programmers, who have focused most of their efforts on learning programming languages that they never realized the common logical backbone that is in so many programming languages. It does venture into a somewhat theoretical space, but I think many would stand to benefit from investing some time to understand these abstractions from the get-go. It also makes me think, once again, that you can become a better programmer if you can be exposed to at least more than one programming languages from early on– so that you are not trapped in the workings of a single mental model.