FunDataMentals
I don’t believe in rote memorization. I believe in derivation.
Welcome to FunDataMentals: part Fun, part Data, part Mentals. The name is a joke, but not really. This blog is where I play with data, mental models, and first-principles systems thinking until the structure underneath starts to show itself.
My bias is simple: if I cannot derive the idea, I probably do not understand it yet. I do not want to merely memorize jargon. I want to know what problem the jargon was trying to solve before it became vocabulary.
Bridge-principles thinking is how I learn across domains. I take a reference frame I already understand — usually math, systems, or physical intuition — and use it to cross into a domain I am still unpacking. The goal is not to avoid the field’s native language. The goal is to derive enough structure that the jargon has somewhere to attach.
The Philosophy
Most technical writing starts after the abstraction has already been chosen. I like starting one layer earlier.
Before "data", I ask: what was observed, by whom, through what frame? Before "computation", I ask: what relation is being physically realized? Before "hardware acceleration", I ask: what abstract operator is being mapped onto what physical operator? Before "performance", I ask: where is the data, where is the function, and what does transport cost?
That is the recurring pattern in this blog: move down the abstraction stack, derive the hidden constraint, then bridge back upward.
I will use analogies, math, scratchpad reasoning, and occasionally uncomfortable amounts of self-questioning. Some explanations may be unorthodox because I am often trying to reconstruct the idea before adopting the standard terminology. That is intentional. The standard term lands better after the structure is visible.
The Current Arc
The first few posts form a loose sequence. They are not random essays. They are me building a personal map of computation, data, systems, and thought. Alternatively, you can read in sequence: 3 -> 1 -> 2 -> 4.
Start here — each card is clickable.
Math says apply the function. Physical computing asks where the data is, where the function is, what hardware operators exist, and what transport costs.
02. What Is Data? Part 1Data as observation through a reference frame: signals, unresolved states, sequences, equivalence classes, memory, meaning, and probability.
03. SPPARRSA systems-design framework that expands upon the constraints of the PPA (Power, Performance, Area) framework.
04. Escaping the 3PsPerfectionism, procrastination, and paralysis treated as systems problems instead of moral failures.
The Author
I am Clarence Bowen. I have a BA in Mathematics from NYU and over 20 years of experience building software and data systems. My background includes SQL-heavy data engineering, production software, compliance/risk systems, teaching programming, and recent deep dives into low-level systems, hardware, FPGA concepts, and performance.
I am an autodidact in many areas of computing. That means I often learn by translating unfamiliar technical material into a reference frame I already understand: math, relations, graphs, algebras, physical constraints, and concrete everyday analogies. Then I translate back into the field’s native language.
That is not a rejection of standard terminology. It is how I make the terminology real.
Work With Me
I am interested in systems, data infrastructure, low-latency engineering, hardware-adjacent software, technical architecture, and hard problems where correctness and performance matter.
My strongest work sits at the boundary between messy real-world systems and clean technical structure: translating ambiguous problems into data models, pipelines, architectures, performance constraints, and implementation plans.
If you need someone who can reason from business/data problems down to implementation constraints — or from math and systems concepts back up to product and architecture — let’s talk.
Start a Conversation →