Category: sense-making

Merged Blogs

It was getting obvious that I could not actively maintain three blogs – tyaga.org, satconomy.org, and edgarsioson.com. Maybe I was thinking that establishing a new blog would reinvigorate my motivation to post more frequently. But it was just wishful thinking. It is very easy to get used to not blogging if I’m really busy at work, writing up a paper, or traveling.

I had resisted the urge to establish another site for more than a year, but finally did it early this year out of the compelling need to better organize my thoughts and message. I also don’t like the situation of feeling stuck and felt compelled to make a decision as needed to get out of a rut.  But three blogs was too ambitious and even silly. The main thing now is to use categories (duh!) and let readers choose whatever topics they want to read. So, I merged the three blogs here, adopted the most up-to-date theme to suit my purpose, and recategorized my posts as needed.

One of the lessons learned ties up quite well with my preferred approach on ‘handling messiness’. Having three blogs to segregate my thoughts in three smaller and neater piles seemed like a good idea, but my tendency is really to let machines organize things as much as possible. I don’t want to log on to three different admin panels and figure out first where I want to post. That’s too much work just to get started. It’s much better to just start writing a post and categorize when the thought has been laid out for review.

I still think that having a personal site was and is a good idea. Only now, the self-titled site will just have mostly static content with links to my various projects and interests. With the merged blogs, there is a risk of turning off tyaga.org readers who are just interested in technical ideas and updates. However, the upside is that readers could get a more holistic picture of me. There will be more transparency and better likelihood of detecting bias in my writings. I’m hoping that amid the mixed bag of topics, the increased transparency will lead to better understanding overall.

 

Handling Messiness

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.