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

Allen:Well, I was sent to management school. Everybody was, back when I was first appointed. But I think it goes back to when I grew up on the farm. I was the oldest of six kids and there were five of us in a row, so my parents were pretty overwhelmed. So it was a natural role for me in some ways.

Seibel:One of the difficulties of the kind of technical management that you were doing is finding the balance between having your own technical opinions about how stuff should be done and giving people room to put their own ideas in.

Allen:I think I had some hard lessons on the Stretch project. I remember some of the people on the project came in and said to me one day that we ought to be using list and hash functions. Well, we knew about list programs but hashing was new. So a couple of my people came and said they wanted to use hashing for the symbol table. And I said, “No, we can’t do that. We don’t know how to do that.” Yadda, yadda, yadda. The next Monday I came in and they had done it. They had torn down the system and rebuilt it with hashing. It worked, and it was much faster. So that was a big lesson to me. I should be much more open to some brand-new ideas.

Seibel:So sometimes—maybe even often—your people actually know what they’re talking about and you shouldn’t interfere too much because you might stomp out a good idea. It’s trickier when you’re really right and their idea really is a little bit flawed but you don’t want to beat up on them too much.

Allen:There was some of that. It was often where somebody came in with a knowledge of some area and wanted to apply that knowledge to an ongoing piece of project without having been embedded in the project long enough to know, and often up against a deadline.

I ran into it big time doing some subcontracting work. I had a group of people that was doing wonderful work building an optimizer based on the work we’ve done here for PL/I, a big, different language. But one of the people working for the subcontractor had just discovered object-oriented programming and decided that he would apply it to the extreme. And I couldn’t stop him, even though I was the contract overseer, and the project was destroyed. Ultimately, what did it was PL/I has lots of pointers and tracing a pointer is done all the time, and it took 11 instructions to trace the value, to find the value of one pointer consistently.

Seibel:You mean in the generated code.

Allen:In the generated code and in the compiler itself because it was bootstrapping the compiler. Every time you made a step you had to check that the thing’s valid. And you were checking, and rechecking, and rechecking. It still happens today. Some of these lessons we haven’t learned well. And I guess I was not dealing with it very well, because I should have just pointed out what the cost of applying object-oriented technology in that kind of situation. It was just hopelessly slow, so the whole thing got canceled.

Seibel:When were you most directly building a product for IBM, with production deadlines that had to be met?

Allen:Certainly, the Stretch project was that way. And I’ve worked in product development two or three times, and been in the situation where one has week-by-week code reviews right up against deadlines. I have a lot of respect for those processes and how important they are for the end result and for the team that’s doing it. It can be very painful to sit there every Friday and do code reads with people explaining why they’re doing what they’re doing and finding other people’s errors.

Seibel:Painful, but worthwhile?

Allen:Absolutely worthwhile. On the PTRAN project, towards the end when we were shipping a piece of it to the products, a half a day was devoted to explaining errors in our code, their code, whatever it was, every week. That went on for ten months, I think. Devoted Friday afternoon to it.

Seibel:When you were working in those settings did you feel like you had a process that let you estimate how long it’s going to take to build X amount of software with any kind of accuracy?

Allen:Well, they did. The product-development people certainly did. It was all tracked, and I’m sure it still is. Part of it would be to statistically get a handle on the quality of the code. How many bugs showed up this week, yeah. I liked the environment of a product lab because it’s sort of where things get real.

Seibel:When you were hiring programmers what did you look for?

Allen:Well, I had a lot of connections in the universities. NYU had some fabulous compiler-writer faculty—that group was really well-trained to write compiler code.

Seibel:So you could hire people recommended by the professors you knew and trusted. How about when you have to interview someone who doesn’t come with a recommendation from someone you trust—how do you figure out in the course of a couple of hours whether they are going to be a good programmer?

Allen:I always start with interviewing anybody for IBM Research by trying to find out what they’re excited about. That’s kind of a basic threshold for me. And it doesn’t matter whether it has anything to do with programming or computers. If they can’t get enthusiastic about something, they’re not going to get charged up in a group.

Sometimes one takes a high risk. I took a high risk on a guy whose thesis adviser wrote that he was very dyslexic. He didn’t work out so well here because he didn’t fit in some ways, but he started his own company and I still go to him for advice, for insights on how to do things technically. He just knows things. So that wasn’t a mistake. It was a mistake in terms of the project, but not in terms of his relationship with a lot of us.

Seibel:Lately you’ve been involved in mentoring—there’s a mentoring award here at IBM that is named for you. Do you have any ideas about how new programmers should be brought along into being better programmers?

Allen:That aspect of mentoring, I don’t get very close to these days. What I do do, though, is encourage a young person starting out to not jump into becoming a manager, which is very tempting for people who have a talent in that direction. Get a reputation for technical work. Whether it’s a nice piece of science, an algorithm, or writing great code—whatever it is, establish a strong reputation there first. That’ll serve you well if you do want to go to managing projects and so forth, to have learned the discipline of what it takes to do that and how to function in that way.

Seibel:Is it possible to have a great manager who’s actually not very technically skilled, but is very good at organizing the efforts of others?

Allen:Yes, as long as he doesn’t think he’s good at the technology, and is able to distinguish between who is and who isn’t in the people that work for him.

Seibel:That’s probably the trickiest thing. For you, what distinguishes the really best programmers?

Allen:Well, I always like to find the people who can turn a light bulb on over my head. That’s really important for me because I spend a lot of time thinking about systems, so I like to have people that will be able, at least in Research, to show me something new and interesting or a new way of looking at something—a new way of solving a problem.

Also, I rely on what other people think. I’ve been wrong plenty and it’s a real learning experience when I find myself thinking more highly of somebody than the group does. If you have a good group, it’s a very good way of sorting out who’s doing good work.