A Note to Self on Churn

We shall not cease from [churn], and the end of all our [churning] will be to arrive where we started and know the place for the first time. — Me, quoting T.S. Elliot

Humans get good at what they practice. Doesn’t matter what it is. If you practice something over and over, consciously or not, you’ll get really good at it.

Working on the web, I feel like I’ve become really good at churn: anticipating, evaluating, and navigating constant change. How we build on the web is constantly changing — seemingly every week a new framework, technology, or methodology which claims to eek an improvement over whatever exists now — and there’s a feeling of “FOMO” at the least, “keep up or die” at the worst.

So I learn, and I churn. I don’t like the churn, but I’ve also become really good at it. And I like to do what I’m good at. The joker said, “if you’re good at something, never do it for free.”

I’m good at staying abreast of new technology. I’m good at Googling a problem and finding a solution. I’m good at hunting through community forums or channels to find the solution or workaround to an API change. I’m good at refactoring an old framework to a new one. I’m good at solving technical problems where I just want to make something work, like making the thing flash across the screen or making the code compile without errors.

But I’m not always good at pausing and asking why I want something to work, and then how I plan to make it work in response to that why.

I feel the pain of my current tool and reach for a new one that relieves those pains, only to realize afterwards that the strengths of my prior tool are now weaknesses of my current one. So I churn, switching from tool X to tool Y to tool Z, often to learn I could’ve lived with tradeoffs of any of them and been just fine.

But fixing an issue is not solving a problem (see my story about a new toilet).

These are all thoughts I’ve been reflecting on after documenting my notes from Rich Hickey’s talk. At one point, he states:

[We have a problem and somebody says] “I think we need a NoSQL database”. There’s something missing here. We haven’t actually said “why?” We haven’t stated: what are the characteristics of this problem that lead us to this solution? This is where all the interesting work is in software development.

I have seen so much software made where nobody ever wrote down the problem and all the sudden boom, we have a new system. Nobody ever stated what problem was being solved.

Perhaps churn can be the experiential stepping stones to understanding and wisdom? There’s a balance in there somewhere. For now, I’m going to try to be better at articulating a problem before jumping to solve (or at least get around) it. As Rich says, “the seed of solving a problem is stating it.”