Is there a problem here?

Solving a problem that you know has a solution may require knowledge, but it is knowledge that already exists. Unfortunately – or, if you prefer, fortunately – many of the problems that are worth solving, that need to be solved, don’t come with that level of certainty.

In his book, How Life Imitates Chess (which, by the way, I highly recommend), Garry Kasparov has this to say about uncertainty:

Knowing a solution is at hand is a huge advantage; it’s like not having a “none of the above” option. Anyone with reasonable competence and adequate resources can solve a puzzle when it is presented as something to be solved. We can skip the subtle evaluations and move directly to plugging in possible solutions until we hit upon a promising one. Uncertainty is far more challenging. Instead of immediately looking for solutions to the crisis, we have to maintain a constant state of asking, “Is there a crisis* forming?”

 

Safe? No. Awesome? YES! My review of Strange Loop 2010

When I first learned about the Strange Loop developers conference here in St. Louis, I had a strong – you might say strange – urge to attend. Strange because I am not a software developer; it’s been a long time since I’ve done any serious coding. What caught my eye was how conference organizer Alex Miller (@puredanger) tied the ideas of one of my favorite books of recent years, Douglas Hofstadter’s I Am a Strange Loop, to The Loop here in St. Louis and the idea of building an identity for St. Louis based developers.

More importantly, at least for me, it was not a conference focused on any one topic or language, but was like a survey course of the latest and greatest in many areas of development theory and practice. Here’s a quick summary of some of the sessions I attended at Strange Loop 2010:

Semantic Web

The first non-keynote talk I attended, Brian Sletten’s (@bsletten) talk Semantic Web: Hot or Not? looked at big-S Semantic Web, providing a bit of history about how it has failed to catch on in the past and why he thinks that its time has come. In case you are wondering, Brian voted for “hot”.

Towards the end of the second day, Scott Davis (@scottdavis99) presented Hidden Web Services: Microformats and the Semantic Web, a look at what I would call small-s semantic web. Using some (not always cooperative) live examples along with his presentation slides, Scott showed RDFa and microformats in action.

Of all the talks, these two provided me the most practical information that I can make use of. As soon as I finish this review (and catch up on a couple of other things I need to blog), I will be diving into RDFa and microformats and seeing how I can put them to use on this blog and a couple of other sites with which I’m involved.

Complexity Theory

Readers of this blog know that complexity is an idea that is never very far back in my thoughts, so I obviously made the time to attend Tim Berglund’s (@tlberglund) talk Complexity Theory and Software Development. He covered a lot of ground that I’m familiar with, but also gave me many new things to think about. And a couple of new ways to look at things.

Not taking anything away from any of the other presenters, Tim was one of the best presenters I had the pleasure of seeing. He was in one of the “small” rooms, but the quality of both the content and the presentation would have made this talk well suited to the main room at the Pageant.

NoSQL

When I saw the NoSQL track on the Strange Loop schedule, I assumed that this was a specific database implementation, along the lines of mySQL. (I told you it’s been a while….). Over the course of the two days, I came to understand the concepts of NoSQL and how these concepts can be, and are, being used.

Eben Hewitt’s (@ebenhewitt) talk Adopting Apache Cassandra provided me with a nice theoretical understanding that would serve me well through later talks, and Kevin Weil’s (@kevinweil) provided some lessons in implementation in his talk NoSQL at Twitter. The engineer in me really enjoyed Kevin’s frank discussion of the challenges and solutions – some successful and some not – as Twitter addressed the challenges presented by huge data sets.

Android

Next to the semantic web discussions, Ted Neward’s (@tedneward) talk Busy Java Developer’s Guide to Android: Basics provided me the most practical value. My Droid gives me a reason – and opportunity – to use Android as a platform to get back into some development (however small scale it may be), and this talk gave me enough to get started. A quick overview of the SDK, some talk about the NDK, and then some runthroughs of ideas were great. Ted also had a wealth of knowledge which he freely shared during the extended Q&A that the session eventually turned into.

It’s tough to say which talk was my favorite, but if you pushed me to choose I would have to go with Android Squared from Bob Lee (@crazybob) and Eric Burke (@burke_eric) from Square.  The talk focused on the engineering and software challenges related to using the Square in the mic port of an Android phone, including some detailed waveform and signal analysis and some tricks to deal with the wide variety of Android implementations out there. (It didn’t hurt that they handed out some hardware at the end of their talk.)

Bob and Eric took turns talking about specific aspects of the challenges and the solutions. Like Kevin Weil, they held no punches in terms of talking about successes and failures along the way. They not only showed the final product, but provided some great insights into the process of figuring things out.

There are a couple of talks I attended but haven’t mentioned, and then their are the keynotes and the panel discussions that were worth the price of admission (a low $190) all on their own. I’ll try to get back to those, and maybe even the above talks, in more detail over the coming weeks.

Summary (of my already too long summary)

At the top of Alex Miller’s favorites list on Twitter is this tweet from Jeff Atwood (@codinghorror):

“it’s better to be safe than sorry” is such crap. You know what’s better than being safe? Being AWESOME.

Alex most definitely didn’t take a “safe” path when he put together Strange Loop. The venue was spread across three venues, including a club typically used for concerts, the hotel next door, and a couple of rooms from the Regional Arts Commission across the street. Some of the rooms got overcrowded, and there was a general dissatisfaction with the wi-fi availability. And then there is the cross-discipline (cross-language?) nature of the conference, which may not have provided the depth that some wanted but made up for it with breadth.

I can’t speak for Alex and whether or not he is sorry about any of it, but I can say that he – and his cadre of assistants and volunteers – definitely hit awesome.

I’m already looking forward to next year.

For knowledge workers, solving problems is the easy part

I read – and highly recommend – Garry Kasparov’s book How Life Imitates Chess a couple of years ago, and am thinking I should pick it back up again. If not to read in its entirety, then at least to skim through my dog-ears and margin notes. There are a lot of good insights into the nature of work today, especially what we call knowledge-work.

For example, Jack Vinson’s (@jackvinson) recent post Some qualities of a knowledge worker reminded me of the following excerpt:

Knowing a solution is at hand is a huge advantage; it’s like not having a “none of the above” option. Anyone with reasonable competence and adequate resources can solve a puzzle when it is presented as something to be solved. We can skip the subtle evaluations and move directly to plugging in possible solutions until we hit upon a promising one. Uncertainty is far more challenging. Instead of immediately looking for solutions to the crisis, we have to maintain a constant state of asking, “Is there a crisis* forming?”

Solving a puzzle that you know has a solution may require knowledge, but it is knowledge that already exists. Figuring out if there is a solution to a problem, or even if there is a problem at all, requires the manipulation of existing knowledge, the gathering of new knowledge / information, and the creation of something new.

This is when knowledge work becomes art.

Autism and “I”

Since I signed up today for the Strange Loop software developer conference here in St. Louis, it seemed fitting to repost this article, originally published on my autism blog nearly three years ago.
– – — — —– ——–

Earlier this summer [2007] I read Douglas Hofstadter’s new book, I Am a Strange Loop. As Hofstadter mentions early in the book, a more appropriate title would have been “I” is a Strange Loop; the book is about the nature of consciousness, that elusive concept of “I”, and not an autobiographical work as the actual name of the book suggests.

Hofstadter’s works have been among my favorites since I read his first book, Godel Escher Bach: An Eternal Golden Braid, in high school. The new book is, in fact, an updating of the ideas he first expressed in GEB. I have long hoped that he might address issues of the mind and consciousness in terms of atypical minds (such as autism), but aside from some passing discussion of those minds, I Am a Strange Loop does not provide any real insight into how the concept of “I” fits with autism.

On Monday, I was pleased to find a paper that specifically addresses the question of autism and “I”, Self-Referential Cognition and Empathy in Autism, co-authored by Michael V. Lombardo, Jennifer L. Barnes, Sally J. Wheelwright, and Simon Baron-Cohen. From the paper’s abstract:

Background. Individuals with autism spectrum conditions (ASC) have profound impairments in the interpersonal social domain, but it is unclear if individuals with ASC also have impairments in the intrapersonal self-referential domain. We aimed to evaluate across several well validated measures in both domains, whether both self-referential cognition and empathy are impaired in ASC and whether these two domains are related to each other.

Conclusions/Significance. We conclude that individuals with ASC have broad impairments in both self-referential cognition and empathy. These two domains are also intrinsically linked and support predictions made by simulation theory. Our results also highlight a specific dysfunction in ASC within cortical midlines structures of the brain such as the medial prefrontal cortex.

Instead of looking at autism as a syndrome of self-focus (the Kanner approach), the paper starts from the concept of “absent-self” put forth by Uta Frith in her book Autism: Explaining the Enigma. I had not heard of Frith before reading this paper, so I can’t really comment on her ideas. But the paper itself seems to make sense. I’m still going through it, trying to understand all that they are studying and what their results mean. (I did learn a new word:alexithymia – difficulty identifying and describing one’s own emotions.)

My first time through I Am a Strange Loop was to soak in the big concepts. I typically wait a few months before re-reading something like this so I can get into the details, but I think I’ll start again sooner than that. (At the moment, I’m reading Steven Pinker’s latest book The Stuff of Thought.) Now that I have a bit more information about autism and “I”, I’ll have a better context for processing what I read.

Another interesting note about the paper, it was originally published by the Public Library of Science under a Creative Commons license. The PLoS home page describes it as a “A new way of communicating peer-reviewed science and medicine”, so I will assume the paper has been appropriately peer reviewed. But I think I will do a bit more checking just to be sure. (Of course, any insight from readers here would be greatly appreciated.)

——– —– — — – –
Chances are very good that I will re-read I Am a Strange Loop again before Strange Loop; curious to see what I get from it this time.

Does your organization need a neurologist?

When addressing the idea of tacit knowledge in respect to knowledge management, most descriptions focus on the tacit knowledge IN organizations – that is, the tacit knowledge of the individual members of the organization – and how to capture and share that tacit knowledge. While I believe it is important to understand this tacit knowledge, I’ve always been more attracted to an understanding of the tacit knowledge OF an organization, what it is the organization as a whole ‘knows.’

As with individuals, organizations operate based on the tacit knowledge they possess and their ability to act on that knowledge when needed. In the human brain it is the connections between neurons – and the ability of the brain to reorganize those connections to meet the situation – that makes up the intelligence and tacit knowledge of the individual. In organizations, it is the connections between people. (see this post of mine from 2006 for a bit more on this.)

Many years ago, in one of my first ever blog posts, I wrote that “KM is the neuroscience of an organization.” After reading Is Enterprise 2.0 the neuro-organization? a couple of days ago, and a brief discussion with Harold Jarche (@hjarche), I was once again curious.

Here’s a start. (Definitions from Wikipedia)

Neurology: a medical specialty dealing with disorders of the nervous system. Specifically, it deals with the diagnosis and treatment of all categories of disease involving the central, peripheral, and autonomic nervous systems, including their coverings, blood vessels, and all effector tissue, such as muscle.  –>OD ?

Neuroscience: the scientific study of the nervous system, the scope of neuroscience has broadened to include different approaches used to study the molecular, developmental, structural, functional, evolutionary, computational, and medical aspects of the nervous system. –> KM?  IT?

Psychology: the scientific study of human or animal mental functions and behaviors, psychologists attempt to understand the role of mental functions in individual and social behavior, while also exploring underlying physiological and neurological processes.  –> OD? Training/Learning?

Psychiatry: the medical specialty devoted to the study and treatment of mental disorders—which include various affective, behavioural, cognitive and perceptual disorders; mental disorders are currently conceptualized as disorders of brain circuits likely caused by developmental processes shaped by a complex interplay of genetics and experience.  –> HR?

Way off base? On the right track?

What we need are knowledge curators, not managers

The concept of “knowledge curator” has been creeping slowly from the back of my mind to the front over the past couple of years, and received a couple of jolts over the weekend that resulted in one of those elusive “aha moments”.

What we need are curators of knowledge,
not managers of knowledge.

First, I noticed the blurb “curated content from Flickr” when I used the Flickr module on a Squidoo lens.

Second was a quote from Liz Danzico (that I found via Signal vs. Noise blog).

A portfolio of work is a curated experience. … but oftentimes, a portfolio only contains final pieces, as applicants are overly concerned about presenting perfection. Polish doesn’t communicate process though, and therefore I’m left with only part of the story. Messy problems — and how applicants work through them — can show a great deal more in a portfolio than one finished, airtight solution.

I didn’t know it at the time,but this all started back in November 2005 with an article titled Technology makes it easy to ‘remember,’ the trick is learning how to forget, in which I wrote:

My early days in Knowledge Management included a lot of time developing, deploying, and getting people to use “knowledge repositories.” (At least trying to get people to use them.) … I finally realized one day that the problem has become not, “How do we remember all this knowledge that we’ve learned?” but rather, “How do we forget all this knowledge we’ve accumulated that we no longer need so we can focus on what we do need?”

I also noted a quote from the book The Trouble with Tom by Paul Collins related to the need to “eliminate” memories:

Memory is a toxin, and its overretention – the constant replaying of the past – is the hallmark of stress disorders and clinical depression. The elimination of memory is a bodily function, like the elimination of urine. Stop urinating and you have renal failure: stop forgetting and you go mad.

It was this latter quote that was in my mind last summer when, in The importance of forgetting,  I wrote about John Medina’s thoughts on the question of memory and forgetting in Brain Rules:

The last step in declarative processing is forgetting. The reason forgetting plays a vital role in our ability to function is deceptively simple. Forgetting allows us to prioritize events. Those events that are irrelevant to our survival will take up wasteful cognitive space if we assign them the same priority as events critical to our survival.

As I noted then, this is no less true in the organizational context of knowledge/concept work.

Simply capturing everything in document repositories and best practices, without the ability to forget – or supercede – any of it, takes up a lot of “cognitive space” that organizations could be putting to other wise good use.

The trick is figuring out how to forget, and how to figure out what to forget.

A checklist for checklists

It’s easy to say, “Make a checklist for your complex process and use it”. It’s another thing altogether to actually make a checklist that is good and that works.

One of the things that I like most about The Checklist Manifesto is that it recognizes and addresses the challenges inherent in designing a good checklist. In fact, a good part of the story revolves around making the WHO surgical checklist a good one. In the acknowledgements section of the book, Gawande credits Boeing engineer Dan Boorman (who is also mentioned in the book) as an “essential partner” in the ongoing development of new checklists, and from the looks of it they’ve been hard at work.

Most relevant to my ongoing thread here is the Checklist for Checklists, pictured below. If you have decided that checklists can help you, this is an excellent place to start as you begin the process of developing your checklists.