Seibel Peter. Coders at Work

Подождите немного. Документ загружается.

Bernie Cosell

545

thought he was going to be. Last I heard, he was doing wonderfully. With

him it worked out. Other people didn’t like working with me because they

found me too overbearing; I can’t imagine why.

Seibel: Did you have particular rules for how much or how little to

comment?

Cosell: I don’t put a lot of comments in my code because I think you

should be writing your code so that it is readable and your algorithms and

thoughts are clear in the code. I put comments that say this routine is

supposed to do this, and usually some description of how you call it—what

do you do when you get exceptions, what the order of the arguments is,

and things like that. But the code itself should clearly express what you are

doing.

The only place I tend to put comments in my code is when my instinct says,

“This particular piece of code, even though it works, doesn’t clearly state

what I’m trying to accomplish.” And so I put a comment in the code to say,

“This code sorts the table,” if it may not look like your standard table-

sorting code because, as it turns out, I can take advantage of something.

I have never been a fan of structured programming listings where every

subroutine has to have 18 lines of comment at the beginning and the

arguments are in the right order. I don’t do a consistent segmentation of my

programs. Some of my subroutines are complicated and some are simple. I

do worry about things like layout; I’m part of the contingent that argues

about curly braces.

One of the reasons is because I read code to understand what it does as

opposed to reading code to see what each little piece of it is. So when I see

if statement, for example, I see the condition. I’m now thinking yea or

nay on that condition, and if I want to skip the

if statement I like having a

program organization that lets my eye flip down to the end of the

statement without me having to process a lot of syntax. So I’m one of those

old-fashioned guys that likes lined-up, open and close braces.

If you made column five go away, my code would look like, “operator, open

brace, close brace; operator, open brace, close brace,” which lets me see

the sequence of operators. Another part of that is related to something I

Bernie Cosell

546

mentioned before: if the open brace is too far from the close brace then

often it’s doing too much, in which case I can pull it out. Sometimes even if

it’s not doing too much I’ll still pull it out because I can’t apprehend what

that little branch is doing if there’s too much crap in there.

I try very hard to hide the crap, to move the crap someplace so that I can

follow the flow of the code, so I can build the picture in my head of what

the code is doing. I have a lot of trouble reading some programming styles

because I have too much trouble trying to absorb the block structure. It’s

interesting that the guy that did Python was clearly of a similar mind. He

eliminated the syntax wars because he doesn’t have open and close braces.

When you see an

if the open curly brace is always there implicitly and the

closed curly brace is also implicitly there and if you need to find the next

thing, it’s lined up under the

if. I use an editor in C and in Perl, and I

assume that editors in Python do the same thing, where you can click on a

button and it shrinks the whole thing so you only see the outer structure.

I don’t like to fight these style wars on the basis that one style is ugly. I like

to believe I fight the style wars is because it interferes with me

understanding the code. I was always pretty good at that. Unless you could

convince me you’re better at understanding code than I am, you have a

tough fight convincing me your way is better.

Seibel: Certainly coming in cold to new code and debugging it is a

particular skill that not every good programmer has, which it sounds like

you did.

Cosell: Indeed. And there are two aspects of that. There was another guy.

His name was Steve Butterfield. And he was also a good fixer, but the

antithesis of me. Steve was about the best I have seen at not having any clue

how a program worked and fixing it. He could dive into a program and

change some little ugly piece down in the bowels of the code to make it do

something different. Big, complicated programs, Steve could leap in and fix

little things leaving them, to my view, functionally better but worse off.

I always tried to make the whole program better and that would often mean

that even though there was one little problem, I would try to understand

the whole program. I would try to find the problem by reasoning down

from the top and finding it as opposed to saying, “Oh, this isn’t working. Do

Bernie Cosell

547

surgery here.” So there were some things where I just took too long and

spent too much time trying to import the whole thing into my head, when a

more directed approach just to go fix it would do.

But usually when Steve left a project, it was hard to revise the code to make

it do stuff. Whereas I tried to keep things good, but it meant that if a

program was really big and awful, I would spend a lot of time spinning my

wheels before I felt comfortable diving in. But that didn’t happen very often

because often when I debug things, I don’t do it by debugging.

As I mentioned before, there were many bugs that I never had any clue

where they were. I just get to a point where I say, “This piece of code is

supposed to be doing this. This does not look like it’s doing that. I mean,

how could anybody have written this complicated bit of code to do this

simple thing?” So I’d rip it out and replace it with a routine that does the

simple thing I thought that piece of code was supposed to do. And the

program magically works. In retrospect, what had happened is that the

program had evolved and this little routine kept getting changed. Rather

than being replaced when the program evolved, somebody was patching it

to do different things and missed once.

I never debugged any of that stuff. I hack on it for a day or two doing all of

this typing and nobody would have a clue of what I’m doing and the program

would get fixed. What a debugger! That is very dangerous because Will’s

dictum is basically right, that if you rewrite a hundred lines of code, you may

well have fixed the one bug and introduced six new ones. And at least the

one bug you, knew what to look for; you now have to start looking for the

six new ones. And I was just fortunate because I had a very good track

record over the years of managing to write code that, for the most part,

worked.

Seibel: So you must have had some strategies for reading code. Even if

there’s no bug but just a big pile of code that you’re going to work on, how

did you tackle that?

Cosell: Not very well, it turns out. One of the reasons why I tend to

rewrite chunks of code rather than fix them is because I reach points where

I can’t manage to figure it out anymore. I don’t read the code as if it were a

Bernie Cosell

548

book. I try to figure out what the program is doing and then get hints about

the code from the top down.

In parallel with reading the program I think about how would I solve this

problem. Which means I’m looking for certain specific pieces so I can say,

“Oh, here’s where the program does it.” Then I can say, in my usual

arrogant way, that the guy that wrote this did it wrong. Or at least I now

understand that they’re doing this some other way.

So I would go top-down. But some of the guys I knew were spectacularly

good at bottom-up. They would start reading little subroutines and

eventually find the one subroutine they needed. But mostly for those kinds

of things I was a top-down kind of guy. That is, I’m looking at the program

trying to figure out what the other programmers should have done. That

was one of the things that led me to sometimes fix bugs where I didn’t

know what the bug was. I’d hit a place where I say, “This piece of code—as I

understand this program now—is supposed to be doing this” and then

either the code I’m looking at doesn’t do that or the code is so complicated

and seems to be doing six other things and it’s not making sense to me.

In either case my usual response at that point is to fix that piece of code so

that it agrees with what I thought was supposed to be happening there in

the program. You can see how fabulously dangerous that can be because

there is no one correct way to organize a program and if the program was

perfectly well organized but in a different way than I wanted, I have now just

killed the program and now have an incredible avalanche of stuff to fix. But I

was pretty lucky with that. Usually when I said, “This looks wrong and I’m

going to fix it” it got fixed. And that was even true from the early days.

The first big program I worked on, the PDP-1 time-sharing system, I was

just a raw programmer doing college-undergrad programming problems and

I moved through the hospital project very quickly, from doing applications

to coming under the wing of the systems guys. Even though I was six

months into being a professional programmer I was perfectly willing to say

that this little piece of the remote process swapper doesn’t look like it’s

right and I would rewrite it.

Seibel: In addition to the danger of introducing new bugs, another risk is

that you may have misapprehended what the program is supposed to do.

Bernie Cosell

549

Cosell: That’s right. The path I took was, if you will, not for the faint at

heart. At the time I was 19 years old and that seemed like the only way to

do things. I had two convictions, which actually served me well: that

programs ought to make sense and there are very, very few inherently hard

problems. Anything that looks really hard or tricky is probably more the

product of the programmer not fully understanding what they needed to do

and pounding it with a hammer ’til they got code that looked like it did the

right thing.

I don’t know why I had those two convictions. I arrived at BBN with no skill

per se, but I had those principles in the back of my head for some reason. I

thought I ought to be able to understand anything and it shouldn’t be so

hard. I found that even for the time-sharing system and the IMPs—for all of

those class of programs, that proved to be true. In general once I had the

right understanding of what a program was supposed to do, the pieces

would fall into place. The pieces that didn’t belong would stand out like a

miscolored piece in a jigsaw puzzle.

Another principle was I always wanted clean listings. I wanted the thing to

be just right. When you have to fix a bug in a program you never, ever fix

the bug in the place where you find it. My rule is, “If you knew then what

you know now about the fact that this piece of code is broken, how would

you have organized this piece of the routine?” What were you thinking

about wrong before? Fix the code so that can’t happen. When you finish

with a routine I want every routine you work on to look as if it was just

written. I do not want to see any evidence of afterthoughts or things gone

wrong followed by something to correct the error or a mysterious piece of

code saying, “This routine returns the wrong value every now and then so

I’ve got to fix it.” I don’t want to see any of that. I want to see code that

looks like through some divine inspiration you got it exactly right the first

time.

Then I compound that with one other little trick. I got this when I was

working on D.O.D. projects. They’ll never fund a new project. Both BBN

and the government have too much invested in the current program, even

when it has limitations that are awful that need to be fixed. The most

common one is something that you did that was right when the program

started is now hopelessly wrong because the program’s use or

requirements or something have evolved. What you’d like to do is rip out

Bernie Cosell

550

that part of the program and just fix it. And they say, “What is that going to

improve?” You say, “It’s not going to improve anything but it’ll make the

program better for next week.” Not going to get permission to do that.

The method I took is the sneaky way and this has worked very well for me

for a lot of programs. I do a design of the future version of the program.

Knowing what I know now, this is how the program would have looked,

now at the program level rather than at a subroutine level. Now when you

go to fix a bug and you have a choice on how to fix it, fix it moving toward

the better model. Don’t just fix it in the shortest way. Don’t just fix it in the

way that fits, but move it toward the other model so that over several

months instead of the program getting more and more mired in patches

fixing up the stuff that was old and wrong, all the critical parts of the

program all of a sudden look like they’re the new way of doing things. Often

you can get to the point where there are so few places left that still do

things the old way that you can slip in and get those fixed because you’re

now not damaging the whole program.

So when they ask, “How long is it going to take you to put this change in?”

you have three answers. The first is the absolute shortest way, changing the

one line of code. The second answer is how long it would be using my

simple rule of rewriting the subroutine as if you were not going to make

that mistake. Then the third answer is how long if you fix that bug if you

were actually writing this subroutine in the better version of the program.

So you make your estimate someplace between those last two and then

every time you get assigned a task you have a little bit of extra time available

to make the program better. I think that that makes an incredible difference.

It makes for programs that evolve cleanly. It’s amazing to have a program

that’s still in version one but it’s like Washington’s hammer. It’s now a really

sleek new thing because all the key parts have gotten fixed without any

project manager having to actually authorize you to go rip out the guts and

go fix it.

Seibel: Have you heard of refactoring?

Cosell: No, what is that?

Seibel: What you just described. I think now there’s perhaps a bit more

acceptance, even among the project managers of this idea.

Bernie Cosell

551

Cosell: Oh, that’s good because I used to need a bug that—I used to need

a reason to change the piece of the code to do what you just said because I

could never get permission just to rewrite it to make it cleaner. So I would

have to wait till a bug or an improvement request came along touching that

part of code, but then I would do exactly that. I guess the thing about

refactoring is that you have spend some time thinking about what the right

target is because it won’t do to refactor and have different people aiming in

different directions or to have the target not be the right thing.

I never did that with a name; it just seemed like the only way I could do two

things: manage the complexity and get a program that you didn’t have to

throw out and code over. The PDP-1 taught me that. It ran for a lot of

years and it was such a huge project. It took three or four guys to write the

first two versions of it and there was no way to throw it out, but it had to

get better.

Seibel: How do you hire programmers? How do you recognize the

talented ones?

Cosell: I couldn’t ever get into the standard interviewing paradigm. People

talk about—and I think Microsoft was famous for this—giving them little

problems to solve. I seem to have taken a more intuitive approach. I

basically glanced at the guy’s—or girl’s—résumé to get a feel for whether

they felt like my type of person. Often the résumés were useless because

they were just college seniors about to graduate. You read between the

lines that this fancy-looking project was really a class project for some

course in something or other. But I used to talk to them and just get a feel

whether they had somehow the kind of inquiring, curious, precise kind of

mind that I had grown to expect people around me to have.

What were their other interests, their nonprofessional interests? Did they

show both aptitude for picking things up, and curiosity? It was kind of

slapdash how I did all of that. I had this idealized image of a BBN-quality

person, some vague thing about aptitude, curiosity, quickness of learning,

interested in lots of different things, and kind of broadly based. I used to go

on a hunt to see if I got the impression that this person was going to be

BBN-quality folk.

Bernie Cosell

552

Seibel: As you mentioned, Microsoft is famous for asking puzzle-type

questions. And you like puzzles. What do you think of that as a way of

gauging someone’s potential?

Cosell: Carefully chosen, I think it has potential. Not because the person

solves the puzzle, but if it gives you a glimmer as to how they organize

something to approach it. I have never used it. I would certainly not have

handed somebody one of the little tchotchke puzzles and watched them

while they tried to put it back together again. The problem is that a lot of

these puzzles require different styles of solution, and either you know that

or you don’t. That’s not so good because I don’t want somebody who’s

really good at doing a sliding-block puzzle because they happen to know

some good tricks for doing that.

BBN spent a lot of its time sailing in unknown waters, doing things that

hadn’t been done, that we didn’t know how to do. And that requires both a

degree of daring, because it’s not so easy, and a degree of skill in order to

not founder. That’s the kind of thing I’m looking for, not looking for

somebody with a knack for solving a particular puzzle but, thrown into this

complicated thing that they have a need to deal with, can they approach it

reasonably?

A case in point was when the Rubik’s Cubes arrived. We had just heard

rumors about this wonderful puzzle and one of the guys was on a business

trip to England and brought back a satchel of them. No books, no

documentation, not yet a phenomenon in the U.S. at all. Just a strange little

group theoretic puzzle. And we started to play with it. Several of us solved

the puzzle in different ways, but it was interesting that we were able to cope

with a puzzle like that. It’s just that that group of BBN people back then had

the right stuff. That was what I used to look for.

I don’t know whether Microsoft’s little quizzes—and I’ve heard that Google

has an aptitude test too, or something—I don’t know if those can give you a

hint that this person has the right spark. But that’s what I used to look for.

Does this person look like they’re ready to be BBN-quality folk? Often I

would say no. They’re perfectly good, they’re terrific engineers, but as we’re

talking I’m not getting that spark. My approach was to look for the spark,

and I don’t know how I did it.

Bernie Cosell

553

Seibel: Do you think programming is a young person’s game?

Cosell: I think that may be the case. I can even see, as I look back at some

of the projects I worked on toward the end of my career at BBN, that the

people I had doing the work for me were doing things that I couldn’t

possibly have done. One of the guys working for me thought that using Tcl

would be a neat thing for part of the interface, so in a day and a half he

learned enough Tcl to bring the thing up and make it work, which I don’t

think I could’ve done. It was amusing for me to think in the back of my head,

“Gee, I used to be able to do things like that.”

I think that the actual production of code—of working, logical, good code—

requires an intensity and a mental agility in terms of picking up new things

that I, at least, find hard to do now. The other side of the coin is that you

get a certain wisdom about things that you certainly didn’t have when you

were younger. I know better now how to do things. So I find a better mix is

to be able to give young and active people guidance. I think that by and large

the sort of programming that I’ve been talking about is similar to the old

saw about mathematics, that most mathematicians do most of their best

work well before they’re 30. The kind of intensity, the kind of focus that

you need to do really cutting-edge mathematics is probably similar to what

you need to do the kind of crazy programming I used to do back when I was

young.

Seibel: One part of the intensity is that it’s simply physically draining to

work long hours. Are long hours necessary or are they just a side effect of

the fact that we love it?

Cosell: I think that’s a personality side effect. The question of whether you

can put something down and come back to it or whether you are compelled

to stick with it and finish it is more of a personality thing. There were

certainly many people I knew of at BBN out in the brilliant end of the

spectrum who were perfectly able to work normal hours and not be

interested in coming in on weekends. Then, of course, there were the other

people who were at the lunatic fringe—for a while I was sleeping in the

computer room because it took me too long to drive back to my

apartment. I would just take a nap in the computer room and I have no idea

how crazy people thought I was for doing that. But I don’t think that is

Bernie Cosell

554

necessary; I think it’s a byproduct of the fact that doing the kind of thing

that we do is pretty exciting, especially when it starts to come together.

One of the really good guys at BBN ended up working a perfectly normal

schedule and finished his PhD dissertation just by being astoundingly

disciplined. He worked every Saturday on his thesis and he worked evenings

on this and that. Part of it, I guess, is being organized. It is much easier to do

something if you can do it all the way through, at which point you don’t

have to think about being organized or careful or putting it down and

picking it back up, because when you’re done you can forget about it. I’ve

been learning that recently since my life is more normal now. I program

around the cracks, putting things down and picking things back up. I find that

if I don’t work on it again for two to three weeks it’s surprisingly hard to

pick it back up. Often when I am lagging on some little personal

programming thing and I really want to get it done, I try to say, “OK, I’m

going to be like the people who exercise. I’m going to do it a couple hours

every morning.” That mostly doesn’t work for me. What happens is at some

point I get bored with having it not be done and I’ll spend a day or two on it

and get it done.

I can, in bursts, get the kind of focus I used to have, but not so well

anymore. So I think that makes this kind of special, fancy programming—

what the true hackers do—more of a young person’s game. I have to admit

almost all of the people I know who did stellar things when they were young

did it intensely. It’s hard for me to think of any folks in the really stellar

category who did it just a couple hours a day as if it were a job. Almost

everyone I know would do it with this burst of maniacal focus and intensity

and then get it done. But the focus is hard. It really wears you out. It

certainly used to wear me out.

Seibel: Would you consider yourself a scientist, an engineer, an artist, a

craftsman, or something else?

Cosell: A blend of those, obviously. I don’t consider myself a scientist, as I

understand what scientists do. I’d like to believe I consider myself a

combination of an artist and a craftsman. The way I do engineering is as a

combination of art and craft.