Seibel: Leaving aside the amount of time you get to spend on it, doesn’tprogramming require a certain intensity and focus? People talk about flowand how if you get interrupted every 15 minutes, you never get anythingdone because it takes that long to even start getting the stuff in your brainsorted out.

Ingalls: That reminds me of something I said to somebody way back atPARC. I was starting to have some other responsibilities besides justhacking Smalltalk, but we were also making a lot of progress in making it areally productive system. I kidded that I was racing to improve the Smalltalkenvironment so that I could continue to get reasonable work done inincreasingly short amounts of time. So I’d gotten to where in 15 minutes Icould sit down and actually do something useful.

The other part of it is that you work with other people. I work withyounger people and it’s great—maybe I spend a bit more time thinking atthe level of goals and politics and arranging to make things happen, andthey’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, whenyou’re leading a project. How do you lead a team that makes peopleproductive and happy?

Ingalls: I love what I do. And it’s fun to share with other people. Theseactivities can go arbitrarily deep or wide, so it’s easy to find things forvarious people to work on. I’ve just always enjoyed doing that with otherpeople. There have been times when it’s worked better or not—there arevery different phases to this kind of work. There are times when you seeeverything that needs to be done and it’s just a matter of getting people todo it. And there are other times when you don’t really know what needs tobe 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. Thejob is to get a clear vision. If you’ve been around, you can see actually howyou’re going to implement that, so you can start to see how that wouldwork out in terms of what various people can do and how it would all fittogether.

There have been times when I’ve been working on a project where I couldsee everything. It felt really powerful because whenever anybody was stuck Icould tell them immediately what the next step was, or how to get aroundit. And people feel that, too, if you know where you’re headed. They canimmediately sense it’s all there—he’s got it. And that’s empowering for theteam as well.

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

Ingalls: Well, you can leave it open how they do their part of it and youmaybe only step in with micromanagement where it’s needed. And oftenthings turn out better. I was lucky to work with a great crew of people for along time whom I trusted. Trust is part of it, trust for the people that you’reworking 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 badmicromanagement is you’re worried and you’re insecure, and so you’refeeling like you have to nail everything down.

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

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

Seibel: When folks are working in a group, is it better for coders to eachown 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 projectis different people have different areas they work on, but there aren’t anyfences. It’s more a matter of expertise, or focus, or goals. I’m trying to thinkof these periods that seemed really successful, how that worked. I’ve neverworked in big teams, so it’s generally been that people pretty much workedsolely on a piece of code.

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

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

It was the same thing with being able to track this down. What I brought toit was just having all this intuition of what can cause what to happen in thesesituations. 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, fourat the time, made me a “Determined Debugger Award.”

Seibel: This was in Smalltalk, I assume. Did you have a symbolic debuggerthat 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’ttell you the details of this one, but the kind of thing is you get an errorsomewhere, which would actually take you to the low-level debuggers. Soyou’re looking at memory like a bunch of octal locations. Then you findthings 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 theselittle clues and little patterns of this can cause that, this can cause that, andso then you try to figure them out.

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

Ingalls: I don’t know of anybody who does that if they have the choice ofusing 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 ateverything, instead of just printing it? Now I do a fair amount of printstatement–style debugging because it’s often the case I don’t have a goodenough JavaScript debugger.

Seibel: What made the Smalltalk debugger so nice?

Ingalls: Well, you could stop anywhere in the program and you couldactually look at all the bindings of all the variables. You could executefragments, 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. Andyou could get to an error, have it on the screen, save the entire state of thesystem, ship it to somebody else who was on a Windows machine and not aMac, and they could fire up that same image, be where you were, make a fix,and proceed. So just complete preservation of state across differentmachine representations.

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