Seibel: Leaving aside the amount of time you get to spend on it, doesn’t programming require a certain intensity and focus? People talk about flow and how if you get interrupted every 15 minutes, you never get anything done because it takes that long to even start getting the stuff in your brain sorted out.
Ingalls: That reminds me of something I said to somebody way back at PARC. I was starting to have some other responsibilities besides just hacking Smalltalk, but we were also making a lot of progress in making it a really productive system. I kidded that I was racing to improve the Smalltalk environment so that I could continue to get reasonable work done in increasingly short amounts of time. So I’d gotten to where in 15 minutes I could sit down and actually do something useful.
The other part of it is that you work with other people. I work with younger people and it’s great—maybe I spend a bit more time thinking at the level of goals and politics and arranging to make things happen, and they’re making up for what I lack in available time for that deep, deep dive.
Seibel: You have a reputation of being a great guy to work for, when you’re leading a project. How do you lead a team that makes people productive and happy?
Ingalls: I love what I do. And it’s fun to share with other people. These activities can go arbitrarily deep or wide, so it’s easy to find things for various people to work on. I’ve just always enjoyed doing that with other people. There have been times when it’s worked better or not—there are very different phases to this kind of work. There are times when you see everything that needs to be done and it’s just a matter of getting people to do it. And there are other times when you don’t really know what needs to be done and you’re trying to find out. Those are really different phases.
Seibel: Do you have any tips on how to be a good technical leader?
Ingalls: The first thing is being clear about what you’re trying to do. The job is to get a clear vision. If you’ve been around, you can see actually how you’re going to implement that, so you can start to see how that would work out in terms of what various people can do and how it would all fit together.
There have been times when I’ve been working on a project where I could see everything. It felt really powerful because whenever anybody was stuck I could tell them immediately what the next step was, or how to get around it. And people feel that, too, if you know where you’re headed. They can immediately sense it’s all there—he’s got it. And that’s empowering for the team as well.
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 print statement? 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?