Part 2 of my Universal Structure blog chain. Start here.
As I was thinking about structure and data models, I wondered about how we make decisions every day, almost effortlessly, which are fundamentally data model manipulations:
- Structuring emails or notes with headings and by moving paragraphs of text around
- Using lists and tables and knowing which items belong together and how to order them
- Creating graphs and visualizations to express certain points with “pictures worth more than a thousand words”
- Naming documents, files, and folders in a way sensible to us
- Filing away documents, emails, notes, and tasks into complex folder hierarchies
- Building these hierarchies in the first place and adapting them over time as our needs change
You don't have to be a computer scientist or software engineer to do any of these things. Chances are that if you are one, you think about them differently. And perhaps too much.
How do we do this?
How do we think about structure?
How do we… think…?
I already have a pretty good understanding of data models and how to implement them with databases or programming languages. I have designed data models — complex, flexible, and performant ones for various use cases — using different technologies many times.
It dawned on me that this could actually be a problem.
How can I step back from all that knowledge, letting go of all the assumptions and restrictions that come with it, into some form of beginner's mind, to discover new ways of thinking about data and how to structure it?
I was keen to distance myself somewhat from programming. I really wanted to understand the problem I was trying to solve. I rejected the comforting feeling of working on the first solution that comes to mind.
We tend to jump into designing solutions way too quickly, often without taking enough time to understand what the problem really is. If you have been trained in and gained experience in the software industry, solutions likely come easy to you, because our industry is all about making up solutions out of thin air. Or caffeine. We don't even need problems for that. We just go back and look for a suitable one later.
I also didn't have anything at hand that would justify adding another app on top of the already enormous pile of apps in the app stores. The last thing the world needs is another app. If I eventually end up building something, it has to offer substantial value.
To come up with something substantial, I felt I needed to explore places I haven't been to before. That's where I believe good ideas come from — the combination of existing ideas that haven't been combined before. I was looking for understanding and inspiration outside of my area of expertise, hoping that I can find something considerably different to the attempts at solutions that already exist. Not different just to be different. Not new just to be new. More in the sense of leaving a local maximum behind and finding a higher one far out in an unexplored landscape. Places where few computer scientists have gone before, but other scientists are at home.
When you expect to found a startup, you talk about it all the time to everyone who's willing to listen. Once, as I was explaining the note taking use case as an example for data model manipulation, I got a recommendation to look into research about categorization in cognitive science. Turns out that this was a thing! A comprehensively researched thing. Several disciplines had explored this area for decades and amassed some pretty insightful ideas about it.
The recommendation came with two names: Eleanor Rosch, known for prototype theory, and George Lakoff, known for metaphorical structuring. Both researchers in cognitive science, who dedicated decades of their lives to figure out how humans put things into categories. Spoiler: it's one of the things we do all the time, we're really good at it (which comes with its own problems), and it's a fundamental part of how we think.
And thus started my journey into linguistics, a field I would've never expected to look into at all. Just what I needed to leave all baggage behind and start from scratch as an absolute beginner.
Soon I would discover that both linguists and programmers think about shockingly similar problems.