Musings

The Times They Are a-Changin'

Lukas Böhm — Thu, 12 Mar 2026 00:00:00 GMT

It is early March 2026. The war between the USA and Iran is still "fresh". Everyone is affected by explosions, by which I mean the explosions of prices at the gas stations. The German government releases the national oil reserves and contemplates stronger regulation on the petrol multi-nationals.

I was at the bakery. This bakery is located inside the same building as my soon-to-be-ex employer's office. So it was convenient for me to fetch my breakfast from there this morning. Surprisingly, I became witness of a situation that seemed as mundane as it was out of the ordinary. The entrance is right on a street corner, and there is no obstacles on the sidewalk in front of it. As I approached from around the corner I noticed a car placed on said corner. It was parking as defined in § 12 Abs. 2 StVO as there was nobody at the steering wheel. Yet, the engine was running. Also, the window of the SUV-class vehicle was open and radio music was audible on the street, albeit at an acceptable volume.

I was mostly taken by surprise by how surprised I was. This was a cliché on every level - everything about it should be expected. Maybe the environment was unusual. The office/bakery building is located in a slightly posh business & living area. In German, one would describe it as "links-grün versifft" (green-left-wing-filthy) yet gentrified. There is of course nothing bad to be said about the driver of this car. As I recall it, it was of German make and model. And literally everybody knows that pulling the key for just a brief stop is bad for your Diesel engine. Still I can't shed the feeling somehow that this event felt like it has fallen out time. I for one am happy that electric cars are making the tough choice between engine longevity and burning gas for no reason a thing of the past. Go ahead - park your 3 ton EV on the sidewalk any time you want.

Toss Everything At Me

Lukas Böhm — Fri, 13 Mar 2026 00:00:00 GMT

I think it is generally true that teams in companies are named after the thing they are expected to deliver. Ideally, that is simply a product name. If this is the case, the goal definition is pretty much clear: The team delivers and maintains said product. As long as the product has users, chances are that it is not being discontinued. Success metrics are clear and measurable and will include e.g. user retention, user adoption, user satisfaction etc. The team succeeds if users are happy, which translates pretty much directly into it being able to keep its backlog at a constant size.

There can also be teams named after whole product areas. It feels like things get a bit more fuzzy here. But overall I would argue that it's mostly about making the decision which products to include in the catalog for the area. After allocating resources appropriately things should in theory be comparable in lifestyle to the team named after the product. At the end of the day, it should be clear what falls inside or outside any given area, and areas in a company should have no overlap. Context switching will be a thing for the team members, though, with larger distances between the topics being the norm. For this reason, I would be somewhat skeptical of such a team setup, as it inherently signals a lack of focus.

And then there are the so-called "cross-functional" teams. Usually, they get named after dimensions of the software engineering process. In other words, aspects of software that are generally desirable in any software product. Concrete examples that would come to mind could be "QA", "Observability", "Performance", "Analytics"... A mistake I have seen people making when they come across a team named after a certain aspect is that they believe they can out-source all the work in that perceived area to this team. "We have a performance team, so it's their responsibility to solve performance in the application I have built". "A user wants to gain some insights in the data they stored in our application? Let the analytics team handle that". If you are setting up a team with a name that falls into this category, I implore you to make sure to inform everyone that the most they can expect from this team to deliver is time-capped, project-level support. As a simple fix, consider suffixing these team names with "Tooling" to bring it back into "named after a product" land.

Personally, I will take my own advice here and try from now on to make sure I do not end up in cross-functional teams any more. FWIW, the German version of "Toss Everything At Me" is "Toll Ein Anderer Macht's". This translates to "Great Another One Doesit".

Instagram Mysogyny

Lukas Böhm — Sat, 14 Mar 2026 00:00:00 GMT

I have confirmation that I am not the only person being affected, but let me quickly summarize anyways: By far the largest reason keeping me from uninstalling Instagram is its chat functionality. Sure, endlessly scrolling reels is nice and all. But on the other hand, it is liquifying my brain over time and I'd rather that happened at a slightly lower pace. Unfortunately, I'm afraid of losing access to Instagram's chat. Not because Instagram is a good platform for direct communication in any way. That couldn't be any farther from reality. To be precise, it is the social circle I have built up that's only existing within Instagram. You have to understand, my Instagram handle is a personal identifier with significantly lower sensitivity than my phone number or my email address. Well, Instagram also wins over email possibly because I'm not 50. And it's the same for most people in my generation. When we meet new people in temporary situations, like let's say on a vacation or at a festival, our Instagram identities feel like the best option to share. That's been my policy for a few years now. So by now I have a significant amount of contacts I feel at least slightly attached to that I don't want risking giving them up by deleting Instagram. I guess this alone is already a cautionary tale. But it's not the main topic I wanted to write about here today.

One thing that I recently witnessed on Instagram with one of my vacation-acquaintances was the following: Someone had made an account with a handle resembling hers and sent friend-invites to many of her followers, including me. This impersonation account was suggesting to be my friend's "secret second OnlyFans promotion account". It had a link to the OF account and all (at least I assume the link lead there, I didn't click it). Oof. Another reminder that being a woman on the internet sucks for all my fellow dudes out there. But it comes worse: The profile picture was actually her real face with a body standing near a pool, only dressed in a bikini. I must assume this picture was created using GenAI based on the few publicly available photos of her. It's frightening how easy the whole process must have been for the person behind the fake account. And yet, this could really have been very damaging to my friend's reputation. She works as a teacher.

I must also admit that in retrospect my reaction was probably not what it should have been. My first thought was not to immediately doubt the validity of this second account. I think my initial thoughts were more along the lines of "huh, interesting choice - good for her I suppose, making some money on the side". Only at the third or fourth thought I started wondering if this wasn't a bit too risky given her day job. Then, slowly realizing that this may be an imposter account, I contemplated sending my friend a message. Something simple like "hey, this you?". But I didn't even do that. The only real excuse I can give is that I was probably on the loo and cold-DMing her felt like having some friction to it. Later I saw a story on her real account where she was letting people know that this alt account was not hers. Only then I sent her a message that I was feeling for her and that I felt sorry this happened to her. I did not get a message back. Maybe I shouldn't have texted. Or maybe her head was occupied with other things at that particular moment.

This was not the first time I wasn't happy with my reaction in hind-sight. Another (female) vacation acquaintance of mine had her account hacked some months earlier. For a period of time (2 days or so) her account would suddenly promote some crypto broker or currency or get-rich-quick scheme or whatever. And here also my first reaction was to roll my eyes about her trying to make some extra money at the expense of others. I do think all things crypto are a scam. But it didn't occur to me that she might have been hacked. Instead, I unfollowed her account. I still was friends with the account of her partner which is where I eventually saw the whole story's explanation. Now I am too ashamed to send her another follow request again.

Willy Nilly

Lukas Böhm — Sun, 15 Mar 2026 00:00:00 GMT

Lots of things in software are binary, or at least we have a tendency to make them so. Sure, the bit, zeros and ones, are underlying any modern computer system. But rather than that being the root of all things to follow, I think there is yet one more level beneath it. Too me at least, thinking in binary logic is just the easiest way to think about things in general. Everyone is thinking in terms of black and white, good or bad, yes and no, ... all the time. And admittedly, this has gotten us remarkably far at this point!

Please don't take this as an excuse to stick to binary-only thinking for everything, however. I encourage everyone to challenge their convictions from time to time to see if there maybe is nuance to be had. But let's not digress.

Binary systems can represent the the real world out there at every imaginable precision. Not because they are binary, but because binary is enough to let us approximate anything to the level of detail we desire. Base-2 is enough to count efficiently, thus to enumerate things. And once we can assign numbers to (and therefore represent) anything we can think of, the rest we really care for is decidability. I.e. if a statement about $thing is true or not. I am not a mathematician, unfortunately, so I cannot academically correctly point out the concrete relationship fot his next statement. But I think the connection between decidability and set theory must be a fairly short one. Because what is set theory if not deciding whether $thing is part of $set or not? To be, or not to be, or something along those lines.

Code can be correct, or it can be incorrect, i.e. it can fall into either of two sets. The question about which is which is, unfortunately, undecidable. But we can use type systems within our programs to partition them efficiently into the "trustworthy" and "not so trustworthy" sets. Note that trustworthiness is not the same as correctness and not all programs failing to typecheck are automatically incorrect.

A rather long while ago I came across the blog post "Making sense of TypeScript using set theory" by Vladimir Klepov. While Typescript's type system has always been intuitive to me, explicitly pointing out the relationship to set theory in this post definitely helped me to get things click into place a bit better. From this post we learn that, in order to construct members of the set of trusted programs in their host language, type systems make use of set theory as well by exposing programmers to set algebra primitives. We often don't notice, though, because of how different the syntax in our programs is from... well, math really. Also, type system designers have to be generally very careful to find the right balance between ease of use, expressivity, decidability, and generally how well their idea of "trustworthiness" overlaps with "program correctness". Designing a type system is not a task to take lightly. And yet, one absurd decision in type system design has endured for decades, since the mid-60s. One, that seems incredibly hard to justify if basic logic is applied. I am talking about a decision that its original creator has acknowledged back in 2009 to have been a "billion dollar mistake". Most readers will probably know what I am referring to. But not everybody is following programming language design topics that closely. And I wanted in this post to also explain (potentially as an exercise to myself) what the mistake is about from first principles so that hopefully most people could follow along.

A lot of programming tutorials would introduce newcomers to some basic operations on numbers. They'd show you how the programming language does addition, multiplication, etc. Then they might introduce variables as a first step to parameterize the computation at hand. Later they show you how a function is declared, and finally you will have created something akin to the following:

function sum(a: number, b: number): number {
  return a + b;
}

Great stuff. A functional function that produces some sums and surely cannot ever be misused. Because the compiler makes sure nobody is calling it with anything but two numbers, right? Until some day, someone wakes up and decides to commit this war crime:

sum(undefined, undefined)

The compiler will be absolutely fine letting this one slip through (with non-strict settings in the case of TS). Because, you see, a lot of type systems have decided willy nilly to add an uninvited guest into the number type. The number type does not just include all numbers. For whatever reason there is also this weird extra guy called undefined in there. Most of the popular languages in software development still do this. If your first interaction with programming is through one of the following languages, you are confronted with a world where null/nil is just a fact of life and you may never have any reason to question it. Something like SQL, Java, JavaScript, or even Go, a language having received its first stable release in 2012(!).

Btw, did anybody check what exactly happened in our code example above? Because the fun didn't end at the misuse of our innocent little function. The language runtime designers (who are different people from the type system designers) decided to want to go wild as well and made it so that undefined + undefined produces a NaN value. This value, short for "not a number", is another value that the type system recognizes to be a valid number. Another uninvited guest to our party. But, in large parts contrary to our previous acquaintance undefined, Mr. NaN comes with bad manners, too! Somebody decided that it is the reasonable thing to make NaN === NaN evaluate to false. Also, 0 * NaN is still NaN, as is NaN / 0. On the other hand, 1 / 0 is defined to return Infinity.

What is remarkable here is that even the rust people couldn't get this right. Not because they didn't want to. The reason why they had to include the NaN-madness in their language as well for the f32/f64 types is simply that every processor in the world that is remotely modern and relevant is using the IEEE754 standard for floating-point arithmetic. And this specification unfortunately makes it so that we have all these ugly special values manifested into hardware for all eternity. So, on this front, I'm afraid to say humanity has lost.

Just like it has with NULL in the SQL standard. To date probably the largest-scale attempt to embed Three-Valued Logic into a programming system. And everyone hates it. I once proposed a tabular compute language where NULL would be treated at least so that it is equal to itself, making use of the ugly but useful IS NOT DISTINCT FROM construct. But a dear colleague pointed out to me (to great dismay on my end) that postgres cannot create indexes on that, dooming any join to be a slow nested-loop join. Concrete sources that would prove my claims here on this are sparse. I could only find this post on StackOverflow. I also remember having read the nabble post linked from there which since seems to have died and isn't available on archive.org either.

What are the alternatives to having special values added to all types, though? How should we let a caller know when an operation did not produce a (meaningful) value? The answer is sum types. In Typescript, with strict null checks enabled, the following is a perfect way let callers know about the possibility of absence of a return value:

/// Will return `undefined` if `n` is not found in `ns`
findIndex(n: number, ns: readonly number[]): number | undefined { /* ... */ }

In rust, we have the Option type, which can come in the flavors Some(value) or None. C++ gives us std::expected.

IRrigation

Lukas Böhm — Mon, 16 Mar 2026 00:00:00 GMT

As software developers, we often find ourselves in the situation that we want to convince our peers that something about some code we like should stay or something we dislike should go out or be done differently. In order to do so, we need to come up with arguments. Unfortunately, personal taste isn't a good argument, and someone's experience seldomly means anything to anyone but the person who made it. So we try to come up with arguments that appear to be objective and, even more importantly, which sound smart. Academia gives us the perfect toolkit to draw from here. And so we use phrases like "Hollywood principle", "Separation of Concerns", "SOLID", "KISS" to try to intimidate the other side and feel good about ourselves. One more element in that list is the mantra of "Don't Repeat Yourself", or just DRY in short. And yes, trying to compartmentalize common sections of code so that they can be reused, remixed and composed well is a very important part of our jobs. If every time we wanted to make an apple pie we had to build up the universe from scratch we'd never get anywhere.

Unfortunately, in practice I have found DRY to be overused by people, however. I am definitely not the only one to have noticed that, so I'll not expand on this a lot here. Maybe just a small stinger: Most of the time where I found DRY to be cited in a situation where I didn't disagree the underlying problem was that the respective colleagues just didn't have good taste / intuition about well-composing components.

What I really wanted for this post to be about is a somewhat interesting realization I had while being WET (i.e. in the shower). In my previous experiences I have found that when it comes to intermediate representations (IRs) of some data to be processed there isn't really a ceiling as to when it becomes too many intermediate representations. Fundamentally, this seems to be in direct violation of the DRY principle. And yet, compiler developers - the subgroup of practitioners in our profession we revere the most - cannot get enough intermediate representations in their compilers. Parse tree, abstract syntax tree, mid-level IR, low-level IR, target-lowered IR, assembly - these are all intermediate representations any compiled program code will go through until finally there is an executable binary produced.

It should be clear that each representation is just there to be the best data structure for a certain stage of the compilation process to operate on. Practice has shown that splitting up the process into these stages has made the overall complexity of compilation manageable. But each time, a decision had to be made to introduce yet another way to represent a program in memory on top of the N different ways that had already existed before. There would have been quite the reluctance to do so as it is anything but DRY.

Feels Good

Lukas Böhm — Tue, 17 Mar 2026 00:00:00 GMT

I only have this blog for a couple of days now. Yet, overall I am very pleased with it so far. One aspect to it is of course this feeling of doing something worthwhile and also getting better at it with each new post. I.e. linearizing thoughts into a coherent argument, doing compelling story-telling etc. All that in my second language, with no help by any LLMs (at least so far). Yes, some of my writing is clunky, some points don't come across as clearly as I want them to, yada yada. What really counts is me having the discipline to stick to it. And after all, nobody forces me to keep the "one post per day" rhythm. If I'd switch to a bi-weekly or even weekly cadence that'd be just fine as well. Actually, I have the feeling that for some of the people I want to read this blog the posting frequency might already be a bit too high.

The other half of what makes this experience so pleasant for me, however - and I don't mean this in a too self-absorbed way - is just how nice I find it to open up this blog's webpage in a browser. I only really realized it today. Of course, the theme choice I still feel comfortable with (although I should maybe consider adding a dark mode). And on top there are so many additional things which make this website feel great in my opinion. And by "are", what I really mean is: there aren't. No loading times - the page is there instantly. No cookie banners to click through. And best of all, no attention-grabbing flashy ads that stick out like a sore thumb design-wise.

I went into the browser console to check what's being loaded. And even though there is 200ms passing until the website is fully loaded, making 53 network requests overall and 645,75 kB / 163,98 kB being transferred over the network (I assume that's deflated vs. gzipped) it's just so much better than what I'm used to on the internet these days. It's really a shame what we collectively put up with. Things could be better for all of us.

Parking Lot Life (Pt. 1)

Lukas Böhm — Thu, 19 Mar 2026 00:00:00 GMT

I started my working career in April of 2019. I had just finished my master's degree, thought the world was my oyster, and had very leftist political opinions. In hindsight I must say that I was unbelievably lucky to have graduated at this particular point in time. While I can't recall the overall economic situation, at least in software the job market was great. Originally I had plans to go abroad for my first job as I didn't have the chance (or if I had I missed them all) to spend time abroad during my studies. However, I wanted to go to an English-speaking country which didn't just leave the EU and was close to home in case something would be happening to my grandparents. So basically I had narrowed down my options to Ireland. In addition to that, I wanted to find a job in compiler engineering. So even given the circumstances, it proved a bit hard to even find one position that matched these requirements. Time passed, and eventually even the 5 months I had given myself to transition from student life to working life were coming to an end. Long story short, at some point I dropped all my demands and just wanted to find something close to where I already lived, as long as it was at least in my favorite programming language of the time, C++. That turned out to be much easier, and after a short while I found myself being accepted at a huge corporation for an entry level position. The only catch was that this company had its offices in hicksville, 35 minutes train ride from the city I lived in. The audacity! Wasting almost 2 hours of my valuable lifetime each day just to get me to my day job was unacceptable. Buying a car - also unacceptable. I would not sell out on my values of a green lifestyle like that. So should I move to this small forsaken town? Absolutely inconceivable. None of my friends would live there. And given the size of the company I worked for it wouldn't even be cheap as all my colleagues were competing for flats. Since I could live in my student dorm for a couple more month before the were going to kick me out I had some time still. But I had to come up with a plan. And so slowly an idea was forming within me. "Society is pampering car owners in this country so much anyways" I thought. Prime real estate given out for free everywhere just for people to place there private steel enclosures on for 90% of the day. Maybe I was stupid not to take advantage of this. As the newbie, I was placed in a 4-person office room together with my manager. One day I asked him if he thought it possible for me to just live in a van on one of my employer's many parking lot. He thought I was joking and found the whole idea very funny. But he didn't say no, or rather he said something like "don't see why not". That sure as hell was enough for me. It sounded genius on paper:

I'd have zero commute
Instead of paying rent I'd pay down on owning my van
I'd be free to go wherever on the weekends
I could use my employer's bathrooms for all sanitary demands for free
If need be, a gym-chain membership would also give me access to showers and bathrooms in different cities in the region
Washing I could do at friends/family/laundromats
I would trim down significantly on personal belongings, basically to just the essentials

Almost too perfect. People around me of course could come up with some aspects of my envisioned lifestyle that might be inconvenient. There were, however, no arguments that seemed grave enough to me to deter me from pursuing this plan. And so I put down a 20k€ down payment on a 57k€, 1 year old Volkswagen California Coast in July 2019. An enormous amount of money, very much absurd to be honest. The reasoning behind me going with such a fancy car, however, were these: The Volkswagen / Dieselgate scandal was still very much present in everyone's mind at the time. I didn't feel like living in a "historic" 30 year old+ car to be freed from any legal requirements. Yet I also didn't want to find myself excluded from driving into certain areas because my car was causing too much air pollution. So in my mind I had to go with a fairly recent model. I also wanted my van to be inconspicuous and not too impractical for everyday usage. Entering parking garages would ideally still be possible. So the California-series delivery-van base paired with a fold-out roof seemed like the best option to me. I can't tell exactly any more why I didn't look at other manufacturers' offerings. I believe the Ford Nugget-based version didn't seem to allow sleeping in the main cabin but only on the fold-out roof level. Maybe I also didn't trust brands like Opel or Fiat very much. I can't really tell any more.

And so, after having picked up my new home on a Friday afternoon, one hot Sunday evening in the mid of July, I finally found myself spending the first night on my employer's parking lot. This adventure ended up lasting 7 months. There were many lessons I had to learn and overall I think it was a very formative experience. But to go into more detail on it I shall be doing another time, in a second part of this blog post.

On Health Insurance

Lukas Böhm — Fri, 20 Mar 2026 00:00:00 GMT

This morning I had my regular dentist appointment. It didn't turn up anything noteworthy. I don't floss well, so there was a bit to do for the dental technician to get my teeth cleaned nice and well. Maybe I'll improve my floss routine for the next few weeks a bit again just to gradually have my motivation for it fizzle out afterwards. On the bright side, I don't have cavities. Overall, my dentist always expresses satisfaction with my overall dental health. I do have what he calls "abrasions", though. That's because I clench my jaws while I'm asleep - probably also when I'm not asleep. But at night is just the most convenient time to put in a dental splint as I have a habit of not eating or talking during that time. The check-up appointments with my dentist usually also serve for letting them have a look at the state of my bite-guard. This led to a slightly awkward situation for me as I had to tell my doctor I had decided to move to some generic product from the internet over the custom-made appliances he had hooked me up with the previous years. You see, in 2025 I bit through a total of 3 separate splints. There is a point to be made just about the sheer amount of plastics I swallowed because of this circumstance. But the real reason behind me looking for alternatives was the price point. On Amazon, I can get a pair of bite guards for 20€. That's 10€ each. And those aren't even the cheapest option. I just went with them because they somehow seemed a bit more trust-worthy than the others. Generally speaking, however, I don't have high standards. It's fine for me that they are bulky - I can get used to that. To be honest, at the rate I bit through the professionally-made models my doctor anyways went with thicker and thicker models. They are also more rubbery, so I think there might be fewer parts coming off that I will swallow at night. Amazon also has fully custom-made ones for less than 100€ on offer for anyone that is skeptical of the generic thermo-plastic ones. Now compare that to what the dental guards I got from my dentist cost me: Each one came in at around 450€, putting me at roughly 1350€ for one year. That is 45 times the amount I now pay for the one from Amazon. And so far, they seem to have similar durability. It's still 4.5x the amount of custom-made "free market" offerings. It just didn't seem cost-effective to me to pay this much money for something that might as well just be a piece of wood to keep my jaws separated.

At crossfit I have a buddy who works as a dental lab technician. When I told him about my struggles and that I would go with a dental guard from the internet he was surprised. "If it's paid by the insurance anyways why even worry about the price?" he asked me. I pointed out that I get to pay the money out of pocket (at least initially). But even if that wasn't the case, the money would need to come from somewhere. Insurance companies don't print Euro bills in their basements to my knowledge. For a while now, there has been an ongoing discussion in German media outlets that our health system is too expensive. Well, German health insurers are complaining frequently and premiums go up every so often that it's hard to lose track of the topic. Let me quickly outline the situation as it presents itself to regular citizens like me. At the core of the German health system is the division between public health insurance and private health insurance. Employees must have health insurance, so most of us Germans come into contact with the system. There is multiple options on either side of the public/private divide that can vary in what services are covered under insurance and other bonus programs. However, you are only free to choose to go into private health insurance if your yearly income exceeds 77,400€ (as of 2026). The most noticeable differences in everyday life between the two forms are:

Doctors are more happy to take you when you have private health insurance because the can ask (AFAIU) up to 2.3x the price for the same service as they can bill publicly insured patients.
For publicly insured patients, doctors are interacting directly with the insurance company to get compensated. If you are a private patient, on the other hand, the first recipient of the doctor's invoice is you and it's also you wiring the money to the doctor, not the health insurance. You will ask your insurance to reimburse the money to you.

Point one indicates there is a pricing catalog for each form of therapy doctors can prescribe and enact to their patients Everyone doctor only can ask a certain amount of money for a procedure because every insurance is only going to pay exactly what is written in that catalog. And yes, this system is absolutely causing certain procedures to be over-prescribed.

From point number two you can already derive which category of insurance I am in. While it is more inconvenient, I do think being able to see the invoice and having to act on it is a good thing. It influences personal behavior and reduces the risk for mistakes or even fraudulent invoices. On the other hand, private health insurers also need to validate incoming reimbursement requests, potentially leading to more effort and costs on their end. I hear that the newly rolled-out German electronic health record service also has a feature to access the invoice information. It may be doubted, though, whether without any active involvement in the invoice settlement process people will look closely at what doctors are billing their insurance.

But aside from a more or less believable spend control aspect, why is the German health insurance space designed the way it is? I didn't research this really, but the availability of different companies to choose from indicates to me that the idea is to somewhat bring market dynamics and competition into the space. As was brought up earlier already, with everything being priced according to a centrally defined catalog, this is kind of a tough goal to achieve.

Personally, I was never with an insurance that my parents hadn't already picked for me, though. Maybe that is just due to my own laziness, however.

So, from what I understand, once you cross a certain income threshold, the government starts trusting you enough that you can graduate from a fully-imaginary toy market to a slightly-less-imaginary toy market when it comes to choosing your health insurance company. I will freely admit that, politically speaking, I am an opponent of egregious over-spending. I also believe in the concept of distributing life's inherent risks across all members of society fairly. Phrased differently, nobody should die of a curable illness because they are lacking the money for medication. But in between, there is a wide spectrum of cases that are not as easily categorized into one of the two extreme ends "preventable death" vs. "unnecessary over-spending". To bring these two points into balance, sure, why not try with a market model to rationalize spending if possible? E.g. Prophylaxis is an area that also makes an extreme amount of sense - invest small earlier to prevent high costs later. Economics is telling us clearly that overspending on prevention on the individual level statistically amortizes across the whole population. Unfortunately, applying statistics quickly gets us back into unethical territory. It hasn't been too long ago that women in private health insurance had higher premiums than men just because of their gender. Only in 2013 the European supreme court ruled that health insurances always have to follow an "Unisex Tarif" model. So, apparently health insurance companies are in most cases restricted from performing risk analysis on their customers. Unlike with banks, I don't think there is much money to be saved in service costs if the company restricts itself to only customers that know how to use the internet. I may want to research this, though.

Speaking of things I want, I don't know where I want to go with this. I don't think there really is a market, nor do I think there should be a market for how we handle individual health matters. What I believe to be true is that it will always be the case that more money buys you more. In a world where all the patients that are now in private health insurance were to be merged back into public insurance it is still very conceivable to see private extra insurances becoming the norm to have access to better treatment. Sure, one could try to forbid this by law. Then only the very rich who can afford private doctors (and maybe people with connections or unafraid of bribery) will have preferential treatment. But I can't even tell you if I think that is an improvement over what we have currently.

Postal Voting

Lukas Böhm — Sun, 22 Mar 2026 00:00:00 GMT

Voting by mail has taken my heart by storm in 2021. Germany was about to decide the successor of Angela Merkel after 16 years of CDU. "Fridays for Future" was still very popular. The smell of change lay in the air for everyone to notice. However, it was clear that the effects of the COVID-19 pandemic would still cause complications to this national election. At least for me, it was out of the question to show up in person at a polling location. Those should remain reserved for the old and vulnerable that didn't know how to cast their vote in other ways. So for the first time in my life, I registered for voting by mail. During the few elections I had been allowed to take part in before I believe I thought it more cost-effective for society to throw off my ballot in person. This time, the circumstances just didn't allow it, though. I don't really remember the details of the registration process any more. But it must have been pleasant enough to completely turn me over as to this date I have never voted in person ever again. Nowadays, when I get the election notification, there's already a QR code printed on the letter. Scanning it leads me to a page where I fill out a couple of input fields and 3 days later I have all the required documents to vote by mail.

In 2021 this led me to have been done with the election weeks in advance and causing me to actually be surprised when election day finally came. Since that date didn't have any significance for me any more I felt free to plan a trip around that time. And so it happened that I was actually in Berlin on that particular Sunday. Me and my companions took part in the last Fridays for Future demo in Berlin. If memory still serves me right it was one of the biggest ones. On our way back to our accommodations we even met a famous politician of the Green party doing campaigning. I was completely star-struck which was slightly awkward. However, she was very nice and gave me pin wheel that I keep in one of my flower pots to this day. On the Sunday itself we actually wanted to leave Berlin which proved to become quite difficult. Some geniuses hat planned the Berlin marathon to fall onto election day and most roads leading out of the city were closed. This was so troublesome, in fact, that in some locations voters were unable to vote because ballots couldn't be brought in on time and some of the affected areas' elections had to be repeated later. As a mail-voter, this of course affected me in no way whatsoever. It sometimes surprises me to learn that so many people still vote "the old way". While the overall share of mailed ballots still rises (ignoring out the COVID outlier) with each election according to the German election administrator, it's still almost two out of three voters voting at the station. I do see the appeal of getting to see the local elementary school from within and not having to trust the postal system. Maybe I also don't want to miss out on all the dirt that gets dug up until the very last day of campaigning. But are these the only advantages? Because on the other hand I see

having the clear conscience of already having performed my civil duties weeks in advance
not having to be anywhere specific on that particular Sunday
not having to wait in line
having all the time in the world to fill out the ballot at home, rather than blocking a cabin
if you die between sending in your ballot and election day, it still counts!

These arguments in my view more than make up for the downsides. Am I missing something?

This is a bit like the recurring discussion about nuclear energy. I just have no idea how anyone can still justify even throwing the idea of new nuclear power plants out there. Do I live in a bubble where all the cited draw-backs are just imaginary? If you have credible answers to any of these two points, please feel invited to reach out!

VPS YAGNI

Lukas Böhm — Mon, 23 Mar 2026 00:00:00 GMT

The technical setup behind this blog is is incredibly effective in my opinion. When I want to add a new post, all I need to do is to log into my Github account, create a new markdown file in a certain directory of my blog repository and commit it to main. Apparently, I could do this from the Github app on my phone - although I didn't test it as it didn't seem obvious to me if this is committing the file right away. Editing is also possible, albeit probably not the greatest experience in practice. I would prefer having a preview mode before publishing a post. However, if on the go, this is a viable option. Once a new commit hits the main branch, some simple Github actions workflow is run to have the static site generator (Astro) do its thing and deploy the result on Github pages. I don't even have to worry about the SSL certificate for the webpage, as Github is taking this over for me as well. Did I mention yet that my blog has a commenting feature that is using Github discussions in the background? That is powered by the excellent Giscus.app. I don't have to worry about the server side of hosting this blog one bit - everything is being taken care of by Github. And the craziest of all things is: It's absolutely free.

Yes, this won't come as news to my technically versed readers. But I wanted to contrast this to what I was considering to do before landing on this solution. I don't think I would have if it wasn't for a very dear colleague of mine. I've been paying my hosting provider for a very long time now for two different services:

The domain hallobitte.com
A Virtual Private Server (VPS) that I shared with a friend from university

So when earlier this month I decided to start blogging, my instinct was to make use of both. The only issue was: I absolutely dreaded getting familiar with the state of my v-server again. Back when we set this up, I was a nerdy student with lots of time. So of course I went with the same Linux distribution I used on my laptops and desktops: Arch. Because nobody got time to go through a major version upgrade every one or two years, am I right? Unfortunately, I made a couple of mistakes:

Early on, I installed Gitlab on this VPS. Not in docker like a sane person. But using AUR build scripts instead. This basically taught me that software updates needed to be supervised, because something about this setup would break almost every single time I did an update.
So I never set up automatic updates. AND I didn't really like doing them regularly. So of course I fell behind "quickly". Right now, this VPS has an uptime of more than 1500 days(!!!). People using Arch Linux likely know that, at this point, one just cannot update any more to latest packages. Doing a full reinstall is the most time-effective solution here.
Unfortunately, as I am sharing the VPS with a friend, I can't just wipe everything and start from scratch. My choice of Arch Linux always meant I would be doing the base system administration as he mostly works with Debian/Ubuntu servers professionally and otherwise stays in Windows where possible.

Something had to be done to get out of this whole mess and towards something better™. But what would that be? Well, ideally a Debian base, of course. And the other thing I wanted was visibility for our individual deployments and entailing configuration changes for shared resources. Put more simply, I wanted to have a web ui to configure what had been nginx config file changes and systemd units in our existing server. Because at the end of the day, all we want to do is have some things in auto-start that get properly exposed exposed on the internet, either multiplexed via http or via port mappings. I asked an LLM if there was a solution for this and it told me to have a closer look at coolify. While I found it a bit off-putting to see that this was written in php, I guess it would have fit the bill? But then I'd have needed to solve getting my blog's markdown files into docker containers first I suppose. Possibly not the low-friction entry I was hoping for. I did take the opportunity, though, to dig a bit into the technical terms I wasn't intimately familiar with that I kept seeing floating around in the docs. For example, one thing I realized is that what we nowadays deploy as containers behind traefic used to be just processes behind fast-cgi. Communication has just shifted from local sockets to http and of course we have better isolation and possibly scaling options. But in my VPS use case, it's pretty much that. I think the effect that understanding this had on me wasn't much other than just feeling old. Oh well.

Today, I shared my blog with another colleague at work. You should check him out. One thing he was reminded of reading my earlier post Feels Good was this old but great post by James Somers. It made me think whether I'd ever had gotten to anything resembling a blog with posts if I had pursued my impractical initial ideas. I am grateful it has turned out the way it has. I want to say a big Thank You to Benni for pointing out to me that I didn't need any of the VPS shenanigans I outlined above - I couldn't be happier with the setup I have now.

While I'm at it, I also want to thank Stel Clementine for sharing her blog's template open source. We don't know each other. But your work was the second biggest factor to get this blog off the ground to my satisfaction in an incredible small amount of time.

Intercompany Feelings

Lukas Böhm — Thu, 26 Mar 2026 00:00:00 GMT

This post's title is misleading and that is exactly why I chose it. This is not going to have anything to do with anthropomorphized enterprises getting into bed with each other (although that does sound like a lot of fun as well). But rather, this post is about my feelings at this moment where I'm in between jobs. It would be disingenuous to this blog, my readers - most of whom are (ex-) colleagues -, and to myself not to address my recent departure from my previous employer in some form.

I've been with this company for three years and eight months. A lot of things happen during such an amount of time and it has definitely left some marks on me. I learned a lot, be it about technology, myself, or office politics. I also had the pleasure to meet a whole lot of cool and interesting people from different backgrounds and cultures. Finally, I also leave behind the things I have been continuously working on for several years. Things I created, maintained, and helped shape. There are definitely many aspects I am going to miss. On the other hand, I have to admit that it is immensely freeing to be in the position to cut some ties. Just having the option to switch to something new, back in that moment I felt a sense of agency I can hardly describe.

Interestingly, three-and-a-half'ish years is also about the same time span I worked in the first job I had after uni, the one right before this one. A somewhat obvious question to arise here is therefore whether I should worry about an emerging pattern. Frankly, in both instances I have actively been starting to look for new positions. That means in each case the underlying reason can be clearly attributed to some sort of dissatisfaction. Am I growing dissatisfied after 3.5 years, is that it? I find it somewhat hard to imagine that anything I don't actively put my focus on would go on over a time horizon this large. Then again, I have no clue how emotional account keeping works.

What I do know, however, is that not all factors of dissatisfaction are created equal. I would say the reasons behind me leaving my first job vs. my second one were quite different overall. If I wanted to phrase it poignantly, maybe I would say that in the first job I saw too much perspective whereas in the second I eventually saw too little. I.e. in the first job I was given the impression I could do anything, anywhere. I was the rock star junior dev in my team, and that might have gone to my head. "So why would I keep doing it here?" my younger, over-privileged me thought. Now, with the job I just left, I rather ended up not seeing any more potential for where I could go next to grow. That's why, in my head, I had to try to find my luck elsewhere. And by the way, that is still what I am out for! Finding luck, i.e. a place where I can feel happy at for a long time.

I do not find the process of changing jobs enjoyable at all. It's probably also not getting better any time soon in the current economic and global political climate and AI coming after all of us. And I think I have to consider myself very lucky landing my next job with the amount of effort and time investment I spent. Without checking the details, I believe what it took was roughly 2-3 months, sending out somewhere in the ballpark of 15 or so applications. I only got into the interview stage with two of the companies I applied to, though, one of which made me the offer I ended up accepting. Not a slam dunk, and far from a pleasant experience. The amounts of time I innocently pulled up my phone randomly to look at god-knows-what, seeing an email notification and then getting hit by a rejection mail out of the blue were just brutal. But I was also still far from hundreds of monthly applications with no response at all as I sometimes hear about.

Leaving my previous safe haven by resigning from my job was taking on a risk. New probation period, new and unfamiliar working environment, new routines to adapt to because of a different commute. But I am hopeful it will pay out. I get to see what others have been working on and get to learn new ways of doing things. On the other side, I will try to bring in my skills as best I can to prove myself and pull more than my own weight. I will meet new colleagues which will show me their unique perspectives and I hope to be able to contribute some of mine. And I will have new pathways open up to me which will shape my way going forward. It is quite exciting if I'm being honest.

We Have Visitors

Lukas Böhm — Mon, 30 Mar 2026 00:00:00 GMT

In my third semester at university it was compulsory to participate in a practical course on software engineering. For that we were assigned into groups of five and given the whole semester to work on one of several different software projects. My group got the task to develop an app that should teach the basics of lambda calculus to children by portraying abstractions as alligators and variables as their eggs. This idea was based on a post by Bret Victor. While it was a bit quirky, the app we created came out quite nicely and satisfied our advisors to the degree that we were asked to present it during an open house event of our university. It's still possible to find all the code we wrote during and after the project on github.

As part of the implementation process, we had regular check-ins with our advisors where they would give us some guidance on how to structure the coding process and the code itself. One of the lessons from that time included the tip to use the visitor pattern. That was where first I learned to appreciate this pattern and to this day I think it addresses a very important issue in software engineering in a clever and arguably elegant way. However, I encountered some ... disagreements on what this pattern is and isn't in my professional career since then which has somewhat dampened my enthusiasm for it. I have also found that it can be "dumbed down" a bit in practice to make it more obvious what's going on. But before I elaborate on this, let's first take a step back and quickly reiterate the problem the pattern is intended to solve.

:::note This is of course my understanding of the pattern. I think in all instances where people were of different opinion they were arguing that there was more to it than what I believe it should boil down to. I will address these "omissions" later in my post and why I think it does not make sense to entangle them with the core of the visitor pattern. :::

Wikipedia says the following about the visitor pattern:

A visitor pattern is a software design pattern that separates the algorithm from the object structure. Because of this separation, new operations can be added to existing object structures without modifying the structures.

I think, speaking abstractly, this is actually a very good and concise description of the pattern. However, maybe we can be a bit more concrete by going through a practical example. Let's assume we are modelling an animal shelter. There are a couple of things we need to be able to do with the animals that are brought to our attention. For example:

house animals depending on their needs, i.e. putting them in an aquarium if they are fish etc.
feed them
healthCheck them
give them specialCare in regular intervals
...

This list will grow for sure once we actually get into business. But we have to start somewhere. The intuitive first solution might be to make all these operations available as methods on the Animal interface that all animals have to inherit from. Unfortunately, this causes a couple of problems. First off, we don't own all the implementations of animals in the world - nature does. So we can't just enforce all animals to implement our custom interface. Secondly, it will cause quite some noise in the animals' implementations to implement all our operations and a lot of churn every time we need to modify or extend the operations we need to have available to run our animal shelter. What we need, and Wikipedia already said it, is to "[separate] the algorithm from the object structure".

But next we run into a different problem: We of course want to continuously make sure that every operation we are regularly going to need is supporting all the different animals that our shelter supports. Ideally, once a new animal is brought to us that we haven't seen before something should make sure we cannot forget adding support for it in all the necessary places. As for all things that we want to be ensured in our code, that something that checks it should be the compiler. So we need a way to let our operation coding signal to the compiler which animals it supports so that it can figure out when there is something missing. Now this is the place where - in the classic visitor pattern - an interface comes into play. For each animal variant there is going to be a visit function in the interface that communicates "I, the operation, know how to visit (i.e how to deal with) this particular animal".

In code, this could look somewhat like this:

class Cat {}
class Dog {}
class Fish {}

interface Visitor {
  visitCat(cat: Cat);
  visitDog(dog: Dog);
  visitFish(fish: Fish);
}

class HouseAnimal implements Visitor {
  visitCat(cat: Cat) { return 'cardboard box' }
  visitDog(dog: Dog) { return 'kennel' }
  visitFish(fish: Fish) { return 'aquarium' }
}

Now there is just one final piece missing. Namely, how to bring arbitrary animal instances together with their respective method implementation in the visitor-based operations. The solution to this is called "double dispatch". Quoting from Wikipedia:

double dispatch is [...] a mechanism that dispatches a function call to different concrete functions depending on the runtime types of two objects involved in the call

In our case, these two objects are 1. the animal instance and 2. the operation instance. The second one we of course get for free in most languages - calling the visitCat function of a HouseAnimal instance is trivial as long as we know the operation we want to use is indeed HouseAnimal. And even if we didn't know which Visitor implementation we have at hand, most modern programming languages conveniently hide the dynamic dispatch in the background for use. Dispatching based on the animal instance is the harder part. Back in university, we were taught that using instanceof is super bad. Honestly, if you keep your inheritance hierarchies flat (as you should) I don't see a big issue with it, though. So our first option would simply be something like this:

type Animal = Cat | Dog | Fish
function dispatch(animal: Animal, visitor: Visitor) {
  if (animal instanceof Cat) {
    return visitor.visitCat(animal)
  } else if (animal instanceof Dog) {
    return visitor.visitDog(animal)
  } else if (animal instanceof Fish) {
    return visitor.visitFish(animal)
  } else {
    throw new Error(`Unhandled animal: ${JSON.stringify(animal satisfies never)}`);
  }
}

IMO, this is perfectly fine as long as we have the satisfies never guard in place there, making sure we handle all kinds of incoming Animals.

If we allow ourselves a bit more extra information on the "object structure", we can also go e.g. with type tagging:

class Cat { readonly type = 'cat' as const }
class Dog { readonly type = 'dog' as const }
class Fish { readonly type = 'fish' as const }
type Animal = Cat | Dog | Fish
function dispatch(animal: Animal, visitor: Visitor) {
  const { type } = animal
  switch (type) {
    case 'cat': return visitor.visitCat(animal);
    case 'dog': return visitor.visitDog(animal);
    case 'fish': return visitor.visitFish(animal);
    default: {
      throw new Error(`Unhandled animal: ${type satisfies never}`);
    }
  }
}

TS Playground

If we have even more influence on the definition of our object structure, we might even want to do what we got taught in university:

class Cat {
  accept(visitor: Visitor) {
    return visitor.visitCat(this)
  }
}
class Dog {
  accept(visitor: Visitor) {
    return visitor.visitDog(this)
  }
}
class Fish {
  accept(visitor: Visitor) {
    return visitor.visitFish(this)
  }
}
type Animal = Cat | Dog | Fish
function dispatch(animal: Animal, visitor: Visitor) {
  return animal.accept(visitor)
}

TS Playground

However, I don't like this too much for a couple of reasons:

There is a relatively meaningless extra function on the public interface of every animal
The object structure now needs to know about the Visitor interface
The dynamic dispatches in both animal.accept and visitor.visitXYZ do quite some heavy lifting. This can be confusing to readers. Furthermore, they aren't "free" if you care deeply about performance
Dynamic dispatch does not work well with generics. While not shown in the code examples above and not really an issue in Typescript, generally it is desirable to be able to choose the return type of an operation freely. In languages where generic code gets instantiated on each type parameter assignment it is generally not possible to also have it be the target of a dynamic dispatch.

Especially point number 4 makes it really hard to recommend this approach. Personally, I'd rather go with the type tagging approach instead. Check out this code on TS Playground for a full-fledged example.

So this was a quick run-down of what I believe the visitor pattern is largely about. Where might others have different opinions on this?

The first argument I could think of here is how much centralized knowledge there needs to be regarding the shape of the object structure. I have seen people argue that it should be possible to completely do without listing all the animals in a single place. I.e. in my code examples, the following should ideally disappear:

type Animal = Cat | Dog | Fish

Also, maybe the visitor interface could be rewritten to more simply state that it can deal with all kinds of animals. So something like this:

// This is now a base class
class Animal {}

interface Visitor {
  visit(animal: Animal)
}

I will admit, if you move the goal posts far enough, something like this can work for varying definitions of "work". Of course, initially it seems a bit absurd to assume some operation can work generically over any kind of animal it has zero knowledge of. And that is kind of the contract we have been given here, right? All that an implementation of Visitor may assume on its argument is that it subclasses the Animal base class. But what if we never wanted to handle all possible incoming variants of animal but just the ones we explicitly know and care about? Of course that is then a totally different problem from the one we started with (being an animal shelter for all animals brought to us, accommodating our code if needed for any newcomers). Then basically what we want is to null-route or reject all the things we don't want/care. That is fine - but I wouldn't call it a use case for the visitor pattern any more. Luckily, I've only come across this opinion once in my career.

The second understanding of the visitor pattern which diverges from the one I laid out above has been much more prevalent, however. I've seen this three or four times across different code bases now minimum. I attribute it coming from the general setting the visitor pattern is usually employed in. And that setting is graph or tree data structures. In the app we programmed, our domain object structure with alligators and eggs really was a model of a syntax tree of lambda calculus. And whatever operations I wanted to perform, I usually didn't just want it to be performed on individual nodes in that tree but rather the whole syntax tree. So in addition to acting on node types, I needed to traverse the tree and keep track of inter-node relationships. And there is where I think a mistake is easy to happen: Conflating tree traversal with node-type-based dispatch (the thing the visitor pattern solves). Wikipedia list 3 * 2 = six different ways to traverse (binary!) trees. To me, that is a big hint to try to encapsulate the complexity inherent to this somewhere separately. In other words, if your visitor ends up having dedicated visitBeforeChildren, visitBetweenChildren, and visitAfterChildren callbacks, I think you are doing it wrong. I do understand that sometimes it needs to be possible to inspect the current traversal state in order to make the decision. And if this works for you who am I to tell you to do it differently? I just find that knowing that you have tree traversal and type-based dispatch as two distinct problems on your hand may lead to code that is structured more clearly and thus better to reason about.

FWIW, I coded up a slightly more complex application of the visitor pattern including a tree and state-tracking depth-first traversal in this playground example. I hope you could find this helpful.

Cheers!

Visiting The Hague

Lukas Böhm — Thu, 09 Apr 2026 00:00:00 GMT

It is starting to become a tradition for me and my significant other to do a nice little trip over the Easter holidays. My girlfriend is more into nature than cities, which sounds like it might narrow down the list of possible destinations but really doesn't. Turns out living in the center of Europe makes it possible to reach a wide variety of places and landscapes within reasonable time. One year ago, we went to Saxon Switzerland, the area around Dresden in eastern Germany. Given that this was a more mountainous region, this time we set our eyes on reaching the sea. And, because ever since I visited Rotterdam a couple of years ago I became a fan of the Dutch coastal region, we eventually settled on visiting The Hague in the Netherlands this year.

Neither my girlfriend nor I own a car. But from experience I also knew that taking a train would be taking long, would be cumbersome, and would limit our flexibility when there. That's why we chose to rent a car from the car sharing service we both are subscribed to. In particular, we opted to take a VW ID.3 pro. I had driven the Cupra Born the also have on offer in the past before and both cars share the same technical foundation. So I didn't expect there to be much of a difference. In hindsight, I can't tell if it was just because of familiarity, but I'd say maybe the VW felt a bit "nicer" on the road.

Overall, we were traveling from 10:30 to roughly 18:00 on Friday to get from Karlsruhe to our hotel. However, this included a short stop at my place in Heidelberg and two or three charging stops, one of which we combined with having lunch. We opted to book a somewhat more fancy Hotel (at least for our standards) which was located right at the beach. It even came with a sauna and infinity pool in the top floor. Additionally, we booked the breakfast buffet for all of the 3 days of our stay. The car we left in a close by garage which we paid for upfront. That was around 80€ for the 72 hour tariff. After check-in and settling into our room it was already getting dark outside. So we only did a small stroll along the beach. It was also extremely windy. This can even be seen on the cover foto of this post!

The next day, Saturday, we got up somewhat early and decided to take the tram into the city. Similar to other cities like e.g. London you don't need to worry about getting a ticket prior to boarding. One can just tap in and out with the credit card using dedicated terminals near the doors. Once we arrived in the city center, we found ourselves near a small market. One of the stalls there was offering freshly hand-made Stroopwafels which we had to try. These were quite amazing!

After exploring the city center a bit more my girlfriend booked us a boat tour over the Grachten. This was, unsurprisingly, an excellent idea. We had a delightful tour guide telling us all kinds of facts about the city and its buildings while we were cruising over the water. Gracht bridges don't have much clearance so we regularly had to duck in order to not bump our heads against one of them.

By the time the boat tour had completed it was already close to 4pm. Some of the smaller museums we were thinking of visiting were already closing by that time. We still wanted to try our luck at the Mauritshuis, however. While the length of the waiting line ended up a bit off-putting, I did see a former colleague standing in it. What a coincidence! Unfortunately he didn't see me, but I texted him and we could verify that it really was him.

After having decided that Sunday was going to be our museum day we decided to head back to Scheveningen, the quarter of The Hague at the coast where our hotel was located. There we went top the area around the Kurhaus, the "seaside resort". My girlfriend had some Kibbeling for dinner while I was having some fries. Afterwards, we also walked down the pier and ended up hopping onto the ferris wheel.

Finally, we made our way back to the hotel after a long walk on the beach where we checked out the spa amenities on the top floor. A beautiful sunset topped off this very much perfect day.

Sunday we again got up rather early for our taste. After another extensive breakfast, we made our way back into the city, noticing that the city was still rather unpopulated. Our first stop was the Mauritshuis which we had already been close to visiting the day before. It's an old building with a modernized basement turned into a reception hall and three stories filled with 300 year old paintings. While initially I admired the skill with which these artworks had been painted, I grew number the higher up we got during the tour. This was very unfortunate as we only got to see the most famous paintings at the very end. On the bright side, my girlfriend bought me a new pair of socks in the museum merch shop depicting "The Anatomy Lesson of Dr. Nicolaes Tulp" by Rembrandt.

Once we were done with the old paintings we continued our way to the Escher museum to get to see some less-old paintings. I really admire his work, both aesthetically as well as from how complex it is. His works were also extended by some information about the palace the museum is housed in. Overall, the size and scope of this museum better matched my limited span of attention.

Unfortunately I started feeling quite ill roughly at the beginning of our visit to the Escher museum. While the symptoms receded after a while (or rather I heroically pushed through them) I was a bit spooked and we decided to cut the day shorter than we initially had intended. We still grabbed a small lunch in the city and got some groceries for later but decided to head back soon afterwards. Dutch people not giving a damn about Sunday or Easter and still opening their shops be praised! Luckily, the weather was great and we could have yet another nice walk on the beach before I ended up laying in bed for the rest of the day.

Finally, on Monday, we had to get back home. But of course not after having one last big breakfast from the buffet and spending just a little extra time near the beach.

What I have left now after an absolutely amazing weekend is some wonderful memories and a cute fridge magnet in the shape of a bicycle - and some small souvenirs from the famous coffee shops they have over there ;)