Peter Seibel - Coders at Work - Reflections on the craft of programming

Seibel:Does having too clear a picture of what you want ever disempower people—since you’ve got everything in your head, there’s nothing fun for them to do?

Ingalls:Well, you can leave it open how they do their part of it and you maybe only step in with micromanagement where it’s needed. And often things turn out better. I was lucky to work with a great crew of people for a long time whom I trusted. Trust is part of it, trust for the people that you’re working with. The other thing is just confidence. When the picture’s clear, it’s easy to be confident about it. I think the kind of thing that makes for bad micromanagement is you’re worried and you’re insecure, and so you’re feeling like you have to nail everything down.

Seibel:Have you ever had a really great team leader when you were a worker bee?

Ingalls:The best boss in my life has been Alan Kay. I worked under him at Xerox for some very formative years, and that was an interesting combination, because he knew what he wanted but he hardly ever said how I should do things. But he was technically savvy about all of it so he was a good critic. I and the guys who came to work with me were really productive so I think he felt enough progress that he didn’t have to interfere much. He made an umbrella for me, for us, and he really had a picture of what he wanted to do.

Seibel:When folks are working in a group, is it better for coders to each own a piece of a system? Where “This is my code and no one touches it” vs. the team owns the code and anybody can touch anything.

Ingalls:I don’t know. The way we work now on the Lively Kernel project is different people have different areas they work on, but there aren’t any fences. It’s more a matter of expertise, or focus, or goals. I’m trying to think of these periods that seemed really successful, how that worked. I’ve never worked in big teams, so it’s generally been that people pretty much worked solely on a piece of code.

Seibel:Another topic, debugging: what’s the worst bug you’ve ever had to track down?

Ingalls:It was a garbage-collection bug. Garbage collection is the worst thing because the manifestation of the problem is long after the cause has come and gone. Being able to track down an obscure bug like that makes me think of breaking codes. My father was in the Office of Strategic Services, and they worked in teams, and a lot of what they did was just gathering information, just trying to be up on things. Then a code would come in with a fragment of something they had seen in a newspaper and they would put it together that way.

It was the same thing with being able to track this down. What I brought to it was just having all this intuition of what can cause what to happen in these situations. This particular one, I was in it deep down for at least a day. When I finally got it done, I was elated, and my son, who was, I think, four at the time, made me a “Determined Debugger Award.”

Seibel:This was in Smalltalk, I assume. Did you have a symbolic debugger that you could use, or were you looking at hex dumps of memory?

Ingalls:This was lower level than the nice Smalltalk debugger. I really can’t tell you the details of this one, but the kind of thing is you get an error somewhere, which would actually take you to the low-level debuggers. So you’re looking at memory like a bunch of octal locations. Then you find things like one object pointing into another object in the way it shouldn’t. So you’re trying to think of, “How could that happen?” You have all these little clues and little patterns of this can cause that, this can cause that, and so then you try to figure them out.

Seibel:So that was at a very low level. When you’re developing in the nice Smalltalk environment, I assume you use symbolic debuggers. Do you ever resort to print statements?

Ingalls:I don’t know of anybody who does that if they have the choice of using a good debugger. Because where do you put the printstatement? You put it there . Well, wouldn’t you just like to be there, looking at everything, instead of just printing it? Now I do a fair amount of print statement–style debugging because it’s often the case I don’t have a good enough JavaScript debugger.

Seibel:What made the Smalltalk debugger so nice?

Ingalls:Well, you could stop anywhere in the program and you could actually look at all the bindings of all the variables. You could execute fragments, evaluate expressions right in the middle of the context.

Seibel:At any particular point in the stack frame?

Ingalls:Yep, and you could make significant changes and then proceed. And you could get to an error, have it on the screen, save the entire state of the system, ship it to somebody else who was on a Windows machine and not a Mac, and they could fire up that same image, be where you were, make a fix, and proceed. So just complete preservation of state across different machine representations.

Seibel:Invariants are another sort of debugging tool. Some people are very big on formal preconditions, and postconditions on all their methods and class invariants, and some people are more ad hoc about how they think about things. How do you think about them?

Ingalls:I’d probably go in the less formal camp. Mainly out of that original feeling of having things be as absolutely simple as possible. I feel the same kinds of things about types. Types are essentially assertions about a program. And I think it’s valuable to have things be as absolutely simple as possible, including not even saying what the types are. I think as you get more serious about a system, it’s nice to be able to add all that stuff, and there are ways of having your cake and eating it, too, such as inferring the types and not having to see them except when you want to see them.

And types are only one thing in a spectrum that includes units and all sorts of other assertions you can put on there. That’s part of the fascinating area we have to explore with this synthetic mathematics. I think increasingly we can take areas of computation and document them more and more with living documentation, real programming documentation, so there are assertions there that really help you that you don’t usually see, but if you’re stuck, you can start to bring them in and test various things about it.

Seibel:Do you have an opinion one way or the other on formally proving programs correct?

Ingalls:It’s never been an occupation of mine. I’m inclined to focus on the architectural part that makes it easier to make assertions about things. So if you are allowed to do all sorts of dangerous things in a program, then when you sit down to do the formal proof, it’s very hard because at every step you’ve got to say, “Well, this could happen, that could happen, that could happen.” If the architecture is clean, then the formal proof may almost be obvious just by reading the code. You’ll say, “Well, this could only come from there. We’re safe.”

Seibel:Have you ever used C++?

Ingalls:No. Nor C.

Seibel:But you did BCPL and assembly, so it’s not like you’ve never used low-level languages.

Ingalls:Right. And I actually have done some C to debug things generated by Squeak. But I remember when we did Squeak, part of my purpose was to have a system that you really could be master of without having to know anything but Squeak. So I made it my purpose to not ever learn that. John Maloney did the translator from Squeak to C in order to give us a practical implementation. The truth is, I would go in and look at that C code but I pretty much made sure that you didn’t need to do any of that.