Sunday, 26 July 2009

Ten Simple Rules for Choosing between Industry and Academia

Just spotted this piece in the current issue of PLoS Computational Biology by David B Searls.

One of the most significant decisions we face as scientists comes at the end of our formal education. Choosing between industry and academia is easy for some, incredibly fraught for others. The author has made two complete cycles between these career destinations, including on the one hand 16 years in academia, as grad student (twice, in biology and in computer science), post-doc, and faculty, and on the other hand 19 years in two different industries (computer and pharmaceutical). The following rules reflect that experience, and my own opinions.
Here's the list:
1. Assess your qualifications
2. Assess your needs
3. Assess your desires
4. Assess your personality
5. Consider the alternatives
6. Consider the timing
7. Plan for the long term
8. Keep your options open
9. Be analytic
10. Be honest with yourself

Wednesday, 15 July 2009

Opium and colonialism

Excerpt from Tastes of paradise: a social history of spices, stimulants and intoxicants, by W. Schivelbusch:

"The East India Co had enjoyed a lively trade relationship with with Chinese Empire ever since the 17th century. The various chinoiseries that were all the rage among the European upper classes--tea, silk, porcelain--represented lucrative items of trade. In the 17th and early 18th century, when the Middle Empire was still an equal partner of the European powers, these articles were regularly paid for in cash, because the Chinese had no use for anything the Europeans could offer them in exchange.

However, the situation changed during the 18th century when the Chinese Empire grew proportionately weaker as the European powers, above all England, became more and more agressive. Trade between equal partners was transformed into a trade dictatorship by the East India Co, which enforced its will by means of its own militia. Instead of continuing to pay for Chinese products in cash, the company now offered a special trade item, opium. It was a cheap commodity for the company, produced on a large scale on its plantations in India. Estimates are that between 1767 and 1850, in less than a century, Chinese opium consumption increased 70-fold. Obviously, such an increase brought far-reaching social consequences. The comparision with the English gin epidemic springs to mind. One might also compare the role opium played in China since the 18th century with that of coffee in Europe since the 17th century: the stagnation of sociopolitical life in China, one might say, was reflected in opium consumption, just as the early capitalist activity of Western Europe was reflected in its coffee consumption.

It is astounding how deliberately and systematically the colonial masters were able to deploy opium to this end. They took it for granted, of course, that this commodity was to be used only outside their homeland. The East India Co itself, the instigator and chief beneficiary of the opium trade, declared in a statement of 1813 how repugnant a thing it considered opium."

Sunday, 28 June 2009

Are you Free Software or Open Source? Trusted or Treacherous?

I came across this interesting interview with Richard Stallman, the lead developer of the GNU operating system and one of the founders of the Free Software Movement. What I found interesting is that the story behind Linux and GNU actually represent two completely different ideologies that essentially produced the same outcome: that of software for free use/distribution/modification.

GNU is socially-motivated: it was created with the "goal of liberating cyberspace" from non-free software, based on four essential user freedoms. The first step needed for the Free Software Movement was to create an operating system, and so, from 1983-1992, Stallman and thousands of others hacked one out based on the non-free Unix platform, calling it GNU, which stands for "GNU is not Unix". (Stallman later comments on the obvious contradiction of needing non-free software in order to create free software, prompting the interviewer to point out Ghandi's similar dilemma when he asked, in his Hind Swaraj, "How can one argue against western civilization using a printing press and writing in English'?)

According to Stallman, Linus Torvalds was motivated to create his Linux kernel "in order to amuse himself and learn". He ended up making the kernel that would allow GNU to run--the missing piece that the GNU team needed (theirs was not getting very far, it seems). "Torvalds never agreed with our ideas. He was not a proponent of the ethical aspects of our ideas or a critic of the antisocial nature of non-free software. He just claimed that our software was technically superior to particular competitors."

And so, the GNU+Linux operating system was born, but everyone just calls it Linux. To Stallman, the name abbreviation represents two short-comings: the first fails to acknowledge the the thousands of people who started the project and did the majority of the grunt work, and who therefore deserve a share of the credit, and the second one undercuts the fight for freedom on which the initiative was based. According to Stallman, "Today tens of millions of users are using an operating system that was developed so they could have freedom -- but they don't know this, because they think the system is Linux and that it was developed by a student 'just for fun'...You cannot rely on accidents to defend freedom. Accidents can sometimes help, but you need people who are aware and determined to do this".

And so it was that by 1996 there was a split in the community on goals: the Free Software side was campaigning for the freedoms of the individual user, creating a superior product in the process, and the Open Source camp was driven to use the intelligence of crowd-outsourcing to create a superior product.

Essentially, the superiority of the product was as a positive by-product for the GNU/Free Software movement that upheld its ideals of freedom, whereas for Torvalds and the Open Sourcers, the superiority of the product was itself the goal.

In the case of operating systems, both sides can have their cake and eat it too. No one has to sacrifice any principals to get what they want. Would one have happened without the other? Are they two sides of the same coin?

The last third of the interview puts everything in a much larger persepective that minimizes the the differences between Free vs. Open Source ideologies relative to their similarities. Both are fighting proprietariness, encoded in the large machinery of patent laws and governement regulations. An analysis of Linux in 2004 showed that it violates 283 different US software patents. The US outlawed a free software program called DECSS that plays DVDs, and is pressuring other countries to do the same. And then there's "treacherous computing", or "trusted computing", depending on which side you are on. Apparently, the XBox produced by Microsoft (and now replaced by the XBox 360) is a mini-example: it prevents users from installing any software without Microsoft authorization. Stallman paints a pretty grim picture:

The technical idea underlying treacherous computing is that the computer includes a digital encryption and signature device, and the keys are kept secret from you. Proprietary programs will use this device to control which other programs you can run, which documents or data you can access, and what programs you can pass them to. These programs will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If you don't allow your computer to obtain the new rules periodically from the Internet, some capabilities will automatically cease to function.

Programs that use treacherous computing will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If Microsoft, or the US government, does not like what you said in a document you wrote, they could post new instructions telling all computers to refuse to let anyone read that document. Each computer would obey when it downloads the new instructions. Your writing would be subject to 1984-style retroactive erasure. You might be unable to read it yourself.


Is this a real possibility? Will a free hardware movement led by hardware engineers become necessary to sustain free/open software? Or, at the end of the day, will superiority of the product be the ultimate decidor?

Disclaimer: this post was written while booted in Windows.

Sunday, 14 June 2009

An outfoxing wolverine

Another excerpt from Nunaga:

Another time a smart wolverine had the best of us. Nasarlulik, another Eskimo called Qurvik and I had killed some caribou, but couldn't get all the meat in our canoe to take back to our post. We decided to cache what was left. We skinned them out and put them on the ground, and gathered up a great pile of rocks to cover the carcasses. After the carcasses were well covered, we took a tea-pail and scooped up water, sloshing it all over the cache. Each pail of water froze, binding the rocks like cement. We were making certain that no wolves would get our caribou before we could return for it ourselves. The cache was frozen solid.

When we eventually got back to pick up that meat, we discovered that a clever wolverine had found a way to outwit us. Unable to tear the frozen rocks away, the cunning beast had lain on top of one rock until its body heat had melted the ice around it; it then plucked the rock out and did the same thing with the next rock, until it was able to pull enough rocks away to get at the caribou.

Wolverine linguistic roots

I'm in the mood for wolverines today. Here is a multi-lingual examination from wikipedia:

The wolverine's questionable reputation as an insatiable glutton (reflected in the Latin genus name Gulo) may be in part due to a false etymology. The animal's name in old Swedish, Fjellfräs, meaning "fjell (mountain) cat," worked its way into German as Vielfraß, which means roughly "devours much." Its name in other West Germanic languages is similar (e.g. Dutch Veelvraat).

The Finnish name is Ahma, derived from ahmatti, which is translated as "glutton." The Russian росомаха (rosomakha) and the Polish and Czech name rosomak, seem to be borrowed from the Finnish rasva-maha (fat belly). Similarly, the Hungarian name is rozsomák or torkosborz which means gluttonous badger.

Purported gluttony is reflected in neither English nor Germanic Scandinavian languages. The English word wolverine (alteration of the earlier form wolvering of uncertain origin) probably implies 'a little wolf'. The name in Old Norse, Jarfr, lives on in the regular Icelandic name jarfi, regular Norwegian name jerv, regular Swedish name järv and regular Danish name jærv.

Outfoxing the wolverine

Excerpt from Nunaga, by Duncan Pryde, a book about a Scotsman's life with Eskimos in the Canadian Arctic.

One day Palvik and I were checking traps along a trapline we were running together down the south coast of Kent Peninusla, north and east of Baychimo Harbour, and we discovered that a wolverine was working our line. This wolverine had followed the sled tracks we had made on our frist run down the line, and many traps we checked had been dug up by the sly spoiler and either srpung or exposed. In some cases we would find scraps of a fox in the trap to show that the wolverine had beat us us to the prize. A wolverine often seems to work a trapline not out of hunger, but just for fun. Sometimes it will simply take the fox out of the trap, drag it off thirty yards and bury it. Normally, however, it chews it up enough to ruin the pelt. A single wolverine could reduce our take of fur considerably.

But we had a few tricks of our own. We went back to our base camp for an old sawn-off shotgun Palvik had used before on wolverines. Back at the trapline, we dug a little pit in the snow near one of the traps that the wolverine had not yet visited, and buried the gun in the snow so that about two inches of the muzzle stuck out. Then we attached a string to the trigger of the shotgun and to a chunk of raw caribou meat, which we thawed out long enough to wrap around the mouth of the shotgun, where it froze tight. When we came back on our reverse trip down the trapline, we had our wolverine, minus its head.

Thursday, 28 May 2009

How to brainstorm effectively?

A few weeks ago, I took part in a brainstorming session (or talkoot in Suomi) on resting-state networks. The gathering was of academics from Finland at various levels of seniority.

Now, I am just back from a brainstorming session organized by Nokia Research. The group consisted of predominantly NRC engineers, designers, and a few outsiders. Since my lips are sealed by the IPR police, I am not at liberty to tell you what it was about. However, I was paying attention to the creative-argumentative process of each and every participant.

Obviously, the sessions were very different in character, participants, participation, format of discussion, and goals. However, let me attempt to take away some universals, and propose some recommendations on how to brainstorm effectively. Obviously, my impressions are fresh, superficial and open to critique.

How to brainstorm effectively

1. Agree in the first 5 minutes on:
a) What you are talking about
b) What you expect the discussion to lead to

2. Spend the next 5-10 minutes on defining the keywords. Usually, in an "interdisciplinary" (the bunny ears have a deep meaning) setting, for each participant, each keyword has a different set of association-keywords (keywords that are triggered by said keyword). If possible, go around the room once and ask people to suggest a few association-keywords. Organize them into a venn diagram if necessary, with each set representing a single participant or their background. If appropriate, brainstorm a tagline (in the advertising, or elevator-pitch sense: the key idea in 5 words or less) consisting of these keywords. Mutliple taglines representing multiple views of the idea enrich the ensuing discussion.

3. Be aware of
a) bounded rationality (there is not enough time and capacity to examine ALL the facts and derive opinions from first principles)
b) bounded comprehension (you may have to repeat yourself in different words, a different style, or pause to explain keywords)
c) bounded empathy (do not expect each participant to agree with a personal opinion dear to you, such as: come on, let's face it, X is bullshit, right?)

4. As an orchestrator, maintain a sense of balance between
a) obviously contradictory viewpoints due to prior biases of participants (an effective strategy to deal with this is what I'd like to call continuum mapping [1]).
b) the need to not idea-kill (let all flowers bloom) and the need to be precise (about definitions, goals of the session etc.).
c) creativity (btw, it strikes me that this can be applied to XYZ) vs. focus (is this strictly relevant?).

5. Accept beforehand, and expect that your stand on an issue may be contradicted, modified, fleshed out etc.

6. At the end of the session (or even through the session), go back and revise keywords, definitions, venn diagrams and taglines. These can finally be wrapped up cutely, as a take home message.

Any other points?

[1] Continuum mapping (own coinage, open for revision) is a technique that may be used by an arbitrator during a debate, or conflict resolution when parties or people explicitly, and diametrically disagree. The arbitrator simply maps each (polemic) viewpoint at two ends of a continuum, and opens the house for examples/suggestions/parameters/viewpoints that fit somewhere in between the continuum, thus defusing the tension. Continuum mapping may be used to visualize various trade-offs and cost-benefit charts.