reflection

March Update

The main story this month is that I traveled to Vancouver in late February, then to Seattle, then to the French Alps. Eight months of emotional buildup were released during my flight back from Geneva a week ago.

❦❦❦

There are just four overlapping stories here.

The first story is factual. I traveled to Vancouver to learn about the city for a few days, then join a group of friends to spend a week in Whistler. I then visited another couple of friends in Seattle before I made my way back home in early March. Two weeks later, I was on my way to Val Thorens, in the French Alps, with a group of a thousand-plus mostly-British vacationers whom I had never met before. I just traveled back.

In both cases, the snow was most excellent and the snowboarding glorious. In one case, I cherished the emotional intimacy of a close group of friends. In the other case, the music and thrice-a-day partying made me feel both younger and stronger than I had ever been before. Both were good times.

On my last flight back, I was taken by a swell of feelings, a mixture of joy from these experiences, sadness to have to wait longer until the next round of winter sports, and uncertainty about the changing climate and its impact on all types of snow-based activities.

❦❦❦

Another story is that I have been organizing group travels with friends for winter sports approximately every year for a long time. This a win-win-win habit: I get to enjoy one of my favorite hobbies; my friends can delegate some of the logistics to me; and I habitually amortize this travel with ancillary activities at the destination. Organizing these trips is a lot of work though, both before and during the travel; this work sometimes prevents me from fully letting go and enjoy the opportunity as a vacation. This year, as an experiment, I chose to join a travel organization other than my own. It was a treat! I was able to “let go”, my attention was much less focused, I lived more in the moment, and as a result I felt much more refreshed at the end.

The lesson learned here is that there are two types of vacations: those of service, and those of rest. I need both. I only realized this on my last flight back. It was enlightening.

❦❦❦

Yet another story is that for the first time in forever, my travels last month were baked in anticipation. In contrast, for as far as I remember in previous travels I would always be busy with other things up to my day of departure. Before, I made no time for mental and emotional preparation—no anticipation, no daydreaming, no imagining! The reason why I denied myself the pleasure of anticipation was to avoid the anxiety crises that it was paired with. For context, I have a tendency to over-analyze possible outcomes, and my thorough analysis skills also bring me to explore all the ways a project can fail. Applied to traveling, this analysis had in a time further past brought anxiety about the corresponding failure modes: missing flights or connections, scams, unfortunate encounters, homesickness, or simply discomfort due to environmental novelty. An so I denied myself anticipation to prevent myself from these bouts of over-analysis and its resulting anxiety.

And then, something changed. I am not sure exactly when, but it certainly has something to do with cognitive-behavioral therapy. This year, I simply knew I could trust myself to enjoy anticipation without fearing anxiety. And so I did. For the last few months, I felt excited and hopeful about my travels to British Columbia and the French Alps. I let myself develop some ideas of how I would enjoy these experiences ahead of time, and reality exceeded expectations. During my last flight back, I felt grateful.

❦❦❦

A simple way to tell the last story could be “I planned for my sabbatical period to last until the end of winter.” However, this would not be accurate in two ways. For one, what I am currently doing is not exactly a sabbatical since my hands have been pretty full for the last few months with management, communication and accounting tasks. (I could even say that I have been working harder than in the few years before. More skills, more knowledge, more discomfort.) The other part of the the truth is that I did not really plan anything. There were a few things I wanted to happen in my life in this period, but then more unplanned things happened, and on top of this there is still a house project to deal with. Yet, one underlying idea of the simple phrasing that is still valid is that I wanted to delay the search for new cash flows up to and including my time snowboarding. Financially, it was unclear I could pull it off. So during my last flight back, I felt relieved I did.

❦❦❦

The irregular schedule and dynamic days left less time than before for reading.

Zero to One: Notes on Startups, or How to Build the Future - Peter Thiel

I read this due to how often it was cited by other works I read before. A lot of it is certainly “rich dude thinks they got rich because they were smart, with no reference to survivor bias.” Some of it is genuinely thought-provoking. (The author proposes that provoking thoughts is a key to good business. I don’t know about that, but I certainly find it interesting.) One aspect I found particularly remarkable is that Peter Thiel’s entire business practice, as much as can be read from his book and perceived from his public appearances, is what happens when starting with a hyper-individualistic personal philosophy and drawing it to its more extreme conclusions. This reading experience solidifies my opinion that Peter Thiel has become who Ayn Rand would have been if she knew how to use computers and had access to venture capital.

I personally would not go about “building the future” like Peter Thiel does it, but I welcomed the various prompts to make me think about it in my own ways.

Seven Habits of Highly Effective People: Powerful Lessons in Personal Change - Stephen Covey

This is very good. Like Your next five moves, this book would have changed my life for the better if I had read it when I was younger. And like the High growth handbook, it is extremely actionable.

However, it is also very difficult for me to read. I challenges my sense of identity—what it means to me to be a good person. I read half of it, realized I misunderstood some of the core ideas, then started again. The second read was much slower. As I am closing to the last few chapters, I realize I will need a third pass with a notebook.

Do Artifacts Have Politics? - Langdon Winner, MIT Press

This 17-page article from 1980 is not a book but influenced my thinking more than several of the higher-profile books I read in the last three months, so it deserves mention here.

At the risk of over-simplifying his argument, my summary of the author’s point would be that the particular choices of a technology designer can either greatly enable or greatly inhibit particular political arguments made around the technology. For example, brittle systems with high risks of critical failure promote authoritarianism (because their correct operation requires strict procedures, and in extenso promote the thinking that governments require the same). Conversely, certain choices in specific artifacts can empower democratic and collaborative behaviors at a larger scale; for example, the introduction of locally-owned, distributed residential solar energy generally increased social participation in energy policy making. (It is unclear this would have happened if designers had optimized for the technology to be leased and managed centrally.)

This article adds one more founding stone to my idea that an effective government in the future will need an Office of Technical Design, and that technology designers/developers should be required to obtain a license to confirm their training in ethics and policy making. I still wonder which part of the world will get to it the fastest, and if I had to bet money I would predict somewhere in Europe.

❦❦❦

While I was not able to make my way through many books like in the months prior, my pace of interstitial learning remained unchanged.

One of my pet topics of interest is the proper use of incentives to drive policy. For example, I like the idea to create pressure to spend money, because I do not like the idea of wealth increases by just sitting on a hoard (relatedly, I buy into Piketty’s ideas). However, I also do not like inflation. How to reconcile the two? I often thought about this until I learned about demurrage this month: introducing a cost just for the holding of currency. It was instructive to learn about the history of Wörgl in Austria (translation). Demurrage works, but central banks and wealthy, influential politicians really do not like the idea.

❦❦❦

My favorite “lies in statistics” for this month are Berkson’s paradox and Simpson’s paradox.

In the first case, two unrelated properties in a population may appear to be inversely correlated due to a selection bias in the observed data. I like one of the examples of the Wikipedia page: if one chooses to date men only if their niceness plus their handsomeness exceeds some threshold, it appears as if the nicer ones are less handsome on average (and vice versa) even if the traits are uncorrelated in general.

In the second case, a clear trend observable in two or more sub-groups of data disappears or even gets reversed when the data is combined. A classic example is how men appear to be more likely to be admitted to certain schools than women, when in fact this combined result is an artifact of mixing admission statistics from different departments, where women apply to the more competitive departments (with lower admission rates) and men apply to the less competitive departments.

With both paradoxes in mind, I started wondering about my earlier observations that folk working in software engineering are either very skilled or experience a more balanced lifestyle, but not both (on average). Which of the two effects is most at play here? Is there a lesson to learn on how to shape hiring policies?

❦❦❦

Two serendipitous readings helped me connect two ideas about good design together which I previously thought were unrelated.

In When robustly tolerable beats precariously optimal, Amanda Askell explains that folk have a rational tendency to pay for products that are less optimal overall because they are less likely to fail in special cases. Key quote:

The more high impact something is—the more widely a technology is used or the more important a piece of infrastructure is, for example—the more we want it to be robustly tolerable. When a lot is on the line, we’re more likely to opt for a product that is worse most of the time but has fewer critical failures.

—Amanda Askell

While Amanda was likely focusing on bridge building and democracy while she was articulating that argument, I find that it applies well to a variety of other topics. For example, for people (like me) who care a lot about versatility, a technology tool with many customization options and less vendor lock-in is more “robustly tolerable” than a reduced-function, polished-UX tool that would fail spectacularly by refusing to achieve certain tasks that I care about. Android, iOS, Emacs, VSCode, this kind of things.

(Or perhaps, connecting more dots with the previous topic, perhaps I would be more likely to hire an individual with a more diverse set of habits and interest than one that outshines other candidates through their technical skills alone.)

Meanwhile, in The Mythical Non-Roboticist, Benjie Holson calls for two important design principles.

One is that design choices should be informed by real people that the designer has directly talked to, with real-world problems. This may result in ad-hoc choices and that is OK (and more valuable overall). The opposite is designing for amorphous groups and abstract problems, which results in shoddy designs that mask too much complexity from the problem domain. In particular, Benjie recommends assuming “your users are just as smart as you.” (Allegedly, Steve Jobs believed the opposite. This migh explain certain things.)

The other principle is that while building stuff, most of the effort is spent battling uninteresting tooling friction. More and better innovation happens when that friction is reduced. So during design we should properly work on reducing that friction at the same time as we make products betters for customers.

In summary, the author proposes his “law of tolerable API design”:

Design your APIs for someone as smart as you, but less tolerant of stupid bullshit.

—Benjie Holson

Note how the word “tolerable” here means something different from the other use above. Nevertheless, the two readings combine into a myriad of conclusions to my practice of engineering.

For example, Pareto’s principle suggests one should focus on “20%” of the work to obtain “80%” of the results. Sure, but which of the 20% should be chosen first? As per the principles above, the right choice is to focus first on the most unpleasant obstacle remaining in the way of users. This may be a big thing that causes the most risk, or it may be a small thing that causes them to feel that their task is insurmountable. Working on this obstacle first may bring the product to a place where it is not optimal any more relative to desirable goals set for later—for example it could be slow, or lack fancy UX; however, we learned here this trade-off would not matter for adoption.

❦❦❦

Another curious but enlightening context for the above is the madness that can be found in traditional ideas regarding identity and access management for Cloud services. In IAM Is The Worst, Mathew Duggan explains the current/past sad state of affairs, and outlines how to use the ideas above towards a happy(ier) situation: let developers deploy their applications with the most permissive set of permissions/capabilities initially; then, after 30 days of testing, automatically inspect which capabilities the application has effectively used and remove all the others. Sure, this approach may result in some imperfections: a bug may cause the application to request/use more capabilities than the customer needs; or perhaps some feature was not tested during the 30 days period and causes the application to fail when the needed capability is not found later. However, overall the outcome is more robustly tolerable, and avoids the huge PITA for developers of discovering required capabilities manually.

I predict this overall philosophy will slowly and surely catch on more product domains. In fact, once looking at design trade-offs in this way, it’s hard not to see it.

Another example can be found in Wayde Robson’s observations in A Return to Blu-ray as Streaming Value Evaporates. When streaming platforms, due to economic pressure, start to reduce their catalog or increase their prices, users quickly realize that the catastrophic risk of losing access to the media they enjoy and have already paid for is, in fact, rather high. In comparison, owning a physical copy of the media with a comparatively less dynamic device like a Blu-Ray player, is more robustly tolerable too.

❦❦❦

My favorite “doom reading of AI politics” this month was Are We Watching The Internet Die? by Edward Zitron. Edward’s center argument is that businesses like Anthropic (Claude) or OpenAI (ChatGPT) are trying to position themselves as middleman between people and the internet and extract payment in exchange for a “clearer” (sanitized) view of online content. These businesses do not care that the average quality of online content seems to decrease (due to more and more generated content with little human supervision), because their technology cancels it out. In fact, it is in their benefit that the internet becomes less and less usable by people directly, so people become increasingly dependent on their tech to do anything. Ergo, the internet will “die.” This piece is well-researched and contains numerous links to other, also well-written resources. (all of them by real people!)

Yet, all in all, I do not share this pessimism. The internet is the network, much more than the content that was uploaded to it. The internet, as a network, is there to stay. Meanwhile, people will continue to invent new ways to connect to each other. At this point, I predict that a new generation of content wealth will emerge from more private interactions, unmediated by large public platforms like Facebook or Instagram. In my vision of the future, we will see entire “web sites” exchanged in private group chats run for and by local communities; all of this neatly tucked away from the training engines of the likes of OpenAI thanks to end-to-end encryption. This is not a bad thing.

❦❦❦

On a technical note, the LLM tooling landscape is a bit of a mess. I was grateful to Chip Huyen for their high-level overview in What I learned from looking at 900 most popular open source AI tools. Their proposed “AI stack” feels like a good mental model.

❦❦❦

On another technical note, I just spent a week prototyping an idea and the exercise required brushing up my skills towards showing stuff to users in a web browser in a new way, including an exercise in creative UX (as opposed to, say, changes to an existing application by modifying existing web code with little UX changes). I had last used those skills in 2018, and in 2009 before that, so I was rather rusty. In the course of a few days, I did a deep dive and learned far more than I care to admit about React, Vue.js and Svelte. The bottom line: bleh, IT IS ALL AWFUL.

(╯°□°)╯︵ ┻━┻

I will refrain from phrasing opinions about their suitability for more mature projects, or perhaps projects with numerous contributors. What I can most confidently say, however, is that none of this technology is remotely adequate for fast prototyping by one person.

In contrast, I felt far more respected by everything I learned through following links in Sebastián Ramírez’s background work analysis for FastAPI. I knew of Django and Flask already, and I was happy to learn of Sanic, Starlette and, of course, FastAPI itself. What made me most happy is to see the convergence in the Python ecosystem, where folk have generally agreed across tools that it is a Good Thing™ when a language’s expressivity allows framework designers to create a DSL to increase the productivity of developer-users. A value I strongly stand by, and one sadly not shared in most of the Go and Typescript ecosystems.

As to which project I am working on specifically? It is just a thought exercise at this point, and I might only tell after and if it actually helps me learn something useful about the world.

❦❦❦

References:

Publication Date: