Notes of November

A few notes from November 2025:

Tooling

I was using two tools in the recent months that gave me a lot of joy in my day-to-day work. The first is Jujutsu, or jj in short. It is a version control system (VCS). If I should describe it with my own words, it is a git-inspired and git-compatible VCS based on the intuition many developers have about the way git should behave.

Many daily development tasks like throwing away all uncommitted changes (jj abandon) or restoring a file from an older commit (jj restore) are much simpler to use than in git, where these tasks usually require a handful of flags that I have all stored in a large cheatsheet.

Git was the first VCS I used, and it still serves me well every day. For a private project, jj has been giving me a breeze of fresh air lately and I hope we will see wider adoption in the future.

Another interesting project I discovered is cdist. It is a configuration management system for servers, initially developed in the space of the university ETH Zürich. I have a couple of servers running and manage them mainly manually. Some administrative tasks got so tedious though that I was looking for a lightweight alternative for Ansible or Puppet. I’ve used both systems, but I always found them complex and slow and Ansible kept breaking after a couple of weeks for Python related topics that I don’t understand.

It took my two evenings to understand cdist and deploy my own binaries with their respective OS users and service definitions. Once I understood how to deploy and configure software with cdist, it was a matter of minutes to add even more software to my deployment stack. If you are looking to automate some parts of your server management and also find Ansible and Puppet too mighty for your simple use-case, cdist might be your tool.

Search

Google Search unfortunately is broken beyond a point of usability. The first half of the page is filled with AI fluff, just for the second half of the page to be filled with ads.

It takes scrolling to reach the first usable results, even though medium.com is still ranked quite high and that’s usually not a useful result (and neither is LinkedIn).

I came across kagi.com. It is a search engine which does only partially rely on other search engines (in contrast to e.g. Ecosia which uses Google’s search index). A compelling feature is to up- or downrank websites, or block them entirely from the search (medium 👀). There are a couple of customization options for searches.

What’s most surprising for me is how used I got to Google gradually serving me a nightmare experience and how kagi is able to bring back this intuitive feeling that Google once brought, to search for a thing and to find that thing within the first page.

I’ve only tried kagi for a few days yet, and it already makes me feel different about how search engines should be. Kagi is a Public Benefit Corporation, and they describe a few things about their mission on their blog, including their stance on AI, which leads me to…

AI on my blog

I thought I’d get around writing about LLMs. I just wanted to say that this article was written by hand and none of it ran through generative transformers. I want to be honest and say that not every article on my blog is equal. I was very impressed when Michael Lynch described in his blog how he hires a human editor to review his articles.

I see the value in well edited text, but I didn’t want to spend this money, so I was looking for a more affordable solution in terms of grammarly and the like (which seems to be an AI company now too…). English is the language I speak best right after my first language German. I wished I could speak with the same precision in both languages, but I don’t, and probably I’ve reached a ceiling in my current environment for how much I’ll be able to improve.

I experimented with LLMs, namely to write an English article by hand and prompt the AI for “You are an editor. Review my article…”. Even though all my posts are handwritten, the editing of the past year or so has this “AI smell” that nobody really can put a finger on, but we all notice when it is there.

I decided that for my own blog I want to be very much in charge of my own language, so I don’t need AI writing or editing anymore.

I compare the usage of LLMs (and the increased use of Agents) to the illusion of productivity-systems. In all the years that I researched note-taking and productivity systems, I came to realize that most of what you see on “Productivity Youtube” creates this illusion of being productive, because there are all these tools and workflows. It is the complexity of the setups, the magic of automation that makes us believe we are more productive. Most of the time though, real productivity comes from sitting down and doing the thing, not managing a system around the thing.

When the LLM generates all these words “for us”, we feel empowered and productive, as if we achieved something. Personally, I don’t want to read AI fluff and I prefer to sense when someone struggles with the language and struggles and succeeds with making a point clear.

Probably the perception of reading blog posts will change in the age of AI. If in 2019 an article was extremely well written, someone spent a lot of time and enthusiasm for language. If in 2025 an article “sounds nice” or “reads well”, it does not say much about effort anymore. The value of an article, as it is with productivity systems, comes from “the thing”, not the system that manages the thing. I’ll never write in a style like The New Yorker, especially in English, and I am starting to get comfortable with my flaws, thanks to the uncanny text-valleys that LLMs produce.

I see LLMs as a search engine for words, which is NOT a search engine for information, knowledge or even wisdom.

Closing with Feedback Culture

When I wrote about Crew Resource Management (CRM) in 2021, I only wrote about the happy path. How to set up a framework for software developers to collaborate. I did not cover the topic of failure.

I was recently thinking about conflicts at the work place. Power struggles, power abuse and how “humans happen”. Giving good feedback is about knowing when not to give it. At the same time, we all have our boundaries, and there is no life-hack to make communicating those boundaries easy. This communication itself can be another cause for friction.

Circling back to CRM, more often than not the root cause is an organizational system that leads to conflict, or phrased differently, an organizational system that does not prevent a certain type of conflict. Once in a while it is good to remember that resolving a conflict is not “you against me” but “us against the problem”. Nonetheless, reckless behaviour is not systematic and requires accountability. Most of this is covered in the context of CRM, and it would require an article of its own to cover those topics.

My flight instructor taught me “always, with one eye, look out for a suitable landing area to be prepared for an engine failure”. Planning for the failure path is part of any aviation mission.

How come we set up systems like Scrum and assume they work if we follow what’s written in the Guide? How come the Scrum Guide does not mention the word “error” or its synonyms? (Except for the word “failure”, which is related to a “lost opportunity”, which in turn is pretty much an empty phrase, as most sentences are in this Guide).

This is not just about Scrum. It is more about the observation that success is made systemic whereas failure is seen as individual error. If framework X succeeds, it did because it is a good framework. If the same framework X fails, it did because we blame an individual.

As with an API that doesn’t define error scenarios, I am highly sceptical of management frameworks that don’t define those either.