In my recent post about design patterns, I more or less inadvertedly touched upon the general topic of how we analyze and understand problems. I postulated the theory that we come to understand the nature of big, complex problems, by subdividing the whole into parts that match solutions we already know from experience. To recapitulate, the interesting part here is that we don’t seem to break the big problem into smaller problems. In this post, I’d like to go back to the topic of understanding problems, because recent events have given me a different angle on it.
About a year ago, my friend Norman was writing his magister artium thesis in german linguistics. The topic was whether Georg Kaiser1, a relatively modern playwright who incorporated the story about Tristan and Iseult into his play König Hahnrei2 knew and drew upon the far older text by Gottfried von Straßburg. Kaiser did not have to know Gottfried’s version, because the story around the two lovers has been told and retold countless times.
Either way, Norman had to dig deep into two long texts, several other medieval versions of the story, and stacks of secondary literature – in other words, he had to intimately understand a topic too large to understand well enough even to break down into parts he could handle.
I was reminded of that just now, because I have just finished documenting an incredibly complex piece of code, which (due to some interruptions) took me weeks to understand and unravel. I’m not trying to claim here that the scale of what I was doing was the same or even close to Norman’s thesis, but we shared one thing in our respective works: sheer and utter frustration, because the problem was too large to grasp. Understanding slipped away, however hard I tried, I just couldn’t wrap my brain around what I was reading.
![[FSF Associate Member]](/images/fsf_4971.png){kind=small}
![[frdm] Support SFLC](/images/support-sflc.png "Software Freedom Law Center"){kind=small}
