I had a discussion a few days ago with a very good friend of mine about different topics including education. So far I’ve lived in two countries for a considerable time - Hungary and France - and I’m not happy with the education in general in any of those countries. There are simply too many autocratic teachers who don’t even want to teach how to think, they just try to impose their own ways of seeing things. If they make a mistake and some smart students recognize those they attack and punish. Thanks, but no, thanks.
Peter Norvig had a similar experience in high school. His teacher tried to teach how to shuffle a deck of cards - as a programming exercise of course. The teacher proposed a way which might never finish and therefore impractical. Still, she didn’t accept it, she didn’t say, okay let’s see how you’d do it. A nice lesson from life early on.
I liked one other thing he said about schools, I liked it so much, that I felt an urge to tweet it: “When I was in school, working as a team was called cheating.”
Okay, still school is useful, I agree on that with Norvig. But as he says, the curriculum changes slowly. I remember that I started with Pascal at university in 2003. It seemed a bit outdated even for us, freshmen.
Thinking about it, as far as I can remember we had only one team assignment during the five years of university. We had a couple of pair assignments, but only one for a team of four. We should have had much more of them.
A recurring question in the book is about what changed during the last decade in terms of skills needed for coding. Norvig has something interesting to say about it. He says that in the past we needed people who could write everything from scratch. Now we need people who assemble pieces. Successful programmers need to understand interfaces relatively well and relatively quickly. This is more important than understanding all the details in a given package.
As a software craftsman, I really liked what he says about the apprentice approach. Just like in other crafts, we should spend a lot of time watching our masters, to see how they do their craft. This is another use of pair programming. But we can interpret pair programming a bit differently. Imagine that you code and broadcast your screen on the web. Young apprentices could watch you. Maybe they could comment, ask questions. I’m sure there are already people doing that.
He also considers programming as a craft. I really like his analogy. He says that you don’t just write a program to be pretty. You write it because you need its functionality and then you pretty it up a bit. Like a carpenter who “can make a chair, and it’s good-looking, but it’s mostly functional—it’s a chair.”
As he considers programming a craft, his other thought makes sense. Norvig claims that the great researchers are not - necessarily - good coders. Many times those who can hold full systems in their heads will end up producing spaghetti code as they don’t have the urge to clean things in order to understand them. They already do.
Funny to hear about the worst bug he had to track down. It’s the infamous Mars program failure. It’s about using foot-pounds vs. newtons. Communications is very important for coders, just like a quiet workplace. It’s not easy to provide both at the same time and many companies fail at that point.
In Google, they don’t have so disastrous bugs. They don’t have install updates in many environments, they just push it their servers. And many of their services are for free. If you use Gmail you cannot ask your money back in case of a failure.
Regarding books, his recommendations don’t hide a lot of surprises. He recommends to read Knuth, Cormen, Leiserson, and Rivest, Sally Goldman or Abelson and Sussman. Great classics, I should read them too. In fact, these books extend my already long waiting list of books. I encourage you too to build such a list of books. s
