unfiltered

I love learning. It often involves looking for new sources of information to drink from. There is an exhilaration from discovering the untapped land of knowledge and a rush from venturing through it.

Yet to my recent surprise I discovered that the once topic of my disdain, repetition, is an equally great teacher. Through the integration of a few daily practices I have found them to be a profound source of satisfaction. Repetition is the king of compounding effects. Inches accumulated over time paves major new thoroughfares.

Doing a thing, whether it is a movement, technique, or habit, over and over again yields insights and opens up new areas of exploration. Maybe it is the small adjustments that repetition demands, the continual solving of micro problems, or simply the comfort of familiarity that frees the mind to wander. Whatever the reason, repetition fosters mastery and creativity.

It’s very hard to do a thing over and over without becoming skilled or without eventually getting inventive. Moreover, this knowledge can only be gained through repetition. The insights are embodied and ingrained in the motion–not something one can read or listen to.

I used to dread practice. Now, I look forward to it.

Recently, I have taken back to sketching out ideas by hand again. To achieve a neater and more compelling final composition, I found it really useful to work in layers.

The first layer is always a rough placement of where things go. Subsequently, I will refine content and details, ink the outlines, and finally add color and shadow. Every pass is an attempt at both fleshing out the idea itself and achieving balance between the elements. Finally, the pencil lines are erased, the scaffolds taken down, and what is left is the final polished composition.

This is going to sound profound and basic at the same time: iteration isn’t optional – it’s essential. Good design demands iterations because it only emerges from progressively refining ideas from rough concepts to detailed compositions. No one, no matter how talented, can do it all in a single pass.

Product design mirrors this truth. Understanding a problem thoroughly demands multiple iterations. Every pass is an opportunity to uncover new insights to elevate the status quo towards something better. Unlike paper and pencil, modern tools often err on the side of too much gloss. This is a reminder to myself that at the fundamental level iteration, more than any tool, is how we get to great products.

In business they often talk about bundling unbundling cycles. In product, the countervailing forces are width and depth, that is to be as broadly applicable as possible, or as narrowly applicable as possible. The worst place to be is at the middle because one can neither reap the effects of being de facto solution nor fitted like a glove to a niche.

Going wide is typically suited for first movers within a new domain and those who seek to challenge them. To take a contemporary example, ChatGPT is the broadest solution in AI Chat today, and they established their position by being an innovator in the field. To play in this arena, new players will have to find nooks and crannies where ChatGPT is no longer a good enough solution, or, mount a full frontal with all the resources they can muster (against all of OpenAI).

The common saying in startup circles is that if one can find 10 customers, one can find 100 (there is risk of overfitting at one). At first glance, the business opportunity may seem enormously asymmetrical, but two things. First, financial rewards are disproportionate; the most lucrative is often overlooked. Second, product molded to specific niches may find a larger market available to them over time because the practices in those areas surface to mainstream (think tools like kanban).

First exist. Then play.

I have been thinking about thrownness ever since I’ve learned about it from Winograd and Flores’s Understanding Computers and Cognition¹.

Wikipedia defines thrownness as the following:

Thrownness (German: Geworfenheit) is a concept introduced by German philosopher Martin Heidegger (1889–1976) to describe humans’ individual existences as being ‘thrown’ (geworfen) into the world.

As I get older, I am starting to believe that we often experience things first, then we make up stories to justify our behaviors. We weave in our felt sensations, our internal motivations, and subconsciously or not our desires as well.

Design, by its contemplative nature really likes constructing stories. Stories like user journeys, especially when stripped of contradictions, become alluring totems that we use to burnish the glean of our designs.

We build flows and interfaces with our perfect information of what we want the user to do. People, on the other hand, experience our designs with what they know and want to accomplish. They do not have knowledge of or care for the frameworks that we attempt to ruthlessly simplify into. Real life is messy and people are thrown into the rhythms of life and have lots of things to worry about other than clicking through our perfectly constructed contraptions.

I am not arguing for abandoning stories or frameworks. They work for a reason. What we need to do is to have less faith in stories but consider them sufficiently so that we can deliver good outcomes, and not so much such that we become prisoners to them.

Sometimes, the best we can do is to watch other people use our software and we’ll realize that how broken everything is.

I got nerd sniped into adding a table of contents into my Jekyll blog. I don’t know, because I think it looks cool (here’s an example). Getting nerd sniped therein of itself is not terribly interesting, but having AI help with nerd sniping is a game changer.

Despite my love for Jekyll, I don’t read or write Ruby. I find the syntax incorrigible. In this case, I was using the venerable jekyll-toc plugin and it was lacking one key thing that I want to do, that is, render the table of contents only when there is something to display. After banging my head against the wall on search engines and shuddering at the thought of submitting a pull request in Ruby, I turned to ChatGPT for a solution.

The result was a short and sweet custom plugin, my first ever on this site. At the end of the day, I’m glad this one day-ish excursion is no longer than it needed to be. I’ll count that as a win.

module Jekyll
    module CountHeadersFilter
        def count_headers(input)
        return 0 unless input
        input.scan(/<h[1-6].*?>.*?<\/h[1-6]>/i).length
        end
    end
end

Liquid::Template.register_filter(Jekyll::CountHeadersFilter)

See? Incorrigible.

There are a certain set of settings that we set once and then we forget why we set them. Recently, I ran into an issue where localhost does not resolve (consistently) to 127.0.0.1 on my local machine. A quick diagnostic revealed that it has something to do with the DNS resolver, and specifically, something to do with pointing it to 8.8.8.8. At some point I stopped digging because it’s not worth the time to untangle the why – I simply needed to unblock myself.

These occurrences, that is discovering my esoteric actions in the past, happen a few times a year, and a few year gap between in each morphotype. I’ve tried a few different solutions, from leaving comments inline (I don’t have the foresight of knowledge), to jotting down in notes (which now creates an all-encompassing chore), and nothing quite works. I then either spend hours trying to understand the system again or unblock myself to the extent necessary.

The thing though is that I am a proponent of software customization. Settings are good! We should be able to change things to suit our needs. The question is customization creates an exception case, and when that exception meets the mainstream and our memory fails us, how do we gracefully resolve them. That is, ensuring that the intent of the change is honored while paving a path forward for whatever that needs to get done.

Design thinking loves happy paths. It does make me wonder, what does the design literature and the collective intelligence have to say about this. What is the best way to handle plurality in systems?