Seibel: With the hot-air balloon on the cover?

Eich: Yeah. That turned me around in a big way. That was big. That was like’80 or so. So I wasn’t really doing a lot of programming then. I was thinkingabout it and I was reading about it and I was playing around on this old ironat undergraduate university. The purity of the Smalltalk environment, thefact that it was so highly bootstrapped—all that really hit me in a way thatmade me want to be involved in programming—languages and virtualmachines. Going into Unix was physical machines and operating systems,and that was where the action was. But even then I was reading—there wasa Springer-Verlag book that had a bunch of papers, and people back thenwere fantasizing about universal object file formats and Java byte-code,essentially, before its time. But yes, Smalltalk was huge. I didn’t actually getto use it until years later at U of I, when they finally released something thatran on the Suns of the time and it was slow.

Seibel: On another topic, how do you recognize programming talent?

Eich: We hired somebody a while ago; he was a friend of one of thesuperbrains we’d hired. But this was a guy who was, I think, just undergrador a bachelor’s degree; I’m not sure if he even finished. He met a guy whowas working for us and they’re both OCaml hackers, and he was doing hisown OCaml hacking on the side. And he was thinking about problems thatwe were seeing in my static analysis. When we interviewed him, I knew hewas young but you couldn’t tell. Some people thought, “Oh, yeah, he hasn’tdone much. You know, we should only hire rock stars; what are we talkingto him for?”

I said, “No, you guys are looking at this wrong. This is like one of our brightinterns. Get them while they’re young. He’s done a bunch by himself, he’sgotten into OCaml; he knows not just the source language, but the runtime,and he’s hacked native methods and he was writing an OCaml operatingsystem, toy operating system. But this guy is good.” And it wasn’t that I gavehim any particular programming test; it was just that I’d listened to him talkabout what he’d done and why he’d done it. He wasn’t just repeatingpabulum about C++ patterns. We have kids like that, unfortunately. Nicepeople and adequate programmers, for what they were doing, JavaEnterprise stuff. But we needed somebody different, and this guy wasdifferent.

So in the interview the main problem was overcoming people misreading hisage or thinking he wasn’t accomplished enough. But we hired him and he’sjust been a superstar. He’s done a bunch of static analysis tooling, originallyon this open-source Berkeley Oink framework, and then on GCC as plugins,working with the GCC guys. Now he’s kicking our mobile effort intohigh gear, just doing poor man’s profiling and printf of timestamps andfinding out where the costs are and whacking them.

So when I interviewed him I knew there was talent. That he camerecommended from somebody bright was good, because you know brightpeople like each other and can judge each other—generally there’s not adysfunctional, “Hire my friend, who’s really not bright.” They want to workwith bright people. Maybe this sounds like I’m cheating, but that’s one way Irecognize talent. And I think that’s why we’re hiring superhackers. I thinkwe’re hiring up all the Valgrind hackers. Some of those guys can do anything;they don’t fuck around.

Seibel: So is that something you often do in interviews: get them to talkabout their own projects?

Eich: I do. I don’t give people puzzles to solve. We have people who dothat here. To the extent that we have to do that and we’re using that tofilter applicants, I worry.

Seibel: Is that even a good first-pass filter?

Eich: I’m skeptical. Google does that in spades, and they hire a bunch ofvery bright puzzle-solvers. But some of them, their street smarts are notnecessarily there, and mature judgment. So I’m skeptical of it. I think wehave to do it to some extent because you can end up getting someone whotalks well, but actually isn’t effective at programming, and so you want tosee them think on their feet, you want to see if they’ve solved a problembefore. So we give them fairly practical problems. Not esoteric puzzles ormath-y things, but more like programming problems.

Check their C++ knowledge, because C++ is hairy. So it’s sort of a sanitycheck, not enough to say, “Let’s hire him.” But if they pass it, that’s good; ifthey don’t, we worry. To say, “Let’s hire them,” we have to see somethingelse, and that’s the spark that involves particulars, like what they’ve doneand their approach and what languages they’ve used.

Maybe I’m also sympathetic to the odd duck. I don’t mind people who are alittle different. I don’t want to hire somebody who’s hard to work with, butwe need talent. We need people who think differently.

When I was an undergrad I was really affected by Pirsig’s Zen and the Art ofMotorcycle Maintenance. And I had been going through Plato and the earlyphilosophers. I was, at that point, inclined more towards idealism in somephilosophical sense. I thought little-endian byte order was superior to bigendian,because after all, the least significant digits are in the lowestaddress—there was some kind of harmony or geometry in that. But tryreading a hex dump. Practical things matter; particulars matter. The famousSchool of Athens painting with Aristotle pointing down and Plato pointingup—I’m more on the pointing-down side now. As I get older I get more andmore skeptical and more and more interested in what works.

When I’m interviewing people, when I’m looking for talent, it’s very hard forme to not stick with particulars and practicalities. OK, so this guy knewOCaml—it meant he was smart, but should we hire him? Well no, but healso did things on his own and he thought on his feet when I talked to him,and he was already thinking about compilation or analysis problems that wewere going to hire him to work on. But maybe the important thing there,the real story, was the network we were going through, the guy we hired,he was his friend.

Seibel: Do you still enjoy programming?

Eich: Yeah. It’s a bit like an addiction; it’s a little problematic. It’s not justthe programming part of getting the code to run; to me now it’s more andmore finding the right idea that has the New Jersey philosophy of a 90/10trade-off—a sweet, sound theoretical core that isn’t going to solve all yourproblems but when you fall on the 10 percent that loses, you don’t go tohell. You can actually win this way and the code stays small enough andsimple enough and there’s some dance between theory and implementation.I like that. That still appeals to me; it still is fun; it keeps me up at nightthinking about it when I should be sleeping.

Seibel: Are there parts of it that you don’t enjoy as much anymore?

Eich: I don’t know. C++. We’re able to use most of its features—there aretoo many of them. It’s probably got a better type system than Java. Butwe’re still screwing around with ’70s debuggers and linkers, and it’s stupid. Idon’t know why we put up with it.

Impatience and hatred of primitive tools drives me to try to be a betterprogrammer. Our code is riddled with assertions now and they are fatal.That’s important to us. But this is something that has helped me, especiallywhen I’m doing one of these allegedly sound, 90/10, sweet trade-off moveson the code that doesn’t quite satisfy all the invariants. I forget something;an assertion will botch and then it’s like, bing, I know what to fix.

Also I’m even now learning about my own weaknesses, where I’ll optimizesomething too much. I’ll have made some kind of happy pony land in myhead, where I forgot some important problem. That’s always a challengebecause programmers have to be optimists. We’re supposed to beparanoid, neurotic, Woody Allen types who are always worried aboutthings, but really you wouldn’t get anywhere in programming if you weretruly paranoid.