unfiltered

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?

At this point, AI writing code is inevitable. People I know are, understandably, worried about the impacts on our vocation. I don’t profess to be prescient about the upcoming effects, but I have a different take.

I’m hopeful that one possible consequence of pervasive AI generated code is that there is much more software functionality to go around. It may sometimes feel like we have a lot of software around us, but if examined closely, its effects are unequally distributed. As an example, ad-serving platforms (financially lucrative but debatably socially positive) have humongous and robust stacks while restaurant websites (personally positive) are positively impoverished.

Software is hard to build right. It is, at its best, a delicate dance done right between requirements, design, architecting, writing good code, and giving a damn. As a result, people gravitate towards building things once and building it right. Which is why people want to be opinionated, build frameworks to incorporate best practices, and the resulting power law distribution of adoption and resources.

AI writing code can change all that. If code can be written quickly with sufficient quality, and more importantly, cheaply, then code doesn’t have to always conform to the most common denominator (or popular opinion). The consequences of lowering this bar will be immense. Small businesses can break free from the big platform or janky home grown dichotomy. Software that conforms to natural workflows instead of vice versa (goodbye to enterprise software contracts). People can rewrite user interfaces to suit their abilities, needs, and preferences.

I am most curious to the last one. Because of the cost of building software, design has always have a citadel like quality to it. We profess to be the whisperer of what our users need and direct the provision of them in software modules. What if users no longer need this layer of translation? I don’t think this will lead to better designed software; it may instead lead to generally terrible software, except that in this world every jagged rock is someone else’s gem. We may truly enter the era of personalized software. To push it into the logical conclusion, seams and structures of software today will cease to exist and instead we will have access to capabilities on our terms, on demand.

It is a challenging framing to consider even beyond considering the existential threat to our livelihoods. For me, abundance upsets so much of what we take for granted, rituals and expectations that are built up over decades of the computing industry. But that may all be for the greater good. Or not. Interesting times indeed.

A theory is by its nature a partial account of reality—a set of blinders through which some aspects of the world are highlighted and others become invisible. Design is by nature both holistic and ruthlessly simplifying. A designed artifact, whether it is a piece of communications software or a city park, must address the complex mixture of human needs, embodied in a weave of physical and social interaction. But the design itself cannot embody all of these complexities if it is to be constructible and understandable. The design must embody a simplification,leaving room for the texture of the world to be filled in by the interpretation and practices of those who use it. (emphasis mine)

– Terry Winograd. 2006. Designing a New Foundation for Design. Communications of the ACM 49, 5 (May 2006), 71–74. DOI:https://doi.org/10.1145/1125944.1125978

I think about this quote a lot.

I often feel compelled to write, but writing can be it’s own work. Most of the times ideas are half-baked and it takes a lot of effort to whip them into article form. Other times thoughts that are promising don’t get fleshed out and they get lost. As a result, I lose a record of them.

I want to find a way to write them down.

And hence unfiltered, a new section in the site. Fashioned after microblogs 10 years past their prime, named after what a former boss of mine said of me, this is the garden where I get to record ideas or pluck thoughts as they flutter by.

Posts will be quite short, mostly unedited, and a light and easy way for me to publish. The fully fleshed ideas will remain in writing, and everything else will come here.

Here’s to the first post; hello world!