Interview with Bruce Eckel

Question: Bruce, congratulations on your book award! Can you tell us why you think this book stood out and received the acclaim that it did?

Answer: John Irving, who is almost certainly my favorite author, said, "Never hurry." I did this book at my own pace, and I think that's the first reason. The second is that it came out of a seminar that I gave over and over again, restructuring it each time based on the feedback I got from attendees. The seminar became the core of the book. The third reason is that I put the book up on the Internet as I was developing it. I got wonderful feedback from readers, much better than I've ever gotten from technical readers hired by publishers. The fourth reason is that I built a code-extraction tool that takes the code listings from the book and builds a source-code tree and makefiles. This way, I can validate that every listing in the book compiles properly—that's a useful thing to know when you're trying to learn a language; I had gotten tired of reading code in books only to find out that it was incorrect.

Question: Can you give us a little background on how you got starting in computing and then in consulting?

Answer: I think I was 15 years old when I decided I didn't want to work at a regular job. My father had me working the dirty jobs on his construction sites, and this convinced me that I didn't want anyone else in control of my life. (Dad's foreman told me that the reason I got the dirty jobs was so that I wouldn't go into this line of work. It was effective.)

I was a freshman in high school when I got access to an ASR-33 teletype with all uppercase letters on a drum and punch tape for program storage. This was Basic, running over a modem at some unbelievably slow baud rate (110), but it was magic. We tended to write games more than anything. After that, it wasn't until I was in college that I started using computers again, through physics (which I was majoring in, after spending a year in journalism). I took a few more programming classes as an undergraduate in applied physics (a bunch of engineering classes mixed with a physics degree). Then I ended up doing a master's degree in computer engineering, along with as many other courses in different disciplines that I could get away with (welding, glassblowing, dance, and so on) and still writing occasionally for the college paper.

So, I knew about computer hardware by the time I graduated, but I had taken only a few programming classes, so my programming expertise was mostly in assembly language, and I could use an oscilloscope and a soldering iron. That's what I did for my first jobs—built embedded systems. But, at the same time, I got hooked on C by reading Jack Purdum's book (now out of print, I think, but a great teaching text and an inspiration). Knowing the hardware really made C come alive for me, and it seemed very exciting, but it was quite difficult at the time to convince people that they should use a higher-level language for embedded programming: "Why isn't assembly good enough? It worked before." This was foreshadowing, since I feel like I've constantly been trying to drag people into using more productive tools (lately it's Python, and I get the same response as when trying to use C in embedded systems, where now people are regularly using C++ and even Java).

I began writing for a computer magazine published out of Bend, Oregon, called Micro Cornucopia, and began speaking at its small, free conference. I still have contact with the former editors, and one of them lives here in Crested Butte in the summer, like me, and introduced me to the place. Micro C was a wonderful experience; the authors and the readers loved the magazine and were dedicated to it. Unfortunately, Miller Freeman (publishers of Computer Language nee Software Development magazine) bought it to close it down and reduce competition. At the time it was closed, there was a whole series of pending articles on how to build a robot in a flower pot, just to give you an idea of how cool the magazine was.

I had a column in Micro C for four years on "Interfacing to the real world," where the theme was to build some hardware that hangs off your computer and program it to do something using a high-level language, things like analog-to-digital conversion, controlling switches, and even just making LEDs turn on and off. So, you see, even then there was this theme of trying to use the most powerful tools at hand to solve a problem with the least amount of effort. Why build the whole system when you have all this hardware already running, and why use assembly when you have a high-level language? Most people answer, "Because it's what I already know how to do" and don't want to learn something new, even if it makes them 10 times more productive (like Python does). (The other thing I've been working with lately is the application server Zope—see http://www.Zope.org—which provides an amazing free platform on which to build networked applications.)

After writing the column for several years, I started feeling like this information should be in a book. But I assumed that it was very hard to get a book published, so I didn't even try. Instead, I published it myself, printing 1,100 copies and selling it through the magazine. It was surprisingly successful, considering everything—I got my investment back and eventually made a worthwhile profit. I still have copies of the book, although I'm trying to redo it as an online book.

I should mention that my whole motivation for writing, although it turns out to be a reasonably pleasurable experience for me, was that I wanted to be a consultant. I thought that if I could publicize myself through writing, I could get lots of consulting work. I actually believed that when my first article came out in Micro C, to an audience of 20,000, I would have to change my phone number because I'd get so many calls for consulting work. The magazine got a number of letters to the editor about the article, which they thought was phenomenal, so they wanted me to do more writing and the column ensued. All in all, I ended up writing more than 150 articles over the years for various magazines.

The whole time, I hardly got any consulting jobs, so I kept doing other things. I got different kinds of jobs, doing the "OOP World Tours" with Borland and other things like that, but not the kind I really coveted, where I would come in and evaluate projects—do design and code walkthroughs, that sort of thing. These came along only rarely. One time a fairly well-known company brought me in, but when I got there, they said that they hadn't thought that I would have time for them. They thought I was so important that I wouldn't do the very thing that I wanted to do from the start! I had over-marketed myself, and to this day I wonder how many people still think that. In the meantime, though, I ended up building my own things to do, such as when I started putting on my own seminars instead of doing them for other companies (this was enabled by the Internet). Lately I've been managing a lot of my own development, using people as far away as Prague and South Africa to create projects that I've thought of. This has been very interesting.

Question: What do you view as your most accomplished contribution to the industry, and why?

Answer: I guess I don't feel like I've done that yet, so I would rather say that I hope to eventually contribute new ways of learning—more than that, new ways of having learning experiences. The MindView company motto is "Exceptional Learning Experiences," but I think that's just the start. One of the things I've found while team teaching is that if the experience is very enjoyable for the leaders (and we've discovered that teaching this way is so much fun that we resist doing individual teaching even though it might be justified and more profitable), then it's much more enjoyable for the attendees. So, I keep trying to push the boundaries (and these are usually just my own boundaries) about what a learning experience is, and trying to come up with more dynamic and challenging experiences, where I and anyone teaching with me will be at least as challenged as the people in the workshop. This is much scarier, but I find the experience to be vastly more exciting, and the possibilities for learning are compounded.

Sometimes this goes pretty far out on a limb. Once I was asked to give a presentation to a design patterns user group in Washington, D.C. If I'm already working in a geographical area and a user group asks me to present, I can often do it without charging anything, but if I'm not getting paid, I don't feel compelled to be traditional about how I'm presenting or to even promise anything in particular. In this case, I decided to do a "design review" of a design pattern from the Gang of Four book (Design Patterns, by Gamma et. al., published by Addison Wesley, 1994), but a pattern that I didn't understand at all. This was pretty risky, but I've started to realize that if you go into an experience at least a little bit scared, it becomes an adventure; everything is intensified. So I got up, explained what I was trying to do, and dove in. The audience, who turned out to be very sharp and experienced, started talking to me about the pattern, and we managed, as a group, to work our way through the pattern and understand it. It was very interactive, and everyone seemed to enjoy it greatly—most of all me. In the past, though, I never would have tried such a risky approach to a presentation.

Generally, I try to compel myself to break the rules, and these are often my own assumptions, not anyone else's. The rule can be as simple as, "You can't sell a printed book if you give away the electronic book on the Web," or "People learn best by listening to lectures and then doing exercises." The problem is that there are some truths to these ideas, so it can seem like everything about it is true. But recently I've had experiences that challenge this idea—for example, in my new "working sessions" (which were compelled by having to cancel seminars because the dot-com crash has caused severe cuts in training budgets). I don't really lecture; instead, I simply provide a space and a framework where we attack a particular problem or set of problems. I don't have the solutions ahead of time because I don't know the answers—I'm learning along with everyone else. I had the selfish intent of solving my own problems, but I discovered that everyone had a great learning experience in the process. In many ways, it seemed to be a much better process than the traditional learning approaches.

There is one other thing that I hope I can contribute, and that is a new form of company or way of working on projects. At the last Python conference, Eric Raymond told me that his next paper will be on the passing away of the big corporate structure because it will no longer be economically optimal, as it once was (before the Internet). Instead, everything will be project-based, and you'll assemble a group of small teams to work on a particular project (perhaps the size of each team will be constrained by how large it can be while maintaining Extreme Programming principles, or some other "natural" constraint). I think I've been trying to do something parallel to this in the organization of my company—everyone who works with me is quite independent, so the amount of management I must do is minimal (this is essential, since much of my company is based on my own writing and work). In addition, they are typically not constrained geographically because if someone is independent and can work through the Internet, there's no need. This model seems to scale reasonably well, although finding the right people to fit into the model generally takes time; I have to really understand someone before I know that person will fit. However, everyone who works with me is exceptional in one way or another, and the quality-of-life benefits seem to make up for the other issues.

I've occasionally pondered some way to make a project team, or at least a contract programming service, based on this model. Many people who come to my seminars are quite interested in the idea, so there seems good potential on the supply side, but I think the customers must be reasonably enlightened to be comfortable working across the Internet. I suspect that I'll have to ponder the idea a good bit longer before I can come up with the right model.

Question: Obviously, you've stuck with the "Thinking In" theme (thinking in Java, C++, and so on). In your opinion, how do your publications reflect your theories?

Answer: The basic idea is that the language you speak controls what you can think about. I guess that isn't how I started thinking about it; originally I was looking at the process of language acquisition, and how people who are learning a foreign language eventually begin to think and dream in that language (for the record, I have not acquired a foreign language myself, other than a few words in many languages—I seem to learn only by immersion and so would have to live in another country for a year in order to learn the language). I wanted to teach the language the way that I learned it: so thoroughly that you begin to "think in" that language, so that it's no longer foreign to you, but native.

Recently, I've become more aware of the limitations. I learned OOP through C++, so that was my world view. If something wasn't easily conceivable in C++, I couldn't think about it—an example is in Coplien's Advanced C++, where he goes to great trouble to dynamically add new types to a running system. This was quite difficult to ponder, yet when you move to Java, it becomes natural and even trivial because Java is designed that way. In fact, Java expanded my world view so much that I could go back to C++ and accomplish things that I could never think about before, when I was limited to C++—for example, coming up with an alternative to multiple inheritance by simulating Java's inner classes in C++ (this is in Volume 2 of "Thinking in C++, 2nd Edition," which you can find at http://www.bruceeckel.com/).

But then I moved to Python and began to realize that both C++ and Java, being languages with strong static type checking, had again constrained my world view so that my thinking was limited. For example, I would occasionally get questions from people, usually former Smalltalk programmers, who asked why I put so much emphasis on the concept of upcasting. To me, you couldn't really think about inheritance and polymorphism without understanding upcasting, so I patiently explained it to them. But then I started working with Python and was being about 10 times more productive than I've been with C++ and Java. Python challenged many of my "known facts" about object-oriented programming, and even programming in general.

A big one is that strong static type checking is necessary for robust code. Python is a weakly typed language, like Smalltalk, and I had long derided this concept—how can you possibly find basic type errors if the compiler doesn't check them for you? One of the great improvements of C++ over C is that it had better type checking, which helped C programmers a lot; clearly, this is a good thing and you must have it—and yet Python's type checking doesn't happen until very late (it does do type checking, make no mistake, but as late as possible rather than as early as possible).

Despite my previous certainty about this issue, I'm not only more productive in Python, but I don't seem to have any excessive problem with type errors slipping through the cracks. I began to realize that it's not so important when type checking happens, but that it happens at all. And Python allows much more flexibility in how you use types. It doesn't force you to jump through hoops (mostly in the form of extra keystrokes, like in C++ and Java), and as long as the type checking happens sometime, it's okay. The upshot of this is that upcasting turns out to be a characteristic of a statically typed language (one where the type checking happens early, usually at compile time), but it's not an essential characteristic of OOP, and in Python and Smalltalk, you don't really think about it. The result is that your thinking is less cluttered, which means you can get more done.

Another example of this is templates in C++. My early thinking about templates was very mechanical: Code is automatically produced to customize general tools into specific implementations based on types. The most compelling reason for this is to customize containers to hold specific types. This is certainly what happens, and you could make a complete argument for the validity of this—and that's exactly what I did. But I always felt like there was more, something deeper to this concept, and I didn't have the mental tools to see it because C++ didn't let me think about the bigger ideas. Java stimulated my thinking with its reflection concept, and I later realized that it was along the same lines, but it still didn't give me the framework to see the bigger issue.

Again, Python's weak typing forced me to move to a new level of thinking, and I could eventually see a commonality between Java's interfaces, reflection, and C++'s templates: They are all ways of loosening the typing constraints imposed by the language (interfaces do more than just that, of course, which is why they are such a fundamental concept). Templates, in particular, do the same thing as Python's weak typing: You're saying, "I don't care what type you are, as long as you support the operations I'm going to perform." But in Python, you don't impose any extra mechanism to allow this; it's just the way method calls work. It's so normal that you are able to think in a larger way, whereas the mechanism of templates in C++ is so onerous that you get lost in it and you can't see what it is that templates actually achieve. So by learning another language, my mind was expanded and I could go back to Java and C++ and see things I was unable to see before. That's very powerful, and it's why I consider "multiple languages" a kind of design pattern—it's likely that you can solve a problem much faster using more than one language instead of arbitrarily requiring yourself to stay within a single language.

Question: How would you compare Java and C++? Would you recommend a beginning programmer to start with one or the other?

Answer: Perhaps I'm going to end up belaboring Python here, but my direction lately has been to direct people toward Python, which I think is a superior first language—it doesn't have all the weird nonsensical baggage that C++ and even Java have accumulated. And I'll bet that for most people, Python will probably satisfy their needs and they might not need to learn Java or C++. But if they do, they'll be well prepared because it has a much stronger object-oriented model, without arbitrarily restricting you to the limited concept of "object" that both C++ and Java have. Yes, I know, the Sun folks claim that Java is a "pure" OO language, but it isn't true—the obvious example is Java primitives (int, float, and so on). After seeing the way Python does it (everything really is an object, but if you need to escape out of that for efficiency purposes, you can), having to cope with the special case of Java primitives is especially annoying.

One of the things I'm working on now is a distance-learning program for people who want to learn to program using Python. I think it will be a much faster and more efficient way for people to come up the learning curve. This is still in the formative stages; as you might have guessed by now, I generally think about something for a while before the right approach comes to me.

Once you've had success with programming and are comfortable with objects, then you're ready to tackle a language like C++ or Java, which is heavier-weight and has more arbitrary details for the programmer to master (or become confused by). With a strong background, you'll be able to see the forest despite some of the rather odd trees you will encounter in those languages. Whether you choose C++ or Java (or just stay with Python) will depend on what kind of work you want to do: C++ is closer to the hardware and tends to produce apps that are bound to particular platforms (but that are often faster). Java is more general and has some more powerful high-level concepts, but this also has tied to it Sun's orientation and whatever its current strategy is (some people have suggested that Sun's business plan is primarily bashing Microsoft), despite claims of an "open community process."

I've also informally started working with Walter Bright (who wrote the first C++ compiler for DOS, then called Zortech C++), who is designing a new language that will probably be called "D." At first I was very skeptical because I'm always hearing about great new languages that will be wonderful for everything. But as I read more of the description, I grew excited because he kept saying things that agreed with what I've studied and with my experience, and he was putting things in the language that I wanted to see. Also, I wrote a rather huge email to him suggesting all kinds of things to change and add, and how he might make a language that would have an impact in the current environment, and he started agreeing with me. So, I see great possibilities with this language and think that it might help move the state of programming forward by incorporating features that we've come to believe are useful, like preconditions and postconditions, integrated testing, parameterized types, and so on.

At the same time, just like Python, Walter has no interest in excluding connectivity with (for example) Microsoft, so he has direct, simple support for things like COM (there is a third-party library for this in Java, but you could hardly imagine seeing it as part of the standard Java library). I would also say that I don't see "D" replacing my need for Python, but rather being a complementary language—remember, I'm a believer in multiple-language solutions.

Question: Do you have a favorite book or seminar that you enjoyed writing or teaching for a particular reason?

Answer: This is probably more of an evolution in myself, but I've found that I've really enjoyed design seminars, in particular the "Objects & Patterns" design seminar I've given in various forms over the last several years, first with Larry O'Brien (former editor of Software Development Magazine) and currently with Bill Venners (author of Inside the Java Virtual Machine). Some of this is certainly that I've wanted to move away from introducing the initial details of a language, and, in fact, I've handed off the introductory Java and introductory C++ courses to my associates, who are now much better at giving them that I am.

But the other thing I've discovered is that I really enjoy teaching with someone else, where we can dynamically bounce ideas off each other and raise the level of participation in the workshop. Also, I'm moving more and more toward workshops where I try to, for lack of a less contradictory phrase, design spontaneous experiences. What I'm trying to do is come up with a framework where exciting and illuminating learning experiences can happen by themselves, basically created by the people who come rather than controlled by me. These are experiences that will inspire me rather than exhaust me, and that's what I want.

Recently, I worked with Alan Shalloway, coauthor of the recent book Design Patterns Explained, and we decided to try out a new seminar together on design and patterns, which will be held in Seattle this December. We both want to try out some interesting approaches at this seminar, and I'm looking forward to it.

Question: 10 years ago, programming was supposed to become much more "object-oriented," and it was going to allow even nontechies to program. It seems that programming (be it in C++, Java, or another language) has become much more specialized. Do you agree? And, if so, how do you feel that the evolution of programming is shaping up in terms of the next five years? Or, another way of stating this might be: What are your predictions for the future of programming?

Answer: Sure, every few years some newly hired journalism graduate enters the technology field and hears from some marketing flack that computers are going to start programming themselves, so everyone should start looking for nonprogramming jobs. What usually happens is that we end up needing more programmers because the demand for solutions goes up, not down.

I've heard that the hallmark of a revolution is that you can't predict the future. I've stopped reading computer magazines and, for that matter, most newsy things, so I don't know if computer columnists are still making end-of-year predictions like they used to do, but it was amazing that they had such a bad success ratio for only one year ahead. Most of the time we keep ending up in places where no one visualized.

One of the Python projects that Guido van Rossum (the creator of the language) came up with was called CP4E: "Computer Programming for Everyone." I think Python is a much more appropriate language for the average person to learn because it doesn't have the arcane artifacts that you must learn for C++ or Java—actually, Java is probably worse here because you have to learn import java.io; public class Foo { public static void main(String args[]) { system.out.println("hello world"); }} just to write "hello world." In C++, it's not quite as steep, but there still are plenty of obscure things: #include <iostream>; using namespace std; int main() { cout << "hello world"; }.

To teach all that to a nonprogrammer would probably take you a day, at least. In Python, you can write and store a program, but you can also just fire up the interpreter and say "print 'hello world'," and you've got something running. You say what you mean, and that's something I would much rather teach a nonprogrammer: We've got "hello world" up and running in 30 seconds rather than in a day or two, and there's nothing special or confusing to teach in order to get it going. You're ready to move on to something more, like opening and reading files, which is tremendously confusing for the beginner in Java. It just goes on like that. The result is that I would never try to teach a beginner Java or C++, but I would try to teach them Python.

The original question is, "Will the average user learn to program?" I would say, "Not if they can help it." I don't want to write a program if I can find that functionality some easier way. The people who are compelled to program have urgent problems that can't be solved using the programs at hand. And they have an orientation toward it. I think there are some folks who just don't want to do that kind of thing, and if "hello world" doesn't stimulate them at least a tiny bit, then the rest of it won't be fun enough to draw them on. I believe it's a self-selecting skill—you do it because you like it, at least a little.

Question: Is there anything not happening in the industry that you think should be?

Answer: That's too tough. I have a hard enough time keeping up with and trying to understand what is happening. For example, there's this new "aspect-oriented programming" that some people are talking about. What's that about? Is it important? My friend Larry O'Brien thinks so, and I'll probably have to figure it out myself, eventually, to see how it affects me.

Question: Is programming an art? Or, in other words, can anyone program?

Answer: Is painting an art? I hired some painters to come in and make the inside of my house a different color, and they did a fine job—very competent—but it was craft at the best. I have a friend who has painted scenes on the doors in my house, and those are art. That's probably glib, but it's the same medium and two different uses, and that's the way I see programming. It certainly can be an art, in my opinion. The high-school photographer who takes all the pictures for the yearbook can be a technician or an artist, depending on what he accomplishes.

When I see a truly elegant design, clearly presented, it certainly feels like an art to me. But the creator has to be inspired and deeply care about what the system looks like from top to bottom for me to believe that—and I would probably never be called in to evaluate such a system because it would be too good in the first place (although I might hope to be hired to do a walkthrough of the design or code).

Question: As you know, there are various ways to learn, and you have obviously hit on some of the key methods for teaching something as complex as a programming language. I noticed in some of your seminars that you take a strong stance on problem solving and on interrelating broad topics. For example, in one seminar, you helped participants solve a problem by using the problem/solution to drive the syllabus of the seminar. In other seminars, you talked about both the design elements and how they relate to technical elements of projects. What do you see as the most important areas of focus for students and seminar participants (experienced or not) when it comes to learning something like Java? Should they start with a book, a training course, or a seminar? What are the most valuable resources available?

Answer: One of the things I've learned is that different people have different "best ways" to learn. This is why I have kept trying different ways of communicating—books, seminars, CD ROMs, distance learning, summits, conferences, and so on. I'm trying to brainstorm new and different ways to use the tools we have, like the Internet, to optimize the process.

As you observe, I'm also trying to figure out different live experiences for people to participate in. Although it's sometimes necessary, I've gotten quite tired of the traditional seminar where I drive the whole process forward with highly structured lectures and exercises. I would much rather figure out a way for people to mix it up and struggle with problems the way they might do it in regular life. We all—instructors included—learn a lot that way. And I've found myself getting selfish; I want to have seminars and workshops that are fun for me and the people that I teach with. Interestingly enough, the ones that are the most fun and interesting for us are also the most fun and interesting for the attendees. It's a fascinating challenge because I have to always question my own assumptions about what a good learning experience is.

Question: How important is hands-on experience when it comes to learning a language, and how can those who don't have this experience gain it when they are first learning?

Answer: My friend Matt Moelter, who teaches physics at Cal Poly San Luis Obispo, put this very well. He described giving a lecture, going through the steps of solving a problem on the board, and seeing heads nodding in the audience. He knows exactly what they're thinking: "In theory, someone could solve this problem." Until they must solve something like it themselves—typically something simpler—it's very distant. When you know that we're going to talk a while and dive in and solve some kind of problem very soon, it really focuses your thinking.

This was something that was clear to me and my friend Richard Hale Shaw. For a couple of years or so, we toured around the country and gave one-week seminars on C++ programming. Before we could do this, we knew we had to find some way to have in-class exercises because we had seen the limitations of the lecture-only format and the amazing difference when people actually had to get a program running themselves—they walked away knowing they could solve the problem. So, in programming, I think it's essential to have a kind of "mixed-media" class: some lecture (ideally, highly interactive) and numerous other kinds of experiences: pair-programming exercises, group design projects, iterative project-building experiences, and whatever else I can come up with. The difference between these and ordinary lecture-only classes is dramatic.

Question: We know how valuable your time is, but would you humor us by answering some nontraditional questions? First, if you weren't consulting and writing, what would you be doing?

Answer: Well, I don't consult and write all the time, and so I actually do these other things. For example, Bill Venners (another Java author) and I did a 3-week, 800 mile bicycle tour of the South Island of New Zealand in February—that was a fabulous adventure, and some pretty good exercise. We're in the process of planning another trip, probably through some interesting part of Europe this spring. We've started to give an annual "miniconference" in Prague, so I go to Europe at least once a year, and often more. I might still try to do that, in some other reality. In addition, I will probably still be doing some kind of public speaking because I find that energizing. For example, in March I gave the closing keynote address at the Python conference, and it was one of the best speaking experiences I've had.

When I am in Crested Butte, I spend a fair amount of time outdoors, hiking and mountain biking mostly. When I have seminars here, I lead people on hikes during the afternoon breaks, which is (again) great for both the teachers and the attendees.

I have long dabbled in art in some form or another—photography in high school; ceramics, glassblowing, welding, and drawing in college; and, more recently, further attempts at drawing in the form of cartoons (which I use in my seminar slides). Also, I've been working with painting; I did the paintings on the cover of the second edition of Thinking in C++, Volume 1, and will also be doing the cover paintings for Thinking in C++, Volume 2 (in conjunction with my book designer and long-time friend Daniel Will-Harris, of course).

I take a lot of workshops when I can, mostly at Esalen (see http://www.Esalen.org), which is my favorite place to go for such things. My first choice is usually writing workshops, but I've tried a lot of the seminars there.

I continue to try to come up with more and better interactive experiences. For example, I'm pondering other ways to create books (possibly in teams); my first could be a book on brainstorming, which I think could be a very fun topic on which to give seminars.

Question: In one sentence and in your mind, what are the most valuable words you would want to share with your audience?

Answer: Over the years, I've had a lot of people come up to me and say, "I'd love to do what you're doing, but I can't, and here's why," and then go on to give me a list of reasons why they can only dream about a different life. As a result, they never even do the smallest experiment to see what's possible.

The reason I find this frustrating is that I occasionally imagine a world full of people who are doing what they love to do—and what a completely different place it would be. I believe that if you really love something, regardless of how "practical" it seems (or, in particular, how "impractical" other people might say it is), you can make enough money—even if it means adjusting your lifestyle—so that you can do that thing. I guess I know a lot of people who've done that and are much happier and productive than they ever could have been by conforming and doing something that's "practical."

So I would say that the most valuable words are, "Doubt your limitations."

Question: Who are your mentors and why?

Answer: There are certainly people who inspire me who I haven't met. One is John Irving, who I've mentioned before, because of the way he works—he doesn't rush his art, and he isn't satisfied with it until it's really exceptional. For some reason, I've always admired Sting, I think for the same reason: He seems entirely dedicated to his art; he just wants to create, and that's what he is pursuing. He seems to glide over all the distractions. There have been lots of people I've admired simply because they are very positive thinkers, and to me that is probably the most important talent in life. Someone who can be positive in the face of adversity can either overcome or adapt to anything, I think, so that's one of my big goals in life. If you're inspired, you're a powerhouse and you can accomplish enormous things.

Question: Do you have any interests outside the industry you work in?

Answer: I keep trying to be a novelist, but for the kind of novel I want to write, it takes time and maturity, so I'm not rushing it, like John Irving counsels.

I've long had an interest in art, and I dabble in it myself. I already mentioned the cover of Thinking in C++, 2nd Edition, Volume 1, for example; watercolor and 2D stuff in general is where I'm currently dabbling. In high school, I was the head photographer on the newspaper staff, and in college I worked in ceramics, welded steel, and blown glass, among other things.

I wrote children's plays in high school (my book designer, Daniel, played the villain, which he found a much juicer role than being the hero). In college, I was actually attempting to do research in the solar energy field, and I did, to a small degree, especially in solar distillation of seawater to fresh water. For a while I surfed and skied (something I might take up again). I generally need some kind of physical activity to stay sane, even if it's just riding my bike around town (in Crested Butte, we all ride bikes).

Question: What do you learn from programming that you can't learn elsewhere?

Answer: I think I see this elsewhere now that I've learned it in programming: the value of testing, especially automated testing. For some reason (probably cultural), we tend to forge ahead and pretend that something works, perhaps because we set our eyes on a particular destination and don't want to take any feedback from the bumps in the road. This is the most important lesson in XP, and it is actually the basic concept of science in general, as was driven home to me in a tape I listened to recently of Richard Feynman's last collected writings. He said that the essence of science is doubt: You need to doubt everything, including things that have been "proven" already.

In programming, the best way to put this is, "Hope is not a strategy." That is, you need to have some kind of testing and automation built into your project so that at any time you can do a build; if it gets all the way through, you know that everything is okay, but if it doesn't, you are pointed right at the problem. I've been doing this more and more in my books. Thinking in Patterns has an automated unit test system, and Chuck Allison and I are putting the same thing (his system for C++) into Thinking in C++, Volume 2. The more I work with this kind of framework, the more time it saves me. (Even though it seems like it takes more time, the fact that I can put out a better product more than pays for it.)

As an example of how this relates to my regular life, if I'm considering doing a project with someone who I haven't had any previous experience with, I find that the best approach is to start with a small project in which neither of us is committed to anything huge, and see how that goes. If it goes well, we continue; if it doesn't, we shake hands and part. It's a test, often one that produces something useful, but a test nonetheless. In fact, a written contract is a test. Enforcing a contract in the courts is usually more expensive than it's worth, but if you write down everything you think is in the agreement, in as much detail as you can come up with, and the other person balks at some aspects of the contract, then you've done a test. If that person doesn't want to sign it, it means that you have a disconnect somewhere, and it's vastly better to find this out before you climb into a project together than it is to discover that you're going in different directions after you're invested.

That's something I learned in a great screenwriting seminar that I took from Robert McKee (it's called "Story Structure," and that's the part that interested me, although the screenwriting issues were also quite illuminating): a character presents a personae, which is who that character wants to think he is. But when you put the character under some kind of stress, his behavior says who he really is.

Copyright 2001 Bruce Eckel