Grokking CMS

I’ve come to love the word “grok.” It comes from Robert Heinlein, the science fiction author. He wrote Stranger in a Strange Land back in 1961, and he defined the word “grok” thusly:

Grok means “to understand,” of course, but […] it also means, “to drink” and a hundred other English words, words which we think of as antithetical concepts. ‘Grok’ means all of these, [to] understand it so thoroughly that you merge with it and it merges with you.

It’s a word that we just don’t have another definition for. In fact, Heinlein presented it as such – a Martian word for which there is no human equivalent. No other word in English really comes close to grok.

The Jargon File has a good definition of grok as it applies to software and programming:

When you claim to “grok” some knowledge or technique, you are asserting that you have not merely learned it in a detached instrumental way but that it has become part of you, part of your identity […] to say you “grok” LISP is to claim that you have deeply entered the world-view and spirit of the language, with the implication that it has transformed your view of programming.

To grok something is to…embody it. To know it down to its bones. To know it in such a way that you can speculate on how it would react in a situation influenced by multiple independent conditions. To know the chessboard and opening moves of a situation so natively that you can see it play out in your head before the first pawn moves.

Grokking something is a level of mastery where the thing becomes an extension of you. It’s where simple problems take up zero brain cycles because they’ve been solved so many times that you automatically move past them to the harder questions. It’s looking at a set of requirements and knowing automatically how you’re going to solve 95% of them because the solutions to those problems have worn grooves in your brain. Better yet – everyone on your team shares this understanding to the point where these requirements don’t even need to be discussed.

But how do we get to that level? How do we get to the level where we grok software? And how do we do this when we work with a _genre _ of software that has wildly different implementations and reifications?

For these reasons, I find it hard to grok different CMSs sometimes, and it bothers me. At Blend, we work with six or seven different CMS platforms, and they work on such different models of content management and delivery that it can be hard to shift gears. It can be difficult to see things from a fundamentally different angle. They all manage content, but in occasionally wildly different ways. This can make an integration painful because you end up fighting a system, rather than co-operating with it.

I saw a cartoon the other day of a number on the ground with two people arguing about what it was. One of them was yelling that the number was a “6”, the other was yelling that it was a “9”.

They were standing on opposite sides of the number. They were both right.

If you only ever work with one CMS, then you don’t have to shift paradigms. But for an integrator that works with multiple systems, or a back-end content strategist who makes plans for clients who could use anything, it can be tough to hold more than one idea in your head. Often, you get really good at solving Problem X in one system, but you’re mystified about how to solve the same problem in another system. Too many times, you try to solve it the same way by forcing the second CMS to act like the first. You jam a paradigm down its throat, then get mad when it doesn’t respond the way you think it should.

Our problem is that models get set in our brains. We get introduced to a way of mentally organizing information and solving problems, and we get fixated on that. Other methods don’t quite line up, and we can’t seem to get to “the other side” of a problem – where we can see that the “6” is really a “9” from someone else’s perspective. And even when we do, the cognitive dissonance causes us mental discomfort. We enjoyed the original solution when it was still a 6, and we don’t like the idea of holding two different ideas in our heads.

Here’s an example –

I’ve written many times on this blog about content trees. This is the idea that the “correct” way to organize content is by parent-child relationship. Our two biggest CMS platforms – Episerver and eZPublish are built around strong content trees. Other systems we use at Blend – WordPress, Concrete 5, Terminal Four – all have some form of tree.

We grok this paradigm. We’ve developed patterns of thought and process to solve problems by using this paradigm. This makes sense.

And this is why Drupal has traditionally been a problem for us. It has no tree. Out of the box, it has no concept of parent-child content. This has always struck me as fundamentally incorrect. Yet, shockingly, people keep building websites with Drupal. Clearly, there was a thought process there that I just wasn’t wrapping my head around.

With our existing, tree-based CMS platforms, if I have a bunch of press releases that should all appear in on a listing page, then I’m going to make the listing page the parent of multiple press releases. I’ll have a page for “Press Releases,” and under that, I’ll put all my press releases as child content in the tree. This totally makes sense to us.

But, a Drupalista doesn’t agree. From their perspective, the concept of “ownership” is strange. Why should a listing page “own” all those press releases? If you delete the listing page, why should all the press releases go away too? To them, the listing page is just a view – an almost incidental detail, compared to the primacy of the press releases themselves. In the end, the listing isn’t even content, it’s just a presentation – it’s just a way of looking at the actual content.

You see, with a tree, it’s not just the content. The tree itself, and the relationships it’s formed from, become almost a “meta content object.” There’s an aggregate structure there that must stay intact for the site to work. From Drupal’s perspective, this is simply not correct – it’s maybe even silly. This is what ancillary structures like menus are for. A tree introduces a rigid structure that hurts more than it helps.

If you contemplate this standoff for a while, you begin to understand how different the paradigms are, yet neither one is wrong. Both have advantages and disadvantages, and you can obviously build a website with either of them. But once you’ve sold yourself out to one of them, and you’re facing off against the other, it can be awfully difficult to reset your thinking and see things from the other side.

I’m suddenly thinking of a forgettable 80s action movie called Firefox (ha!), with Clint Eastwood. In it, he steals a Russian jet fighter that responds to the pilot’s thoughts. He’s having trouble flying it in the final scene, then he suddenly remembers that he has to “think in Russian.” Victory ensues. Here’s the clip, in fact.

A consequence of our inability to “think in Russian” is that we fall into ruts and try to brute force our way out of them. When you try to learn Russian, you still think in English, and you consciously translate into Russian. So, you’re not speaking native Russian, you’re speaking English which is overlaid with Russian. This is why you sound stilted and awkward at first. One when you begin to think in Russian first do you begin to sound native.

We suffer from the same thing when we try to re-frame other CMS platforms to act like the ones we know. I can remember complaining to Drupal experts on more than one occasion about the lack of a tree. Almost to a person, they said, “Well, you can install Node Relativity if you want, and make it act like a tree…but that’s not how I would do it.” They were basically telling me that I could fight Drupal all I wanted, but I was never going to benefit from the platform until I started working with it, not against it.

I was talking with Larry Garfield on Twitter about this is the other day, and he said something universally true:

What distinguishes a system is its ability to coax you into adopting its mental model, without you realizing you’re doing it.

Getting to this point can be painful, and Larry correctly points out that a good system will realize that people bring different models, and the first barrier is to get those models to change in relation to that system.

I’m reading Domain Driven Design right now, which is a classic book ultimately about getting developers and domain experts to understand the same domain of knowledge in the same ways so that software can be built to match it. Author Eric Evans has a chapter called, simply “Breakthrough.” In it, he talks of moments when clarity dawns on the developers and they suddenly understand what the domain experts have been talking about (“the deep model,” he calls it) and how it may have a huge, disruptive effect on what they’ve been building.

This sort of breakthrough is not a technique; it is an event. […] The transition to a really deep model is a profound shift in your thinking and demands a major change the design. On many projects the most important progress in model and design come in these breakthroughs.

[…] A period of steady refinement can suddenly bring you to an insight that shakes up everything. These breakthroughs don’t happen every day, yet a large proportion of the changes that lead to a deep model and supple design emerge from them.

These are the moments when a developer realizes that they’ve been looking at the problem from the entirely wrong direction. Although Evans is talking about designing software, the same thing applies to learning software. I’ve had more than one moment with a new CMS where I’ve had a G.O.B. Bluth moment, stared off into space, and said to myself, “I’ve made a huge mistake.”

I think this discomfort is ultimately healthy, and my company is better for having worked with more than one system. We talk of “cross-pollination,” where we borrow ideas from System A to implement in System B, because, occasionally, one model is better than another and it helps to have the broad base of experience to recognize when that’s the case.

There’s a cheesy cliché – from martial arts movies I think – that “the master must become the student,” or something similar. The idea is that, to learn something new, you have to embrace that new thing without reservation, as if you’re learning the entire discipline for the very first time.

Only in doing this can you really grok the thing, and only then you can evaluate it from a position of mastery. Once you grok it, you can look at it clearly, know that you understand it, and be in an honest position to decide whether or not it’s right for you. (And it might not be – I grok a lot of things that are simply bad, no matter how well understood.)

I’m trying to make a practice of going limp and let other paradigms wash over me. In these cases, I’m sometimes doing things in ways that don’t make any sense to me and seeking to understand them from the minds of those who built the system and have refined it over the years.

They clearly grok it. Hopefully, I can too.