Monday, August 2, 2010

we're not teaching programming and we should be: learn how to read code, lots of it.

By Dave Winer on Sunday, August 01, 2010 at 11:57 AM.

A picture named bikewide.gif

I love that David Weinberger is narrating his fumbling programming work on his blog. It's great for a lot of reasons. Permanent link to this item in the archive.

Everyone goes through what he's going through. Permanent link to this item in the archive.

You never stop going through it, even if you've been programming for 37 years, as I have. You'd think after all this time I would remember the basic lessons I learned the hard way when I was in my early 20s. But nope, I often forget them. Permanent link to this item in the archive.

It's very useful for me to read his narrative. I'm going to teach this stuff, and I have to remember that what seems second-nature to me now, once didn't. Permanent link to this item in the archive.

One of the things I talk about with everyone I meet at NYU if they're willing to listen is that we're not teaching programming and we should be. I think every person who graduates with a bachelor's degree should have one semester of programming, just as they should have one semester of journalism.  Permanent link to this item in the archive.

If I ever get my book together, there will be a chapter on programming in it, where we'll cover the basics. Logic, looping, variables. I seriously think we can get political science students to experience a teeny bit of the magic of programming. It'll be a challenge for sure. Permanent link to this item in the archive.

But it's a serious situation because there aren't enough students taking up computer science. New York wants to become a tech center, but it'll never happen as long as there are so few programmers graduating from our universities. Another way of saying this is that every student graduating with a compsci degree is much sought-after. They have their choice of jobs. This, in a major recession. Permanent link to this item in the archive.

A picture named bike.gifNow, my advice for David, and anyone else who is staring at code wondering how it could possibly be behaving as badly as it is.  Permanent link to this item in the archive.

Of course you're going to think it's the system that's screwing up. We all do. But that is so rarely the cause of the problem that it pays to put the theory aside and get the computer to reveal its logic to you. It's coming up with what you think is the wrong answer, but when you finally figure it out, you'll see why it's the right answer. You can't move on until you see this. Permanent link to this item in the archive.

So step through it in the debugger, and watch what it does with your data. Eventually you will see it do something that isn't what you expected. Now figure out why and change the code, and test again. Permanent link to this item in the archive.

I once stared at some code that was supposed to return the value 26 but it was returning 251. Must be a bug in the math processing code, because how could 25 plus 1 yield 251. But it did, ever damned time the code ran. Until I realized that the 1 was a string and the 25 was a number and the language coerced the number to a string so it could concatenate them. What was imperfect was not the machine, but my understanding of the machine.  Permanent link to this item in the archive.

BTW, I can only remember one time that a problem turned out to be a bug in the system. I spent a week chasing a bug in IBM's Pascal compiler in the early IBM PC. Of course there was no way to file a bug report, so once I understood what it was (I had to look into the code it was generating) I just worked around it.  Permanent link to this item in the archive.

A picture named kong.gifAnother time, there was some bad memory in my system. This was in the very early days of PCs, when there was no memory management. So I put a comment around the bad memory in my source, and was very careful not to add any code above it -- in all my source files.  Permanent link to this item in the archive.

Very early in my career as a programmer, I had an office in the Empire State Building, on the 39th Floor, with windows that open. I was there late one night, trying in vain to figure out which of the computers that was running my code had the bug. My problem was I had no idea how to approach the problem. That's 98 percent of the battle, clearing your mind, rolling up your sleeves, accepting the responsibility that it's your bug not some programmer in New Jersey, or the guy who wrote the operating system. I remember thinking, staring out into the NYC night that they shouldn't put young programmers in skyscrapers with windows that open. :-) Permanent link to this item in the archive.

View the forum thread.

Posted via email from

No comments: