It comes from the amount of time it takes to make thousands of thoughtful decisions on how to solve a problem.

Mass production didn’t change that. The time-consuming work just shifted to the planning, engineering, and logistics stages.

So what about mass-produced or LLM-generated code?

In software, quality also comes from taking the time to understand the problem deeply and make thousands of informed decisions. Those decisions shape how the code solves the problem.

Automatically generating code skips that time and those decisions by selecting a statistically average solution. It also skips the time it takes for a human to deeply understand the problem. The time for understanding is necessary, so that the person can make those thousands of decisions and assess wether the generated code is the best solution for the problem and its context.

Therefore, LLM-generated code is always low-quality software. It lacks the time spent understanding the problem and bypasses thousands of decisions. Instead, it selects a solution based on statistical patterns, without understanding the problem or reasoning through the choices involved.

I’m one of the few people, who are really lucky to enjoy democratic freedom at my workplace. Therefore I’m super happy, that I could share my experience of working at Mein Grundeinkommen and my perspective on democratic business design in the new book Doughnut Economics for Regenerative Business Design.

My interview is just one of 14 case studies highlighting German organisations, that left traditional organisation models behind, and embraced more decentralised and innovative models of organising work. You can download the digital version (PDF) for free or buy the print version. Enjoy!

Instead of deferring the execution of JavaScript after the <body> is parsed (by using defer/type="module", waiting for the DOMContentLoaded event or by moving the JS before the closing </body> tag), one can instead use CSS variables to represent different state possibilities in the HTML. For example showing/hiding certain elements based on the state of a CSS variable.

<span style="display: var(--show-message, none)">
  Should I be displayed?
</span>

An inline <script> in the <head> then configures the CSS variables according to some state by setting them on the <html> element. This script happens before the <body> is parsed, but once the parser reaches it, the variables already have the proper state and will therefore display the HTML accordingly.

<script>
if (localStorage.getItem('showHiddenMessage')) {
  document.documentElement.style.setProperty("--show-message", 'inline');
}
</script>

I had two use cases for this today. One was to add dynamic behaviour to cached pages from the server without layout shifts or flash of out-of-sync HTML. The other was a client-side A/B testing setup without showing the wrong version to the user and without delaying first paint.

Modern browsers have two different runtimes (JS and CSS) that can talk to each other via CSS custom properties in HTML. The state transfer can happen before the HTML is fully parsed.

Very cool! 🤯

In 2026 my website loads a webfont again! And it was created by a real creative human being. Federico Parra Barrios was inspired by the old metal plaques that can be found everywhere in Berlin (where I live). Therefore this kind of typography is very familiar to my eyes and it also has this raw and analog feeling, that I really like. So I paid the creator with my own money and put that font on my website. The font is called “Lost” and if you also like it, you can buy it yourself on 205ft’s website.

I haven’t updated the meta images to use the new font yet. But with social media becoming useless and dying because of AI generated content, it doesn’t have my highest priority to be honest. My website now looks different to all those glossy corporate bullshit AI vibe coding portfolio websites. That is more important.

Let’s make the web weird and personal again!

At least until I tested my creation in Safari, which again spoiled the fun: I wanted to implement a tooltip, which was quickly done with the new API and it worked in all browser engines. But I also wanted to add an arrow to the tooltip and thought this is another great use case for anchor positioning.

Turns out Safari doesn’t seem to support nested CSS anchors. So anchoring an element on an anchored element just breaks. The first anchor for the tooltip works, but the tooltip’s arrow never ends up, where it’s supposed to be. It works in Chromium’s and Gecko’s implementation, but not in WebKit.

Until WebKit gets recursive anchor positioning right, I warn you not to nest CSS anchors in your own projects.

This is the error that appeared in the dev tools console:

InvalidStateError: Multiple elements found with view-transition-name: some-name

This error can be fixed by declaring view-transition-name on the <img> element inside the picture tag.

When the decision was made to add syntactic sugar for (prefers-color-scheme: dark), which allows passing different values at the point of definition, why did they choose to only allow it for colors?

This breaks the shorthand for common use cases like changing the background-image based on the color scheme. And that also means, that we cannot use light-dark() in combination with gradients. I’ve refactored the CSS on my website to use it, but I’m disappointed, that its use case is very limited.

That’s why I now decided toput the navigation at the top of the page. No jumping on the page, no overlay, just a few links to click on. Keep it simple. :)

I’m still unsure about having the language switch in the footer. According to my stats, half of my visitors are in Germany, while the other half is from all over the world. I guess I’ll continue to post in both languages, randomly choosing when to use which one.

Something like this?

<link
  href="big-screens.css"
  media="(min-width: 800px)"
>

This would remove render blocking by desktop styles when mobile devices visit the website. They are still being downloaded, but don’t block the time to first paint.

I don’t know any websites that do this yet, but maybe I just haven’t found them?

Therefore I started by moving the navigation below the content on bigger screens like it already was on smaller ones. I also reduced the number of navigation items by merging different pages into one, e.g. the new projects page and good stuff page. I’ll probably move the navigation up, once I have about five items left. I’m also thinking about adding a language switch to make it even smaller.

I also thought about having just a single feed page, which combines blog posts and notes—though separate ones for English and German. I can still provide separate RSS feeds for each content type, but one feed would further simplify the navigation architecture. The problem is that I think feeds are in the end a dark design pattern. Maybe less so without algorithms, but endless scrolling still encourages spending more time on a website instead of doing other things. Maybe I don’t call it a feed and just add pagination? I don’t know.

If you are new to the whole keyboard scene like me, ordering an ergonomic keyboard comes with quite a few unknowns. I didn’t know if my choice of key switches is correct, what kind of accessories I should include in my order and how much taxes I would have to pay to ship the Voyager to Germany. Since I now have the experience of ordering one, I can give you some answers, that might help, if you also consider buying a Voyager:

• If you want your keyboard to feel similar to your Macbook’s or external Apple keyboard, ZSA’s linear switches are your best bet. I have to warn you though. They aren’t close to your current typing experience and aren’t even a good typing experience in my opinion. But compared to the other switches ZSA offers, they are still the closest to what Apple offers. I’ll explain how to greatly improve the typing experience on the Voyager later on.
• All switches from ZSA are quite loud, including the linear ones. With loud I mean a lot louder than your Macbook’s keyboard. ZSA offers a little accessory to put under each key cap, that decreases their loudness called SHHHOCS. If you care about not annoying other people with your typing, I highly recommend to include the SHHHOCS in your first order. Otherwise you’ll order them later and then you probably have to pay shipping fees. They are an essential part for quiet typing on the Voyager, but they aren’t the only one and not the most important one. More on that later.
• ZSA doesn’t charge for shipping, but you’ll probably pay additional import taxes in your country. If you happen to also order a Voyager to Germany, I can at least provide you the number from my experience. I ordered my Voyager in mid 2025 to Berlin and had to pay an import tax of ~77€. That’s on top of the normal price. Keep that in mind when ordering one.

Once my Voyager arrived I used it for a couple of days at work to see if this could become my daily typing experience. I love the form factor, the build quality, the way the key caps feel, the amount of additional key caps that they include, the carrying case and the three USB-C cables with different lengths.

Some downsides for me: The position of the thumb keys isn’t optimal for my hand size. In a resting position my thumb lies in the middle of both keys. Maybe that’s intended, but I was hoping it would rest on the bigger key. Also the medium length USB cable is too short in my opinion. It should have been a balanced length between the long one and the short one, but it’s more like having two short cables and one very long one.

These are just nitpicks though. The much bigger issue for me were ZSA’s linear switches. They really don’t feel great to type on. Plus they are quite loud. It’s not just the clicking sound of typing, but I could also sometimes hear the spring inside the switches. Yes, the SHHHOCS help to make the keys a little bit more quiet, but it’s barely noticeable since the switches themselves are so loud, that the sound being removed by the SHHHOCS isn’t even audible.

Luckily there is a solution to this problem. Unfortunately it means spending more money again. But since I already started this journey, I wanted to know how it feels like at the end, or maybe more like midway through. And from my research before going down this route, I already expected this to happen. The solution is to buy custom silent key switches from a different supplier.

What makes the Voyager valuable as a long-term investment is the possibility to exchange its key switches yourself. You can even mix and match different types. Some people for example use lighter switches for keys that the pinky finger presses. The same tool shipped in the box to exchange key caps, can be used to also exchange key switches. And that’s exactly what I did.

There are different versions of the Kailh low profile switches, which can be used in the Voyager. I already had an idea which one might be a good fit for me, but to be really sure I ordered a sample pack first. The sample pack I got included a Nocturnal switch (20g), a Twilight switch (35g), a Bokeh switch (50g) and a Sunset switch (40-55g tactile). The sunset switch is tactile and not silent, so that was not was I was looking for. The other ones are super quiet and really nice to type on.

Since I wanted to get a typing experience close to my Macbook, the Bokeh switches are what I went with, since they require a similar amount of force to press. With a little more experience on the Voyager and more accurate touch typing, I could see myself moving to the twilight switches at some point, since a little less force while typing might be even more comfortable. The Nocturnal switches are as quiet as the other two, but are way too responsive for me. Resting my fingers on the keyboard already caused pressing them.

If you live in Germany and from my experience, I can recommend keeb.supply to order your switches. They offer the sample pack I mentioned and offer free shipping for orders over 40€. The Voyager has 52 keys. I ordered 53 Bokeh switches (one as a fallback), which costs about 50€. All in all, the new typing experience cost me 375$ (Voyager and SHHHOCS) + 77€ taxes + 50€ switches.

Yes, that’s a lot of money. But considering that I spend at least 8 hours per workday typing on my keyboard and that it’s the main way of interacting with my computer for years to come, it’s not expensive anymore. I also expect the Voyager to last a very long time, probably until the end of my career, since its build quality is so good and because I can exchange the switches and key caps easily. That’s good for repairs and if my requirements change in the future.

What I got for that money is the best typing experience I had so far on a keyboard and a fully customizable typing experience, that can improve my typing comfort immensely. I will cover the whole part of programming my keyboard in a different note, because that (besides the typing experience) is the other huge improvement I got from buying a dedicated ergonomic keyboard.

While I was at it, I also simplified and deduplicated my HTML and CSS. The code is a lot cleaner now. There are still some minor places left, which could be refactored, but it’s a lot smaller now. It’s great how much grid and subgrid simplify layout code.

Watch this ad to get 10 more prompts