Archive | November, 2012

Better reading / On deadlines and poverty

15 Nov

I have started the second month of my “being a better scientist” project. This month I will focus on better reading. My goals are:

1. Read more random stuff
2. Read more relevant stuff
3. Annotate what I read
4. Switch from Endnote to Mendeley

Reading random stuff

Yesterday, I started with reading more random stuff. Random stuff means papers that are not directly relevant to my research. Since a few months I have a print subscription to Science magazine (for just $50 for a year!). So now I can sit on the couch at home and read articles which are interesting, and entirely irrelevant to my work.

Following a tip I read somewhere (likely in David Allen’s “Getting things done”), I flipped through the magazine and cut out the stuff I wanted to read. Then I quickly threw away the rest of the magazine. This is important and I should make sure I really do it because piles of half-read Science issues make me feel quilty. Yesterday, I cut out an article about malaria, something about selective sweeps, a perspective about speciation and an article about the mindset of poor people.

The last one, about poverty, is clearly furthest away from my own work. But it turned out to be relevant to the “being a better scientist project!” The paper describes how people behave when they play certain games, just like in many experimental economics papers. In this case the players were made “rich” or “poor” (by giving them few or many tries to complete a task) and the researchers tried to find out how being “poor” changed how people played. They found that “poor” players sometimes did stupid things. For example, if the game allowed them, they would borrow tries (e.g., they can try to guess a word X times) from the next round, even if they knew they had to pay a high interest (they loose two tries in the future for each extra try they use now). “Poor” players who were allowed to borrow ended up with lower scores than “poor” players who were not allowed to borrow. This was not true for “rich” players.

The researchers conclude that people who are faced with scarcity will focus on solving the task that is most urgent and ignore future problems.

What I find absolutely brilliant of this study is that, in a second experiment, they compared being poor with being busy. They created “busy” players by giving them much less time to play each round of the game. And they found that “busy” players made the same mistakes as “poor” players. The “busy” players borrowed time, even though it didn’t lead to higher scores.

Poor similar to busy?

Comparing busy with poor is very cool. First of all because they can show that scarcity of time and money has a similar effects – it makes that we stop thinking about the future. It is also brilliant because it connects the busy and the poor in a deep way. If you are a politician, for example, or a scientist, you may have never felt poverty, or you may not remember how it felt. But most certainly you know how it feels to be busy. The Science paper tells us that what happens to us when we are very busy (we ignore emails, forget to back-up our computer, work too many hours and eat unhealthy food) is very similar to what happens to the poor when they have no money to pay the rent. In both cases, we focus too much on the issues that play now and ignore how our actions affect the future. In one case this may lead to borrowing money, and in the other case to forgoing sleep. The consequences will be felt the next month or the next day.

One thing I should mention is that the “poor” in the game made better use of their few tries, than “the rich”. So scarcity also has a positive effect.

What can we learn from this? Deadlines are good, the scarcity of time probably makes us perform somewhat better. But we shouldn’t borrow time from the future by ignoring other tasks or by not getting enough sleep. It tells me that my “no work after 8pm” rule is scientifically sound!



Update on my programming resolutions – fighting lazyness

6 Nov

A few weeks ago I started a project of “being a better scientist.” I made general resolutions, which I plan to keep for a long time, and resolutions related to programming, on which I wanted focus for a month. I am pretty happy with how I stick to the general ones, but the programming-related resolutions turn out to be challenging.

1. Learn python by finishing Udacity‘s python course.
I planned to finish my Udactity CS101 course and this is almost done. I already started working on the exam questions. The last units  with technical content (5 and 6) were great fun, and I learned about hash tables, the page-rank algorithm and recursive functions.

2. Look it up, write it down.
I decided to make an effort to look things up and write them down. For example, I often get Excel files from collaborators and I used to open such files in OpenOffice and save them as .csv files before importing the contents in R. But this is somewhat time-consuming (OpenOffice takes forever to start) and generally annoying to do. Plus, there is a risk that, one day, I may get a new version of the Excel file and forget to convert it to .csv. So this month I made an effort to find out how to read Excel files directly into R. It was not very hard, and it will save time in the future. I also added two lines of annotation to my R script.

#load library to be able to read xls excel files
#usage: to read first sheet of xls file: DataFromExcel <- read.xlsx(“test.xlsx”, 1)

So, all seems fine. But why I didn’t do this years ago? It’s not as if I just started using R or reading Excel files.

I am not sure, but I fear it is just lazyness. I need to remind myself all the time to keep learning new things – even if they are small and uninteresting like how to read an Excel file (and how to type a dash in stead of a hyphen – I learned that too this week!). To help myself, I started using Joe’s Goals. This website helps you stick to your resolutions. For me, the site helps, at least for now. I am not yet convinced that it will still work in two months’ time, but I will give it a try!

3. Annotate, annotate, annotate.
My third resolution was to do a better job annotating my code. But, wow, this is hard. I haven’t even started looking into things like Doxygen to do serious annotation. I first wanted to think about what I need to record to be able to understand what I coded two months or two years ago. This turns out to be harder than I thought. But this blog entry is already getting long. Later this week I will write about lines and lines of unannotated code, variable names that have no meaning, filenames that have no meaning, or twenty files in a folder and I don’t remember how they are related. Any tips on how to avoid these things are very welcome!