It is easy to think that the big deal these days has to do with multimedia (YouTube) or social networks (Facebook), but the written word is changing too! As someone who writes for a living, I am fascinated by how writing has changed drastically in recent years. Of course, the Web has changed the way we write in an obvious way: it has become less of a formal activity and more of a social one. However, even formal writing, such as the production of research papers, has changed a lot. We are in the middle of a revolution.

• Documents are not standalone objects. Documents are commonly hyperlinked, and when they are not, it is increasingly easy to browse through the documents that reference it or through the documents referenced by it. PageRank is just one example of how links between documents are becoming as important as the documents themselves. I no longer read scientific papers on their own: I always read them as part of a stream of papers in a given area. The fact that I can download in about 5 minutes a dozen of papers on the same topic, makes a big difference. I very frequently look up the Web pages of the researchers I read, just to see what they worked on beside the paper I read. Most blog posts do not stand on their own: they are part of a worldwide exchange. Also, papers are no longer static objects: several times a year, I will write to an author I read and get feedback from him.
• Transparency matters. As it becomes easier than ever to make information available, it becomes less acceptable to keep relevant matters secret or to lie. Bloggers are famous for sharing openly: lying on your blog is dangerous because so many people can check your facts. Increasingly, researchers are asked to make source code and data available. You can no longer write for a small community: people outside your little group are likely to stumble on your work as well.
• Countries and organizations do not write, people do. A journal that accepted one of our papers objected yesterday that, in the reference section, we omitted the location of the publishers and where conference were held. But I do not care about where the results first appeared! They also asked us which organization was behind each of the proceedings paper we cited: I do not care! Several years ago, I was asked if, as a researcher, I had international collaborations. The question does not even make sense to me.
• Metadata is more about selling than about describing. Many people still write abstracts as if they had to summarize their work. But I can grab your paper in about 2 minutes and read its introduction in 5 minutes. We no longer mail order science papers. So the abstract should tell me why I need to read your paper. The same hold true for blog posts: your title is not there to describe the blog post, but to tell us why we should care.

• Work on projects you love doing, even if only part of the time. You can only be as smart as you are motivated. I will never be a smart electrician.
• Reading and learning are important, but people learn by doing, by tinkering.
• Carry a notebook or a PDA, and use it to record ideas. Periodically discard most of your ideas.
• Having a blog can’t hurt.
• This is probably the most important point: hang around with smart people. If you live among monkeys, you might have a good life, but you will not earn a Ph.D. (except if you are studying monkeys!). Happily, you can easily hang around with smart people wherever you live thanks to the Internet. This is important because if you hang around with people who do great work, you will be motivated by emulation: nobody likes to feel like a loser among his peers.
• Push yourself: try daring projects and learn to fail. Be ambitious! Do not waste your time with things you know how to do well. Go beyond. Aim as high as you can, while trying to stay on track.
• Context is important when solving problems. I found that offices are nearly the worst place to work for me. My home office is much better. Sometimes, a coffee place can be a decent alternative office (presumably because of the white noise effect). Sometimes, using a pen is better than a keyboard. Sometimes, working with a laptop in your bed is better than working on a desk. Change, try new contexts!
• Come back to important projects regularly. Do not get lost in the small stuff.
• Urgency is an important factor. Somehow, being too happy about what you achieved can slow you down. This suggests that you should be critical of your own work, and you should not underestimate your competitors. Of course, you need to stay motivated, so do not overestimate your competitors or underestimate your own work either!

• Omega-3 is good for you and might make you smarter. Eating fish seems like a good idea.
• When you are tensed, eat carbs (bread, cookies). Do not make things worse by drinking coffee.
• Too much coffee tends to get your mind to speed up and you lose focus easily. You end up getting many things done, but you no longer have time for thinking about the hard problems.
• When you need energy, eat proteins (cheese, meat, beans). Coffee alone will only help you temporarily, it does not get you through a lot of hard work.
• Drink a lot of water: after all, your brain is mostly water.
• Sleep a decent amount. Some people claim sleep-deprivation allows them to get more done, and it might be true, and I do not know of any evidence that sleep-deprivation hurts your brain, but being sleepy does slow you down and tends to get you to work on routine problems.
• Taking long walks (at least 20 minutes) out in a quiet park, thinking about some deep issues, tend to set me up for good work for the rest of the day.

See also my post My research process.

For further reading and scientific evidence, read my posts Physical factors making your smarter: white noise, carbohydrates, music, alcohol, and coffee? and Thinking intelligence is innate makes you stupid.

Reference.

• David Dobbs, How to be a genius, New Scientist, 2006.

Subscribe to this blog
in a reader
or by Email.

I had two important meetings today. One of them was with my good friend Harold Boley (of RuleML fame) and another well know professor. The other meeting was with an infamous professor who shall remain nameless.

What is most amazing about these meetings is that they happened in my kitchen, using Skype and the builtin webcam of my MacBook. And these meetings were efficient, to the point, content-rich, and pleasant. Moreover they were inexpensive. And I don’t mean financially. They required almost no time to prepare. They required no room, no building. They did not require any staff.

Of course, the bandwidth is not quite the same as a live meeting, but this can be a good thing: I do not care to smell your pheromones nor do I insist on seeing the details of your body posture. Moreover, the bandwidth is increasing at a crazy rate.

What does this mean for our future? It means that institutions are no longer required to get the system running. No vice-president, no staff. It means you can run the world from your kitchen. Or at least, get some research done.

See also my post Big schools are no longer giving researchers an edge?

There is a nice article in Forbes which basically says that directed research is pretty much useless. Directed research is what happens when you tell researchers what they must work on, because you predict that it is what is important. The article is based on a book by Nassim Nicholas Taleb, The Black Swan: The Impact of the Highly Improbable. Here are two great quotes from the article:

Trial-and-error has error in it; and most top-down traditional rational and academic environments do not like the fallibility of “error” and the embarrassment of not quite knowing where they’re going.

(Some years ago, I drafted a funding application where I carefully outlined what could go wrong. I was told that this was suicidal.)

It is high time to recognize that we humans are far better at doing than understanding, and better at tinkering than inventing.

This being said, I am not sure I agree with the Black swan theory. I need to think about it.

However, in research as in most businesses, it is quite clear that the willingness to take risks is an ingredient for success. As for myself, the main reason I take risks is that it is more fun. If I know I will succeed ahead of time, why bother doing the work? So that even if I never come up with a significant unexpected discovery, taking risks is still a very valid strategy.

See also my posts My research process and That’s why I tinker.

Source: Stephen Downes.

Peter released a technical report (available from arxiv) on the computation of the Tucker decomposition on large tensors: the Tucker decomposition is just a multidimensional generalization of the Singular Value Decomposition (SVD). The report includes a new algorithm designed by Peter which is more accurate than competing Matlab implementations, in the case where you have very large tensors (3 or 4 dimensional) and need external memory computations.

There exist incremental SVD algorithms. It does seem to me that a nice property of Turney’s tensor algorithm is that it can be made part of an incremental scheme efficiently.

Another challenge would be to have a serious look at parallel implementations. I think that Turney’s scheme could benefit tremendously from several processors.

One thing you never read about is how people do research in their mind. People do describe how to write papers, how to get an academic job, but somehow, I cannot recall anyone describing their thought process.

Mine is simple enough. It includes both theoretical and experimental work. So here it is…

• I usually start with a specific problem. This problem must be about something significant: a few people worldwide might want to know about the solution. It must be sufficiently narrow that I can address it in a few months. I try to apply the Turney’s principle: be ambitious. In other words, it should not be obvious when I begin that I will succeed. Yes, this means that I do not know I will be able to write a paper at the end! And yes, this means that I sometimes fail. Ideally, I pick a problem so original that I am the only one working on it, worldwide. Almost invariably, the nicest problems take one of the following forms: 1) I want to explain theoretically something I observe experimentally 2) I want to improve on an existing method by at least an order of magnitude (in accuracy, simplicity, speed). Merely aiming to improve an existing approach by a small amount is something I avoid, if only because I know that given enough time, I can always hope to improve any technique by a tiny amount. There is no challenge, no surprise, no risk of failure!
• A good problem is such that I can then it process down to at least one simple conjecture. A simple conjecture is one that I can realistically hope to make progress on within a few days or a few hours. Sometimes I verify the conjecture experimentally, sometimes theoretically, it does not matter. I avoid working on several small conjectures at the same time: I try to handle them one at a time. Sometimes, the result of my work on a conjecture will be another conjecture. Sometimes these conjectures turn out to be silly, in retrospect.
• Once I have processed the first simple conjecture, I try to come up with other ones that will bring me closer to a solution to my problem. Always picking the next most promising one.
• Very often, I will give up on a problem or the problem will change drastically over time. Or the problem will generate worthwhile subproblems. At any given time, I have about a dozen different problems on my radar, but only about 2 or 3 active ones, and only about 2 or 3 conjectures I am working on.

Collaboration messes up this process because I no longer control the overall problem. But I will still decompose the problem into conjectures that I take one at a time. One benefit of working with someone else is that you have someone who will read and check your conjectures. You can also check someone’s else conjecture which is refreshing. You are also much less likely to make crucial mistakes in the process if you work with others (especially if your collaborators are any good).

To a large extend, my process does not rely on brilliant insights nor luck. I merely grind the problem slowly, each time approaching closer and closer to the solution (hopefully). I do not care about making mistakes. I am very, very often wrong. In the past, I have wasted months working on useless problems, generating useless conjectures: this tends to happen more frequently if I work alone.

What makes me more productive, mostly, are nice problems. Often, picking the small conjectures is rather simple: after all, I do not need to be right, I just need to grind at the problem. If there is any talent involved at all in my process, it has to do on how I pick the overall problem. But even then, I think that passion matters more than talent. The more I care about the problem, to faster I make progress. And more importantly, the happier I am as I work.

Funding opportunities, networking, fame and fortune play no role in the above process. At no point do I worry about what others will think except maybe when I pick the overall problem. And even then, I only check, in my mind, that a few people will care, enough that some journal will publish it, eventually. This egocentric process is probably suboptimal. However, my overarching goal is not to be famous, but rather to enjoy myself and get paid in the process. This is not to say I do care about my peers: I want to earn their respect.

I can sometimes offload some of the conjectures to people working on my projects. However, my process does not scale up very well. I can work in small teams (2 or 3 people), but I could not run a large laboratory (10 people or more) with the above process. I am more of a craftsman than a tycoon.

Subscribe to this blog
in a reader
or by Email.

I wish I could realistically attend this. They are holding a tribute to Jim Gray, the famous database researcher. Jim has been lost at sea. We cannot conclude he is dead, though it becomes increasingly difficult to find an explanation for his disappearance. Mike Stonebraker, of Postgresql fame, will give a talk on “Why Jim Got the Turing Award.” Should be interesting.

I have written about Jim quite a bit here: Jim Gray missing at sea, What is infinite storage? , Science in an exponential world, That’s why I tinker, A “Measure of Transaction Processing” 20 Years Later, ACM Queue - A Conversation with Tim Bray, and so on.

Of all database researchers, Jim is the one who has had the biggest impact on my research and my teaching. Indeed, the cool thing about Jim is that he did not work on abstract nonsense. You can actually take his papers, and give the gist of them to your students, and you will have helped your students a lot.