Seibel: Do you think it’s those little bits of feedback or questions? Or is itjust the fact of explaining it?

Armstrong: I think it is because you are forcing it to move it from the partof your brain that has solved it to the part of your brain that has verbalizedit and they are different parts of the brain. I think it’s because you’re forcingthat to happen. I’ve never done the experiment of just speaking out loud toan empty room.

Seibel: I heard about a computer science department where in the tutor’soffice they had a stuffed animal and the rule was you had to explain yourproblem to the stuffed animal before you could bother the tutor. “OK, Mr.Bear, here’s the thing I’m working on and here’s my approach—aha! Thereit is.”

Armstrong: Really? I must try that.

Seibel: Talk to your cats.

Armstrong: The cats—absolutely! I worked with this guy who was slightlyolder than me and very clever. And every time I’d go into his office and askhim a question, every single question, he would say, “A program is a blackbox. It has inputs and it has outputs. And there is a functional relationshipbetween the inputs and the outputs. What are the inputs to your problem?What are the outputs to your problem? What is the functional relationshipbetween the two?” And then somewhere in this dialog, you would say,“You’re a genius!” And you’d run out of the room and he would shake hishead in amazement—“I wonder what the problem was, he never said.” Sohe’s your bear which you explain the problem to.

Seibel: The doodling—is that writing little snippets of code or is it literallygraphical doodles?

Armstrong: It’s more bubbles with arrows. You know when you explainthings to people on a white board—you draw bubbles and arrows andequations and notations. Not code. Code fragments—piddly bits of codesometimes because that’s a compact way to express something. This is inthe thinking period. Very occasional code experiments because I don’t knowhow long it takes to do something. So I’ll write ten lines of code and timesomething.

Seibel: You mean how long it takes for the computer to do it?

Armstrong: Yeah. Does that take a millisecond or a microsecond—I don’tknow. I can guess but I want to confirm that guess. And so I’m only lookingat the bits I don’t really know. But I have a great stock of experienceprogramming Erlang so I know pretty much what things are going to do.Problem solving was the same years ago. It was, identify the difficult bits,write the small prototypes, identify the areas of uncertainty, writing verysmall bits of code. Essentially I do the same thing now but I have less reasonto do these small experiments. If it’s Erlang. If I’m doing Ruby or Java then Ihave to go back and do a lot of experiments because I don’t know what’sgoing to happen.

Seibel: Then somewhere in this thinking process you get to the pointwhere you know how to write the code?

Armstrong: Yeah, then all the bits fit together. But maybe I can’t explain itto anybody. I just get a very strong feeling that if I start writing the programnow it’ll work. I don’t really know what the solution is. It’s like an egg. Thechicken’s ready to lay the egg. Now I’m ready to lay the egg.

Seibel: And that’s the point at which you need to go into flow and not beinterrupted.

Armstrong: Yes, yes.

Seibel: So there are still presumably a lot of details to be sorted out at thecode level which requires your concentration.

Armstrong: Oh yes. But then there are two types of those things. The stuffthat really needs the concentration is the stuff that is not automatic—you’vegot to think about it. You’ve got this really tricky garbage collection—exactlywhat needs to be marked and exactly where—you’ve got to think hard about that.You know you’ll find a solution because you’ve kind of bounded it in. And youknow it’s in the right little black box.

Michelangelo is doing the roof of the Sistine Chapel or something and he’sgot a whole team of painters helping him. So he would sketch the bigpicture first. These huge areas have got to be done in blue and green. Sothat’s rather like writing a program. The first sketch is this broad sketchwhere everything’s in the right place. Some of these places are going to befilled with uniform color and just can be filled in fairly rapidly—you don’thave to think.

And then you get to the details of the eyes—that’s tricky stuff. You knowyou can do it. And the eye is in the right place because the picture is OK. Soyou go and do the eye and the detail. That’s not to say that’s easy—that’sthe difficult bit, actually. You’ve got to really concentrate while you’re doingthe eye. You don’t have to really concentrate while you’re doing theforehead or the cheeks because they’re fairly uniform. A bit of stubble hereso you pay a sort of half concentration.

Then type it all in and get the syntax errors out and run a few little tests tomake sure it works. And that’s all rather relaxing. See a little compiler errorthere and you fix it. Once you’re experienced at a language you don’t evenbother to read the diagnostic. It just says the line number—you don’t readwhat it says. That line—oh, yeah. That’s wrong, you retype it.

I gave a course in Erlang in Chicago. I was wandering around the class andI’d notice, there’s something wrong. Oh, there’s a comma missing there orthat’ll crash before that happens and you’re not linked. My wife’s very goodat proofreading and she says errors spring out of the page at you. A missingcomma or a spelling mistake—they literally spring out of the page at her.

And programming errors just spring out of the page if I look at otherpeople’s code, wandering around. It doesn’t feel like conscious thought isinvolved—it’s holistic. You see everything on the screen and there’s theerror, bumpf. So it’s just a matter of correcting those surface errors.

One that’s tricky is slight spelling errors in variable names. So I choosevariable names that are very dissimilar, deliberately, so that error won’toccur. If you’ve got a long variable like personName and you’ve gotpersonNames with an “s” on the end, that’s a list of person names, that willbe something that my eye will tend to read what I thought it should havebeen. And so I’d have personName and then listOfPeople. And I do thatdeliberately because I know that my eye will see what I thought I’d written.But punctuation, I do see that—I do see the commas and the brackets asbeing wrong. And of course Emacs colors everything and auto-indents andthe brackets are different colors. So this is really easy.

Seibel: At the point that you start typing code, do you code top-down orbottom-up or middle-out?

Armstrong: Bottom up. I write a little bit and test it, write a little bit andtest it. I’ve gone over to this writing test cases first, now. Unit testing. Justwrite the test cases and then write the code. I feel fairly confident that itworks.

Seibel: Back to a bit of your history, it was after the Swedish SpaceCorporation that you went to Ericsson’s research lab?

Armstrong: Yes. And it was a very, very fortunate time to come, it musthave been ’84. I think I had come to the lab something like two years after ithad started. So we were very optimistic. Our view of the world was, yeswe’ll solve problems and then we’ll push them into projects and we willimprove Ericsson’s productivity. This view of the world wasn’t yet tinged byany contact with reality. So we thought it would be easy to discover newand useful stuff and we thought that once we had discovered new and usefulstuff then the world would welcome us with open arms. What we learnedlater was, it wasn’t all that easy to discover new stuff. And it’s incrediblydifficult to get people to use new and better stuff.