When Brad Fitzpatrick was five, his father, an electrical engineer at Intel, handed him a simple BASIC program:

10 Print "Hello World."

20 Goto 10

What, his father asked, do you suppose this does? The long term answer to this infinite loop turned out to be a jump start to a career as a programmer. Fitzpatrick would go on to invent the influential social network LiveJournal, selling his company. Some of the technologies developed for LiveJournal have become well known open source projects, including the Memcached distributed memory object caching system, which is used by YouTube, Facebook and Twitter. In 2005, Fitzpatrick sold his company, Danga Interactive, to Six Apart, and was involved in the subsequent sale of LiveJournal to the Russian media company SUP.

He did all this before age 30. For an encore, he joined Google, which has given him a virtual license to apply his talents wherever he sees fit. It was before work that I spoke with him by phone one morning from his home in San Francisco.

The goal of every teacher is to be surpassed by your pupil. When did you overtake your father?

He says that by the time I reached seven or eight, after I started programming in C, I had passed him up. And that's possibly true; he's more of a hardware guy than a programmer. But my dad did more than teach me directly. He introduced me to the technical book section of our local library. Mom always jokes that I was reading the Apple II BASIC Programming Manual around the same time I was reading Clifford the Big Red Dog. By high school, I was doing contract work. Our neighbor, for example, needed some software ported from DOS to Windows. I was able to do that. My friends and I also made games, which we sold at school.

Did you major in computer science at college?

I did--at the University of Washington in Seattle. A lot of what was taught wasn't new to me. And a lot of it was way too theoretical. Looking back, I think my time might have been just as well been spent reading the right books. The most important thing for me in college turned out to be running LiveJournal.

You seemed to have been way ahead of the curve with LiveJournal. You launched it five years ahead of Facebook.

Yeah, that's true. Dana Boyd, a researcher at Microsoft Research and Harvard, has done presentations on all the things LiveJournal had ahead of Friendster, Facebook, and MySpace--including the ability to mark favorites, leave comments, and give virtual gifts.

One legacy of those days seems to be the number of social networking sites--and sites with a social network component--you are involved with. I count 24 of them linked to your home page.

I think it's better to have lots of little services that integrate with each other, even as they compete with each other. For the first two years at Google, I worked on decentralized social networking. The idea is that social networking can itself be a protocol, in the same way as SMPT or HTTP are simply ways of communicating across servers to accomplish some end. I think that social networking should operate similarly, with mix-and-match pieces that you put together in different ways. I'm still working on that, but my involvement is now more political than technical. For example, for two years I've been working in a group that is trying to get Webfinger defined as a protocol. Webfinger would allow people to attach metadata to an email address. It's a UNIX idea from the 1970s, and I think its time has come again. Now, I've added Webfinger to Gmail, Yahoo! has added it, and we are now trying to better define how it should be used. Achieving consensus like that isn't easy, but it is preferable to what too many people do: build monolithic services that only work with themselves. That's superficially the easier approach, but in the end, I think you'll see more social networking Web services that interoperate with each other. This was also why I did OpenID, another decentralized protocol, for logging onto websites.

I'm interested in that intersection between what you do for yourself--like starting LiveJournal to connect high school friends--and what you do to make a living. Do these two approaches blur together?

Typically, I pursue projects that interest me, that are fun. Sometimes it turns out that other people are interested in the same thing. If you build a business around what you like to do, you'll at least put a lot of effort into it. That's still true for me at Google. Everything I work on at Google I would want to work on anyways. It just so happens that Google wants to pay me.

What do you do at Google?

Recently, I've been working on Android performance--trying to make the operating system, and hence the entire phone experience, run as fast as possible.

So you mostly optimize code?

Sometimes. But mostly I write analysis tools for the development teams at Google, as well as at HTC, Motorola, and other Android development partners, that try to show why things aren't running as fast as possible. The amount of instrumentation varies depending on the class of user, but in general, we provide a lot of dashboard feedback that alerts developers to performance problems: showing, for example that a database operation is slow, or an RPC [remote procedure call] between two processes is consuming too many resources.

You've praised the Google development environment.

The Google development environment is nice; the Android environment is less so, because as an open source project, it lives outside the Google world. So on the Google side, we have our own build system, which is a pleasure to use, while on the Android side, we use make, as well as other open system tools. The idea is to make sure other people can do builds, even though they don't have any of the non-standard crazy stuff that Google has.

In fact, we are trying to bring some of that technology over: we're open sourcing everything we can. The problem is that many developers have built systems that are heavily dependent on open source development tools. So we try make sure that anything we open source has a maintainer that will work with the community, rather than just throwing a library over the wall and telling people: "have fun." Open source development is something of a pain compared with just maintaining the code for internal consumption. Internally, we have comparatively few supported configs and distros. But once you open source a library, you encounter a lot of noise over portability and other issues you never had to consider.

At the age of 30, where do you see your career headed?

I came to Google because I had done the startup thing and the medium-size company thing: and I wondered what the big company thing would be like. But there was another reason. After work, I'd come to the neighborhood park where my Google friends were hanging out. And suddenly, the conversation would come to a halt. I'd realized they were talking about secret Google stuff--and my very presence had killed the conversation.

In truth though, I actually didn't think I would be here this long. That I have has to do with my job description--or the lack of one. When I walked in the door the first day, they gave me a computer and said: "have fun." That was about the extent of the direction, and I've just bounced around, working on what has interested me, ever since. So in that sense, it might be hard to leave Google. There are so many awesome projects you can work on. If you don't control yourself, you can "20 percent" on a dozen different things.

The "20 percent" refers to the time Google gives people to work on projects that aren't part of their job description. You've joked that you have seven of them.

Yeah--seven 20 percent projects: what's that add up to? But I do think it would be fun to do another startup sometime, especially if I had the right group of people. We'll see.

What's your advice to developers who are just starting out about where they should take their career?

Well there's the obvious: work on cool stuff--things that interest you. But beyond that, I think you should try to understand the entire software stack all the way down, if even only vaguely. There are so many people who are only comfortable at one level, and who just assume that everything written below that is just perfect and magic. Every level of abstraction is really designed to make you feel comfortable. But in practice, implementations tend to be crap or to be hiding functionality from you. So if you actually peek under the covers, you'll often think: "is that all it's doing?"

Maybe you are using an API, or somebody's Web services, or some library you've downloaded off the Internet. Don't just use it, but look to see how it's actually implemented. You may realize that that layer of abstraction may be hiding access that keeps you from doing all other things. Or you'll think: it's doing it inefficiently: if I bypassed this abstraction layer, I could do it much more efficiently, myself. The same might be true looking at the disassembly at the compiler level, particularly if you are writing something that's performance-sensitive. If you are writing your own video codec, definitely look at the output of the compiler. So my advice: write your program at a high level, then start poking down to see what's happening under the covers. Doing that may at least give you some ideas of other things you can do.

It sounds like by digging into the stack, you can redefine who you are as a programmer.

It opens your eyes. You realize there's no magic, no magicians, and that there may in fact be better ways to get the job done. When I first started using Linux and Unix, I considered the code to be perfect--that it was written by gods. If I ran into a problem with a Unix tool, or an Apache or Perl tool, I figured it must be my fault, because this tool is blessedly golden, because it came from the Apache project or CPAN [the Comprehensive Perl Archive Network]. It took me a long time to get the confidence to realize: this is just other people's software, and other people can suck, too. I'd look at the code and realize I could totally write a better one. So yeah, it definitely gave me a lot more confidence. Now I question everything I use. First I figure out how a technology works, and only then do I decide if that's the best way to accomplish my goals.