2025-03-12 epistemology

Look at the thing!

Several years ago, I was working on a dashboard of platform usage statistics to be presented to the executive team. I had spent a few days on it, sourcing the data, building out calculations, adjusting its layout and design. Hours before the presentation, I sent it to my manager for final review.

“Why does the total active user count seem so low?”, he asked.

I pulled up the dashboard and studied the number. Total active users was indeed too low. Obviously, undeniably, irredeemably low. Had I even looked at it?

Looking #

Looking is a hard thing to do. Looking does not produce anything. It merely observes, reviews, and scrutinizes what has already been produced. It is an exercise in quality control. It does not create; it critiques.

Doing, on the other hand, is highly valued. There is a clear, tangible artifact. Excel models, Powerpoint presentations, Confluence specs, email memos, Python code, Tableau dashboards. There is no question about what you did, how you spent your time, or what you delivered.

Why spend 1 hour reviewing when you could instead spend 1 hour building?

So we build. We are incessant, frenetic builders, though we do not always look at what we built. How else can one explain the typo in the subject line of an email? Or memos with such discursive writing that readers are forced to read and re-read, as if deciphering hieroglyphics? Or inconsistently formatted presentations, the evidence of rushed copy-and-paste jobs between various templates? Or finally, as in my case above, glaring dashboard miscalculations that send viewers reeling before they even begin? 

Were these all dumb mistakes, or more perhaps aptly, hasty mistakes? One must inquire, in a very physical, tangible sense: did we even look?

Slowing down #

As the world becomes increasingly connected, it too feels like everything is speeding up. Information arrives sooner and more frequently, we communicate non-stop with family and friends and colleagues, we feel we must always be moving, doing, producing.

All this rushing implicitly prioritizes quantity over quality.

We feel impelled to get things out the door - faster, more - so that we can move onto the next thing. We are constantly distracted by the next news article, the next phone notification, the next opportunity. We are in such a rush to reach the finish line that we forget whether we’re still holding the baton.

But what about this thing in front of us? What if we stared at it, defiantly refusing to shift our attention to the next thing?

We would reflect on it. We would wonder if it looks right, if it feels right. We would notice errors and inconsistencies and words that did not quite fit. We would probe it, reshape it, refine it. We would revisit it over and over again until it was complete. It would be a meditation on quality. 

What good is what we produce if it is not what we ultimately desire? We do not merely want “stuff”, but rather “good stuff”. This necessitates deep, effortful craftsmanship. We should not just “get things done”, but instead, “get quality things done”. The indelible mark of experience is having an intuition for what is good and what is not. It is exercising good judgment and having good taste.

To do this, we must slow down. Velocity is the mother of quantity, but patience is the mother of quality. As the old Zen teachings say: “If you are busy, meditate for an hour. If you are very busy, meditate for two hours.”

Design, build and test #

Looking, while valuable in its own right, is not enough to produce great work. You must of course also produce.

In many disciplines, the roles of builder and reviewer are distinct, as if by necessity the reviewer must step back from the work, create distance, and evaluate it with the impartial eyes of an outside observer. When performed by the same person, there tend to be distinct phases of development.

When writing software, we typically begin with draft code before refactoring it into more modular, more parsimonious code. When building software systems, we typically separate software development from quality assurance (QA) and user acceptance testing (UAT). 

In civil engineering and manufacturing, we observe the same pattern: there is a stage of design, a stage of production, and finally a stage of review, collectively called design-build-test. Even in writing, many writers employ a similar methodology, my favorite of which is the madman, architect, carpenter, and judge.

As I write I flow through the different personas: he who creates, he who structures, he who fills in, and finally he who reviews. To only create is to produce without attention to detail; to only judge is to have nothing of substance to review.

All stages are necessary to produce great work. The madman will create wildly, generatively, uncontrollably. But without review, his studio of detours and missteps will be laid bare.

The judge must step in and revise. He pauses, takes a deep breath, and begins his work.