There are a few books that I like to reread especially when I need to recharge my motivation. One of these books is “Behind Deep Blue” by Feng-Hsiung Hsu. It is a well-written story about a small team who, as the subtitle says, built ‘the computer that defeated the World Chess Champion’, aka Gary Kasparov. Despite the technical implications in the title, a person moderately familiar with chess and computers would not have any problems following the story. The few geeky parts, scattered here and there, can be skimmed in favor of what really stands out, the human narrative.

The fateful night and soul-searching described in Chapter 3 is one of my favorites. Hsu finds himself at a cross-roads, and only hesitates for a bit before committing to the task at hand. One of the reaffirmed lessons for me is the need to identify the root of confusion and doubt before one could proceed into effective paths. Hsu found the 64-chip design odd even from the beginning, but for various reasons he did not think about alternative solutions. Until he was asked to help out, and he started to look deeper into the technical issues, and then that fateful night of introspection, … and the rest is history, or more precisely, a 12-year endeavor by dedicated individuals.

I really don’t want to give a long book review or spoil the story. Let me just say that there are many lessons in Deep Blue that I find relevant to my own pursuits. Dedication to a task is one of them. Not the ‘blind’ variety, but dedication that springs from the process of working through doubts and the careful assessment of one’s capabilities and limitations. It’s been seven years since I first took the time to really reflect on recurring questions; six years since I decided that yes, I could do something about these questions and started to search for potential paths; four years since I committed to training towards a technical role as warranted by my natural inclinations; and now I’m again purposely moving out of my comfort zone towards unfamiliar territory. Who knows if anything will come out of my projects, but it’s all worth it as I really enjoy the self-imposed challenges.

 

I have been thinking a bit on two system approaches to handling messiness: one that is oriented towards mess ‘prevention’, and another that is more tolerant of messiness but instead prioritizes sense-making. Of course, it is possible to spend effort on both fronts when designing and implementing a system. But sometimes a compromise has to be made and one approach has to prevail on the other.

This thought process was seeded through recent experiences at work and also by points raised in online discussions that I follow. After boiling down the issues to what I perceived is a root cause of many misunderstandings, I realized just how much I prioritize sense-making over mess-prevention. Don’t get me wrong, I really value mess prevention and a good system or process design should set well-defined boundaries. However, if I could think of an efficient way to make sense of existing or future mess, I would gradually lose ‘faith’ in the need for mess-prevention efforts.

For example, my preference for sense-making leads to heightened interest towards natural language processing instead of required semantic mark-ups. I admit that I routinely use structured data formats, such as found in JSON/XML specifications or implied in relational database systems, so I don’t think I under-appreciate the importance of mess-prevention. However, where there are no systems or specifications in place, I am more open to considering lightweight systems with minimal requirements. Similarly, I like dynamically-typed programming languages and search engines that attempt to make sense of whatever and however I write.

There is just too much to lose when requirements are over-specified too early. In a research environment such as where I work, I think the tools chosen should be more naturally inclined towards sense-making rather than mess prevention. Enforcing manual code versioning steps is simply inappropriate especially when there is an opportunity to automate routine commands, such as creating hooks in git or mercurial. Time spent complying with strict standards would be better spent conducting actual research. A tool that has a good balance of tolerance for messiness and built-in capabilities for sense-making should be preferred over another that requires strict enforcement.

It’s sad that I have not been given an opportunity to explain all of the above where I work. But at least I have my personal projects where I could express the approach that I prefer and blogs to demonstrate what I mean.

 

Perhaps it was inevitable, but here I am starting another blog. I have alluded to making this move in another blog, in order to clean up and reorganize my accumulating accounts of ideas, demos, and white/gray papers. I had to overcome a lot of hesitation extending over a year to convince myself this move is really necessary.

But the time has come and I’m ready for it.

This personal blog will relay experiences and opinions beyond my project-oriented blogs. It was getting harder to filter out indirectly related observations from my posts in satconomy.org, and that’s why that blog has laid dormant for over a year now. I still think that inspirational quotes and observations have their place in a blog such as satconomy.org, but I felt like the blog was losing focus. I felt the same with tyaga.org, sometimes wondering which blog to post recent observations in, since the main purpose for each blog was getting blurry.

The main problem is that I did not have a personal blog as a default ‘outlet’. When in doubt, I will post here rather than my other blogs. I plan to make this my most active blog, which to me might mean a post once a month. The project blogs will have maybe two to four posts a year. I will discontinue a project blog once I feel that it has served its purpose. In that connection, I will update and clarify the About pages in my other blogs.

I hope you’ll follow this blog and enjoy reading it.

© 2012 edgarsioson.com Suffusion theme by Sayontan Sinha