Self management &mdash part 1

I'm going to Croatia. I'll be driving at least 8 hours. The other half of the way my father will be the driver. If I let him drive. I didn't decide yet. Driving is a hobby of mine and it is a hobby that was neglected for the past 2 years, since I started the PhD. I like both to be able to give passengers a smooth ride and to be able to drive as in a rally, but mostly the former. I guess it's the age. I remember that I used to drive fast quite often after I got my license. And when I say fast I mean to the limit. For example tires screeched at almost all curves. I had no accident while driving fast. Once I scratched the car. Apart from that I had no accident that was my fault. Once a guy reversed into my car while I was not moving. Lesson: Never assume you are being seen no matter as crazy the alternative seems. Another time I was driving straight ahead on the main road and a guy that was turning left hit the back of my car. I guess he was in a hurry or he thought I'm driving faster. Both these incidents resulted only in broken bumpers. Those are all the incidents involving contacts between my car and other cars in the last 9 years.

What does this mean? The article Culpable versus non-culpable traffic accidents; What is wrong with this picture? by Wålberg and Dorn from the Journal of Safety Research 2007 gives some figures. According to their data Swedish bus drivers have one accident every 4961 hours, while British bus drivers have one every 1518 hours. I drove probably about 50 hours in the last two years. Before that I would guess I averaged about one hour per day. That sums up to about 2600 hours of driving. That is, I have one accident every 867 hours of driving. Which means I suck. I could make it look better by pointing fingers or by saying when I had the last accident. But it's probably better if I get the message and try to improve.

Which brings me to the subject of this post. I believe that there are a few important ingredients that help improve a skill:

• you should know that there is plenty of room for improvement,
• you should be confident that you can improve,
• you should continuously monitor your progress, and
• you should establish (attainable and objective) next targets.

I now know that there is plenty of room for improvement: I know that, at least by one measure, Swedish bus drivers are 5.7 times better than me. Confidence that I can improve was never a problem of mine. Maybe I'm overconfident sometimes. But I know that for others it can be a problem. The next step is to monitor my progress. One thing to monitor is how many hours I drive. The next big target for me is to drive 1954 hours without any crash. That will make me as good as an average British bus driver. Notice that I said big. To keep me motivated I need to find smaller targets. I used to have a small piece of paper on me with a list of five things I want to improve. That list should evolve. But what I already have is a good starting point. It's fun to look back now. Here is the list:

1. Don't change gears while steering.
2. Use the horn to make yourself seen, not to `yell' at others.
3. ALWAYS know what happens behind you before steering or braking.
4. Be careful at traffic signs.
5. Always have clean windows and mirrors.

Nowadays I would say that I seldom change gears while steering. I virtually never use the horn to `yell' at others so I can erase this one. It's annoying to realize that sometimes I still brake without looking in the mirror. My perception of traffic signs is now much better, but the main reason I do not overlook them is probably that I no longer have a standard route. Years ago, habit was the main reason why I missed (changed) traffic signs. I did not improve at all when it comes to windows and mirrors. Still, I absolutely hate things put in the car that hinder visibility.

Unfortunately, I don't expect to improve much in the next two years because the probability that I'll get a car while being a PhD student is 0. This is a dilemma for me.

Now let's see how the same schema applies (or not) to another skill, say, programming.

The first step is to know that there is plenty of room for improvement. There is. The TopCoder ratings show that I suck at solving Aha! problems and at finding good heuristics. The rating for developing well-documented and robust programs comes from only one participation so it is not reliable. But it is says I suck. Another area where I suck is familiarity with contemporary technologies. Since I suck at so many things I need to prioritize. I'm pretty sure I do not want to improve my knowledge of contemporary technologies. On one hand they come and go fast, so at this stage in my life (PhD) it would be an effort badly spent. On the other hand I tend to associate technology with stupid people. I know this is not true but I just can't help it. I've heard the `school doesn't teach modern technologies and you have to learn by yourself' excuse so many times that I feel like running and yelling whenever someone repeats it. (Learn by yourself as opposed to what? Having someone to stuff the textbooks down your throat? Learning is something that students do, by definition.) Finally, I'm yet to see a “modern technology” that takes more than a day to get started with, and more than a week to become reasonably efficient with it. What remains is the set of three TopCoder categories I mentioned: Aha! problems, heuristics for hard problems, and well-documented and robust programs. (These are known as Algorithms, Marathons, and Component competitions in the TopCoder world.) The trouble is that I can't pick one. All have a certain appeal to me. The only reason I participated in more Algorithm competitions than in Marathon competitions than in Component competitions is that I favored those that take less time. One option would be to focus on Knuth. His books and programs are generally a nice blend, and of very high quality. The nagging problem with this is that he is somewhat conducive to a work style that ignores existent good tools and languages. This is partly on purpose, because he doesn't want to be dependent on technologies that come and go. But it can be annoying sometimes. For example, his CWEB system for literate programming is a strain for most editors (only ViM does proper syntax highlight) and it encourages C-style programming even when C++ has better alternatives (such as defines in C versus constants in C++). To some point this doesn't matter for learning principles but it does tend to form bad habits that kick you when you want to get things done.

For now I want to remain flexible in what I want to become good at. For the short term I want to make good progress in reading TAoCP and in writing good literate programs.

The second step is to be confident. Am I confident? Not really. I feel somewhat threatened by the lack of time and by my slow progress. I want to believe that my slow progress is generated by a lack of focus, but I'm not sure if I do believe it. In short, I need to work on my confidence. A good way to build confidence is to have some set of concrete achievements to which I can look back later on. I'll collect these on my webpage as programs.

The third step is to monitor my progress. The webpage will help. So will my TopCoder rating.

The fourth step is to have some small targets to follow. Here is the list for now.

1. Release a functional FreeBoogie on 1st of October. (I promised one for the end of the summer but somehow I did not work on it for the last two or three months. I don't know how I manage so often to not work on something I promise. It's almost like promising something makes me less likely to do it.)
2. Increase the TopCoder algorithm rating to ≥ 1900 by the end of the year. This should be doable since I've been there. Remember that rating is just a way to measure progress. If I think about the rating before and during a match I usually end up much worse. I should be thinking about the problems.
3. Finish reading chapter 1 of TAoCP by the end of the year. This involves solving all exercises rated ≤ 10 and all those that are starred. For the starred ones, trying for 3 hours and then understanding the suggested solution is acceptable too. I know that there are some exercises that I just can't solve.

OK. So we saw two examples of how to apply this simple improvement strategy: driving and programming. Since I am a PhD candidate it makes sense to apply it to one more skill: doing research.

What is good research? I gave the answer a while back in terms of what a good researcher does: (1) works hard, (2) picks good problems, and (3) presents well the results. I don't need to work harder. I do it quite well (when I'm not on holiday as I am now). Do I pick good problems? I'm not sure. Do I present well the results? No.

Let's go thru the four steps again.

Is there room for improvement? Well, certainly. I am virtually unknown as a researcher. I need to publish more to let people know what I do. I need to interact more at conferences to let people know what I do. I need to give good presentations of what I do: at conferences, in articles, and on this blog. In research the objective measure of success that comes to mind is the h-index. (Sure, that is an imperfect measure. But that can be said about grades in school, TopCoder ratings, number of articles, and virtually any objective measure. The point is that looking at numbers helps one's self-confidence if those numbers improve.) Let's see, what is my h-index? It can't be too high because I have only three articles that I co-authored. Two have no citation and the third has 4. (There is no self-citation involved.) That would make my h-index equal to 1. The very best in Computer Science are somewhere above 60. So yes, there is plenty of room for improvement.

Am I confident? Yes, I am. But I do believe that I have a big problem with focusing on doing work that can be seen and measured as opposed to playing around. I have to drill this into my mind: If I don't communicate it well it's like I didn't do it — it won't benefit anyone. Writing things down may seem as slowing me down, but it should ultimately be beneficial.

Monitor my progress. I will keep track of articles I write on my webpage. I will also make it easy to contribute to FreeBoogie. The reason is that that piece of software is my best chance to become known in my research community if done properly. It's also the best way I see of contributing to the community. It uses my programming skills and gives back a platform for experimenting. At least that's the ideal.

Let's see some targets now.

1. I must write one article every two months.
2. I must improve old articles and build upon them as opposed to keep starting new things.
3. I must turn FreeBoogie into a platform that others will want to use for research.
4. I must give a short presentation of each of the articles I co-author on this blog for a wider audience. In fact I should have in mind a programmer from industry that is not familiar with applied formal methods when I write the posts.

That's it.

I will write a `self management' post only once every three months, roughly. I want this blog to be mainly about technical problems and about research. Nevertheless, a little introspection is good for one's improvement.