I love that David Weinberger is narrating his fumbling programming work on his blog. It's great for a lot of reasons. 

Everyone goes through what he's going through. 

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. 

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. 

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.  

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. 

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. 

Now, my advice for David, and anyone else who is staring at code wondering how it could possibly be behaving as badly as it is.  

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. 

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. 

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.  

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.  

Another 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.  

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.