What problem are you solving?
What problem are you solving?
How to make progress without making a mess.
Greetings!
Status of Executable Specifications, my new book on domain modeling:
You can always see the table of contents with links to the ready chapters here.
Last week, I published the Data Lens Supplement, a reference for common data modeling structures and the language features used to implement them. Please hit reply to let me know if you found it useful or if you know how it could be more helpful.
Chapter 3 is still in the works. It's currently 20 pages.
Please reply to this email if there is any part you love or a place you got confused. If you send me a significant number of comments, I'll put your name in the acknowledgments section.
Also, I was on the Kodsnack podcast! That was a great conversation.
Now for the essay:
What problem are you solving?
I said, "My god, it's full of state," but what I thought was, "React was supposed to make things more functional, not less." They were using the right tool but solving the wrong problem. We do it too often in our industry. Why? And how can we do better?
Some context: In 2016, after four years of blissful immersion in ClojureScript with Om and Reagent, a company contracted me to functionalize an ailing React Native app in JavaScript. They designed React for functional programming. I thought it would be a breeze. Boy was I wrong!
When David Nolen introduced React to the Clojure community, I immediately recognized that it solved the problem of syncing the DOM with the state as it changed.
When I dipped back into the world of JavaScript years later, I found these common practices:
Fetching user account data inside the component when it's mounted? 🙈
Building giant trees of components that managed state for you? 🙊
Keeping all sorts of state inside the components? 🙉
Not just at the one company, but all over the web. People applied React to every problem, including:
State management
Declarative configuration
Error handling
People think React is dumb because systems using React are so complicated. But to me, React simplified code because it solved a real problem. Look at any Reagent application. React is there, doing its job (the view). It is not dominating the application. But out in the JavaScript ecosystem, people ignore what problem they are solving.
It's easy to fall into this trap because it's easier to start coding than to think hard about your problem. We start coding, using our habits and the herd to guide us. Each step we take down that well-worn path makes it hard to return to square one and rethink everything.
It happens when people code the Student/Course Problem with classes and references. They're so used to modeling the nouns in the problem description with classes and identifying isA and hasA relationships that they don't think about what the problem is about.
I know about the DOM/state syncing problem, but there are problems I don't understand as well. I didn't see the many-to-many solution to the Student/Course Problem when I first saw it. I learned those with time. It's not fair to expect everyone to see the problems I see. I'm sure I miss many problems they see as well.
There is a beautiful one-line implementation of the Game of Life in APL. It counts the neighbors of live cells instead of counting the live neighbors of cells. Meditating on the Clojure version helped me understand it. Not in a million years would I have thought of that problem definition.
Having learned that problem definition, reviewed it, and considered why I couldn't see it, I found the pattern: Whenever you're facing a problem with symmetry, consider the symmetrical problem, too. The Game of Life phrases the rules as counting the live neighbors of a given cell. Neighbors are symmetric, so we should consider counting the neighbors of live cells. It may be an equivalent problem with better solutions.
Problem-finding is a skill. It takes practice and self-awareness. But so does the skill of recognizing you need to know what problem you're solving. It may take more work to find the problem than it takes to solve it. We should step back and identify the problem to a certain level of understanding before proceeding. Problem-finding is as valuable as coding, if not more so.
Rock on!
Eric
PS I love hackathons for practicing problem-finding. There's nothing like tight deadlines, low stakes, total authority, and sleep deprivation to figure out what's important.