Stephen Wolfram is in the business of making people smart. His creations, including Mathematica, Wolfram Alpha, and Wolfram Language, help people think computationally, and he’s not being arrogant when he compares them to the invention of mathematical symbols. As the founder and CEO of Wolfram, he oversees a team of 800 people, but he highly prizes learning every technical detail he can, and maximizing his own input.
Stephen recently published a 14,000-word essay on his personal productivity habits, including specially designed desk drawers, a flat file system, and the health benefits of taking his laptop for a walk. We interviewed him at length about his mental strategies, making sure self-measurement is a tool and not a distraction, how he avoids delegating away his intelligence, why Google is bad at institutional search, and an evil hack for making your wifi network stand out in a crowd.
Lifehacker: How long have you been working on this piece in particular?
Stephen Wolfram: We’re trying to finish version 12 of Wolfram Language. Usually I am deeply involved in things with our product. But right now we’ve got a couple of hundred people working on finishing the thing, and they’re just fixing bugs and there’s nothing for me to do. And I was kind of going crazy. I’ve been meaning to write this piece for a decade. So I [decided to] jump in and do it.
I didn’t take very long—it was maybe a week, 10 days between thinking of doing it and having it out. For better or worse I’m a fairly fast writer, a “write once” kind of character. I’m not a good “revise your work” kind of person, because I figure it’s better for me to write more stuff than to have it be more perfect. That wasn’t the theory that I followed when I wrote this big book, A New Kind of Science, which took me 10 years! That, every page I went over endlessly. But that has made me subsequently prefer the “write once” strategy. So I’ve been meaning to write this piece for 10 years, but it actually took about a week.
LH: You make a lot of references in the piece to Wolfram Language, Wolfram Notebooks, and Wolfram Cloud. Can you give a broad description?
SW: The big picture is trying to deliver computational intelligence to everything. For the last 32 years I’ve been building this thing called Wolfram Language: not a programming language, it’s a sort of general computational language.
The goal is to build as much automation and knowledge into the language as possible. At first, when computers were new, 60 years ago or something, people were very excited when they got their very first so-called high level [programming] languages. And then they were excited when they got their first operating systems. And then it started to be taken for granted that when you got a computer it comes with an operating system. You get a computer and it comes with a user interface, networking, etc.
What I’ve been interested in for a long time is if you get a computer and it comes with a layer of computational intelligence, so that the computer intrinsically knows how to do machine learning, knows all kinds of facts about the world, maps and socio-economic data or whatever else. That’s what Wolfram Language delivers. As much as possible in terms of knowledge and intelligence is built right into the language, so that the human gets to do as little as possible.
I started building the precursors of Wolfram Language more than 40 years ago now. My basic idea was, I’ve got things I want to do, science I want to do, other kinds of work I want to do. I want to build the best tools I can, to make it possible for me to do that work as efficiently as possible. And it turns out, I’m a practical guy and those tools that are useful to me are also useful for lots of other people. And I also am practical enough to want to build companies around the tools that I build, because that’s how one gets to go on building more of those things.
Within our company, my strategy has been to have very talented people, but to automate as much as possible. And we’ve done that over and over again, building layers of automation for the last 30 years. My goal is to delegate as much as possible to the machine. So I get to have ideas and figure out what to do, and as much as possible of the details are handled automatically.
Wolfram Notebooks is an idea we released 30 years ago. [Digital] notebooks have become popular in the last few years, and it’s kind of shocking to me that it took 25 years for the world in general to say “Oh, notebooks are a good idea.” The point of Wolfram Notebooks is a structured document that mixes text with code, and graphics, and interactive interfaces and so on.
When write things, I use a mixture of English and Wolfram Language. People 300 years ago started using mathematical notation; before then people would write out—mostly in Latin—what they wanted to say that was mathematical, and it was very hard to understand. I’m interested in using computational language as an efficient way to express oneself. That’s what I built in Wolfram Language. It’s something that both humans and computers can read. And it’s a way of organizing one’s thoughts, much in the same fashion that mathematical notation helps people.
Another objective is to help clarify one’s own thinking.
LH: So it’s not only being able to call up values or functions, but it also makes you think differently.
SW: Yeah, it provides a way of structure. People debate, for human languages, whether what language you use affects how you think about things. For computational languages, there is no question that this is the case. I’ve noticed as I develop Wolfram Language over the years: As we crystallize some new structure, then I can start thinking in terms of that structure. Without that it’s very hard.
There’s one slightly complicated functional programming construct called “subset map.” I realized after I figured it out a few months ago, I’ve needed things like this for years and years and years, but they’ve all been swirling around, not well organized for me. Now that I have this organizing way of thinking about it, I can inject that construct into lots of things.
This whole computational paradigm is the paradigm of the 21st century.
LH: Let’s talk about this super-optimization that you have for a lot of your work processes. How do you decide what you are going to optimize or not? You make some interesting and surprising choices—in the beginning of the article, you’re talking about your physical workspace and habits of say, walking around outside with a laptop strapped to you. If I saw this without knowing who was talking, I’d be like “Here’s someone who clearly isn’t getting anything done because they spent too much time optimizing it.”
SW: The meta point is, just keep the thinking apparatus engaged while you’re doing what you’re doing. That is, if I notice that there’s something I’m doing that’s obviously silly and repetitive, I’m not just saying “Oh that’s the way it has to be.” Just like I try and solve problems in lots of other areas, I’m still thinking about how I can solve that problem.
Another piece to it is that just because everybody does it such-and-such a way doesn’t mean I’m going to do it that way. I mean, my wife is often critical of my “I’ll just figure it out for myself” type thing, because sometimes it goes wrong. And there’s a tradeoff between “just do it the way everybody else does it” and “always figure it out for yourself.” Always figuring it out for yourself can lead to wasting a huge amount of time trying to do something that turns out to be really hard. But I would say the majority of the time, it ends up being something that is much better optimized for me than your typical solution would be.
I do try and keep thinking when I’m doing stuff. Something like file system organization. I think I’ve done four file system reorganizations in my life. Not a huge number. But every so often I’ll decide, “This is not working. I need to do something about it.” I will have been thinking for a while about it. And I’ll sit down and try and solve the problem.
I suppose the fact that I’ve spent a large part of my life doing language design is probably useful for coming up with solutions that work. Because language design is a story of how to take a whole set of things you’re trying to do and crystallize them into something that is understandable, workable, etc. And that’s a lot of what a lot of these kinds of optimization decisions are about. You can lead your life and do absolutely no planning. Or you can spend all your time planning and not remember to lead your life. I like to spend, you know, a few percent of my time planning what I’m going to do.
Plenty of the projects that I’ve ended up doing, like the Wolfram Alpha project, making this computational knowledge engine—I have been thinking about doing that project since I was a kid, and I had not thought that it would be possible until pretty much the time when I started trying to do it. And there have been people who had thought about projects a bit like that for about 300 years. If you started it 300 years ago, it was definitely not a doable project. And I’m sure if I’d started it 40 years ago it would not have been a doable project either.
LH: Can we talk about your personal tracking? You’ve written about it before, and in the new post you talk about making some decisions and discoveries. For example, you started walking outside with your laptop, because you noticed your resting heart rate drops more when you’ve walked outside than when you’ve walked on a treadmill:
For many years I’ve kept all kinds of personal analytics data on myself, and for the past couple of years this has included continuous heart-rate data. Early last summer I noticed that for a couple of weeks my resting heart rate had noticeably gone down. At first I thought it was just because I happened to be systematically doing something I liked then. But later in the summer, it happened again. And then I realized: those were times when I wasn’t walking inside on a treadmill; instead (for different reasons) I was walking outside.
Are you normally checking your heart rate stats every day?
SW: Most of the things that I keep are completely automated and I don’t do anything with them. The main way that I see them is because I get mail sent to me every day with the summaries of different things. I’ll glance at that mail for probably half a second or something, mostly just to see if the data came in correctly. The heart rate thing, I’m sure I noticed just by glancing at that mail.
My fundamental thing about personal analytics is, I don’t put any effort into collecting the data. I put effort into getting systems built to do it, and then I make sure the systems keep running.
Actually just yesterday, I was looking in my archives and I discovered something I’d completely forgotten, which is that I used to keep handwritten notes of things like sleep and wake times, before I was doing that automatically. I was just amazed that I had been doing that. It seems like way too much work for me!
LH: And when you’re deciding what to track, does that usually come about because you found some new device or system that lets you track something easily, and you’re like “OK, let’s just try it and see if anything interesting happens”? Or is this more goal-oriented?
SW: Anything I can track, I track. And most of these systems, once they’re set up, I never have to think about them again. Years ago I started taking a picture of my computer screens every, I don’t know what it is, 30 seconds or a minute or something. And that’s been running for years and years and years, and I never think about it. Occasionally I think maybe I should make a movie out of that. And I look at it, and it’s amusing to see the e-mail scrunch down and expand and so on, but it’s pretty boring. Will I ever use that data for anything? I don’t know. It’s super cheap to keep. And so why not.
LH: How do you avoid constant maintenance of these tracking systems? For example, I track my music listening on last.fm, but I’m constantly fixing it because it double-logs an album, or it can’t log my listening on Apple TV.
SW: First thing is, the more you can dashboard it in real time or every day, the less likely you are [to let the system fail]. Some report that came in this morning, a piece of it was blank. So I know that immediately. Something failed yesterday. I admit that there’s a bit of cheating going on there, because I have a sysadmin person who works for me, who I just sent mail saying “This seems to be blank, please figure out what’s happening.” Now, some of the code I wrote myself, and sometimes it’s faster for me to express myself by writing the code than it is for me to tell somebody, “Can you make a piece of code that does this?”
This is the value of having a computational language. I can express myself that way more efficiently than I can express myself by sending a piece of e-mail or something saying in English “Please do this and this.”
Another thing is, I like to keep all my data myself. There are various kinds of devices I would love to use, but I’m just not going to leave the data in that provider’s cloud. If I can’t download it, I really don’t want it. Things which have been sitting actively on a disk, in my active file system for 40 years, they’re still there, they’re still fine. Things that were in somebody else’s file system or went into some other medium, who knows?
So keep it in your active file system. Check it. Have something that sends you mail every day, where you can take that half second to eyeball that it isn’t totally crazy. And I do have some systems that aggregate stuff that is supposed to be coming in from a bunch of other systems, and give me a master conclusion. There’s one that comes in every week that’s a master conclusion of “Did all of the things that were supposed to come in every day actually come in?”
All these systems rot at a certain rate. And the trick is to fix them quickly rather than to discover this thing stopped taking data three months ago. In past years, a decade ago or more, I was caught a few times with the, “Oops the system stopped working a month ago.” And that’s why I now have the daily dashboard result.
LH: Are there any tools you use to find insights from the data you collect, without having to wait for the human insight of “Oh wait a second, this heart-rate drop is when I go out for walks!”
SW: I’ll do some visualization, maybe I’ll do some fancy machine learning thing if I think it’s going to be useful. But it tends to be human-initiated.
The fundamental thing about good data science is, can you notice the unexpected. And one of the problems with being very clever about the automation is, the automation implies certain expectations about what’s going on. It’s much harder to discover the unexpected when you have already put in a bunch of expectations.
LH: Let’s talk about your choices between search and sort, which you talk about in your piece:
Over the years, I’ve accumulated over a hundred thousand notebooks, representing product designs, plans, research, writings, and, basically, everything I do. All these notebooks are ultimately stored in my filesystem… And I take pains to keep my filesystem organized—with the result I can typically find any notebook I’m looking for just by navigating my filesystem, faster than I could formulate a search for it.
I feel like I’ve seen, even as early as 15 years ago, a lot of productivity writing that said to make everything optimized for search. Search is the way we’re going now, we’ve got Quicksilver on our computers and Google on the internet, and sorting just isn’t as important anymore. But you make a really good case for cases where you really do want a little bit of sorting, and in those cases searching is never going to be as fast.
SW: I think it’s a question of whether it’s conceptual, or it’s finding a particular name. I’m about to go to my close to 50-year elementary school reunion. And so I was tracking down what happened to all these kids and search is the thing for that. You’ve got a name. But if it’s a concept like, I don’t know, teaching computational thinking to kids. I’ve done a bunch of work on that, I’ve collected tons of stuff about that. What would I search for? There isn’t really a search term [that will turn up every relevant item].
And of course when it comes to search, one is spoiled by internet search, because the problem of enterprise search is similar to the problem of personal search. With web search there’s the signal of how many people link to this page. That gives you a signal of how important is this page. The problem of enterprise search has never been well solved. Because there isn’t a similar obvious signal.
We once swapped a site license for Mathematica to Google, in exchange for a Google internal corporate search appliance. It was beautiful, it was a lovely yellow box, but it was absolutely useless. It would do things like it would say, “There are more links to earlier versions of the documentation, so that’s what should come up top in the results.”
And for these more conceptual things, the idea of saying I’m going to put in a tag? I’m going to put in the right set of tags? Good luck. I’ve never found tagging useful. I found, I put it in this bucket, which I can do very quickly, and I know what the buckets are. If I was going to do tagging I would end up having some crazy list of my 200 tags that I could use. It’s very important to have not too many categories, so you can remember every category. So you know “I’m going to file this in roughly this place” and you can build up a personal acquaintance with that category over time—even if the category isn’t precisely named right. I think the most important message there is, don’t try to be too clever.
I spend a lot of time doing language design, and language design often involves making up names for functions for languages. If you change the name, as one often does as one’s homing in on the concept, search is out the window.
I’m aware of laying things down so that they are searchable later. I am a real stickler for making sure my assistants spell a person’s name correctly, because if you don’t it’s lost forever. But you can’t search for concepts. That’s sort of hopeless.
LH: I also liked your mention of the archive folder—how every folder has an archive folder inside it, for files that are no longer active. I love using archive folders too, they save me from a lot of clutter.
SW: You’re ahead of most people. I haven’t really done any kind of systematic study but I have looked over the shoulders of people at what their file systems looked like. I’m surprised by how few people seem to have figured it out. Maybe people who read your publication are the type who will have figured this out.
LH: You show the gadgets that you always take with you to a conference or a presentation, including a bag full of adapters. Because you never know whether the projector is going to be ready for your specific computer and its ports. We’ve all been frustrated when some state of the art projection system is missing one dongle, or it’s not recognizing your computer for some mysterious reason. And I really like the line, “I decided I’d better actually understand how computers talk to projectors.”
Do you have any advice on recognizing bottlenecks like that? Realizing that there’s a category of thing that might seem ancillary to your work, but eventually becomes such a chokepoint that you should learn the actual science or technology behind it?
SW: There’s all kinds of stuff like that. Like when you go to some place and you switch on your computer and it’s looking around for wifi, and maybe you have a phone tethering mechanism. Often the thing is freezing because you’re in the middle of New York City or something, and there’s 800 wifi networks that your computer’s connecting to. The thing was driving me crazy, I’m trying to scroll through 800 things to find my phone. So I realized I should rename my phone, so it always sorts at the top.
I don’t want to make that tip too popular!
LH: It doesn’t obey the categorical imperative.
SW: And then we’ll have a fight for the top.
I’ve been CEOing a software company for a long time. So you would think that when like systems things go wrong that there would be some set of people who will fix them, and I’d never have to know about them or think about them. But I have kind of made it a principle to, you know, when we have some nasty bug, I always ask people, what was the bug? Because that’s built up, over the course of years, a huge amount of experience.
An example from today. Some websites of ours mysteriously lost their CSS. How could this possibly be happening? And we don’t know the answer to that yet, although I was able to offer a bunch of theories because I’ve had experience of seeing weird things happen. But when that gets fixed, somebody will tell me what the actual problem was, and that goes in my personal database of the possible things that can go wrong.
I make a point of reporting bugs when I notice them. It feels like a kind of a good citizen type thing to do, because the fact is most of the time people don’t report bugs. Most of the time they just work around something and the world goes on and other people get bitten by that bug.
My approach to debugging is rooted in my whole computational-thinking way of doing things. There’s one I wrote a post about actually, about finding a bug in our cloud infrastructure. People are quite bad at debugging. Debugging is a complicated skill, kind of like medical diagnosis. And it’s not as well codified for debugging computer systems as it is for medical diagnosis, where one knows there’s this percent probability of this or that, but it’s the same kind of idea, [testing theories one by one] and so on. But the thing people don’t do very much, and they really really should, is data science for debugging.
One case, this was a mail system, it might have been Apple Mail or Zimbra. My mail was bizarrely failing for some reason. And I got fairly upset about it and eventually I insist on being on the phone with somebody from whatever vendor this was. So we’re looking at all these messages. I start doing a lot of data science on it, and I discover: Every time it starts more than 256 simultaneous threads, the thing’s dying. It turned out, because I had more than 512 mail folders or something, the thing couldn’t handle it.
This would never have been figured out by looking at individual messages. What you saw was just, it worked worked worked worked worked, and then splat something failed. There was no counter that said you just started the 256th thread. It was just, somewhere in the middle of all of this, boom it fails.
In our company for example, actually as a result of that debugging that I did on our cloud infrastructure a number of years ago, we built a group of essentially physicists who do data-science-oriented debugging of complicated systems. And that turns out to be a really quite powerful methodology.
While it is frustrating at the time, they’re quite interesting intellectual exercises, these debugging things. The more you know, the better you’re going to be at it. So having this background experience is really useful. When something goes wrong, even if somebody fixes it for you, find out what they did.
Interview edited for clarity. For more follow-up on Wolfram’s essay, read his Reddit AMA.