12 Jan 2024
As the weeks pass by after finishing this book, I realise more and more how perturbing the experience was. It’s like a lingering nightmare from nights gone by which looms every night, threatening to return while you sleep, to terrorise your dreams with a complex distorted reality of cold, coats, toads, rabbits, cows and “the other side”.
The Discomfort of Evening, known in Dutch as De Avond is Ongemak written by Marieke Lucas Rijneveld, is a whirlwind to say the least.
It is an easy read which is a pro, full of ample descriptions of this world which is described which is so visual yet so drab and gray, I can imagine the featureless landscape, as I write this looking out the gray skies of Belgium on a winter morning. I can picture the mud, the fields, the cows, as when I run long distances I often stumble upon many farms, with the cows grazing, often looking up at me as I run by and then returning to their rumination. I always wondered what kind of people live in these farms, how do they live their lives, and this book gives a portrayal of a glimpse into this life, albeit heavily distorted by the family’s circumstances.
Speaking of rumination, I still can’t digest this book. It is an endurance run of pain or a marathon of grimness, every page gray and drab, a bitter or metallic taste in the mouth, like blood. This is not to say it is badly written, as the language and the story carry beautifully from page to page, similar to how the monotonous voice of Charlie (aka MoistCr1TiKaL) on his YouTube channel delivers his videos, starkly honestly without a facade, direct, blunt, piercing. In this same light the book reads like an honest down-to-earth journal, narrating the smallest yet nastiest intricacies of the daily life of a troubled family in a run-down town in the middle of nowhere in the Netherlands.
I have mixed feelings after reading this book. Marieke crafted a world so unique that if it wasn’t for the mention of a few real world characters I swear it could have been about a run-down farm in Russia or Thailand, or Mars for all I care. It transports you to this place and puts you in those muddy boots and featureless landscape, and it drags you through terrible situation after terrible situation, screaming and kicking.
At times I’d be reading on the train, bus, or plane, hiding the pages from people, afraid they’d catch a glimpse of the perturbing sentences, page after page. It was a diarrhea of all possible intrusive thoughts, everything weird you might have thought of doing, to yourself, or to others, growing up and exploring the world, wondering “why not?”. All of those crazy disgusting weird thoughts, turned into a reality.
I don’t know whether I’d recommend this book. I’m still perturbed by it, so I guess it did its job. 7/10
04 Jan 2024
I just came back a few days ago from spending a week in Krakow, and what a beautiful city it is. With an amazing historic city centre, and lots to do around the city, it is well worth visiting.
I recorded quite a bit of footage with the intent of making a somewhat experimental video. Instead of being your standard vlog narrating our strolls around the city, food, and landmarks, it takes a different tone, with very little speech. The intent is more of an audio-visual experience, with music matching the tone of the scenes. It will take quite a while to edit and then record the score for it, but that was what I was thinking about while recording the individual scenes over the course of a week. Hopefully it comes out as I intend it to, maybe a few months down the line.
A few things to visit if you happen to be passing by the city for a few days:
- The castle (1-2 hours, I’d go mostly around the castle and not to specific exhibits… great for photos)
- There is a dragon statue that spits fire behind the castle (next to the river)
- The historic city centre (the x-mas market there is amazing, but also the interior of the building with artesanal wares)
- Kazimierz (the region has great bars and an AMAZING ribs restaurant called “RZEZNIA”)
- To the south of Kazimierz you have a few bridges crossing the Wisła river, they have cool lights at night!
- Park Bednarskiego (climb the hills for a nice view!)
- Galeria Krakowska (shopping mall, probably spent too much time here)
- The botanical garden just east of th ecity centre
- Behind the TAURON arena in the east there is a really beautiful (BIG) park; it was snowing when I went making it amazing
There is plenty more to visit, so many cool restaurants and bars, landmarks and epic sightseeing spots, but this is the bare minimum I think you should have on your list if you are visiting for 2-3 days.
Public transport is great and super fast, you can take the train to get to multiple parts of the city which I found sometimes more optimal than buses/taxis/etc.
25 Nov 2023
Note: This book review has minor spoilers (specially towards the end)!
I’m years late to reading this book. I bought it for my sister around 2019, because I thought the title was a bit edgy and maybe had a few glimmers of insight and protocols to deal with life, social situations, stress, anxiety, and the seemingly overwhelming need to perform and put on a face that has become ever-increasing in the era of TikTok.
Yet when it was proposed in our Book Club, even though I knew it was loosely a type of humoristic approach at a self-help book, I kind of thought it would be good to give it a go (mostly because we had just finished a longer and more complicated book, so it feels nice to dive into something that reads easily in between lengthier reads).
The core idea of the book is to set expectations to zero, the baseline is nothing, then you can only go up. If things were to get worse, that is the new baseline. Choose what things to be passionate or care for with frugality: If you care for everything and want to be everything and measure everything in terms of success then everything will cease to be worthwhile.
I think the most important chapters were 1, 6 and 9.
The last chapter was the one that felt the realest and most honest; but i feel like the whole going to a cliff in south africa was a weird way to confront the idea of death, I feel like you can be at peace with the fact we are going to die without having to look at the bottom of a cliff.
Overall I feel it was written in a state of flow, the sentences are fluid, and whilst targetting a specific audience with a bit of an overuse of expletives, it still feels honest and straight-forward. I feel there are a few nuggets of knowledge and it was entertaining to read.
The downside? I feel like it could have been a 20-30 minute video. For this I think I’ll give it a 3.5 out of 5.
16 Oct 2023
Every year on the first of October a band (which gets together with the sole purpose of making a record) meets in a studio and records an album in a day, or 12 hours to be precise.
It has become a bit of a ritual to listen to the album upon release, just out of mere curiosity.
The act of making music or art under constraints has always intrigued me, and music is even harder because you can so easily fall into a flow state where it feels somewhat… wrong… to leave something unfinished. Yet there is the flip-side of this which is that it is uniquely beautiful to hear something as it ended up, a bit bare, something that didn’t undergo the grueling (and often most time-consuming) act of tinkering with a song until perfect.
And the results are always raw, random, and beautiful as-is.
The latest album called “Across the Road” was filmed in Abbey Road Studios, and is absolutely amazing. From the process of creating the album to the final result, year upon year they have improved; it feels like the first years were about “can we do it? rush!” whereas the latest one feels more like “we know the drill, let’s put effort into where it belongs, and do revisions and add the non-essentials towards the end”, and it goes to show… the song structures, the arrangements, the little funny bits here and there, yet grave seriousness of some of the other tracks provides a very nice mixture of textures, themes, genres, and more.
The mere fact they recorded it in Abbey Road (using some of The Beatles’ instruments) was a source of inspiration that transpires through the musical themes of the album.
Hats off to Rob and Andrew as always, and looking forward to next years’ edition!
16 Oct 2023
I’ve been on call for about 10 years. I wanted to share a few thoughts on this, such as: Managing stress, how things change over time, and how the tech landscape and architecture change the scope of responsibilities of the person who is on call.
When I was asked to be on call nearly a decade ago, we had about 4-5 people who were selected as the group to be on call. This would mean we’d need to be available 1-2 days a week, in full mental capacity (aka not intoxicated) to jump on calls, debug issues, be woken up at any point during the night to help mitigate production issues. On the upside you get compensated, based on how many days you are on call per month, as well as how many hours of extra work you did as part of emergency responses.
At first thought it might seem a bit daunting, what if you randomly get a message to go out with friends? What if you don’t know how to fix the issue? What if it is outside of your domain and you need someone else to help? What if they are not available? What if you are not feeling well that night? What if you just pulled a full day and night of working and you finally manage to get some shut-eye just to be awoken in the middle of the night, knowing you have a fully packed schedule the next day?
Personally, I feel like the initial fear of being on-call outweighs the actual job; yes it will happen, you will eventually get the dreaded ping, but more often than not the issues are easier to fix (specially with modern tooling) than you might think; as long as you have a modern infrastructure with pipelines and auto-scaling of some sort.
What is expected of me?
When you are on call you are expected to know how to investigate, narrow down, debug, inspect network requests, try to isolate the issue to a specific service or area, then prod at it, check the pods, check the database, figure out if you can restart or redeploy previous pipelines.
You are not expected to be an expert in every domain, nor every part of the codebase. A critical mindset is what is needed, one that doesn’t go down a rabbit hole at 3AM but instead tries different high-level approaches to understand the problem from a few angles before trying to dive a bit deeper.
What happens when shit hits the fan? It is 2AM and you get paged. The initial response is a bit of fear, the alarms are going off, you have to get to the laptop and catch up with the chat messages. A few minutes in you have seen the ticket, caught up with the chat logs, and you are now checking the error tracking issue. Shortly afterwards, you work together with support to reproduce it, and meanwhile you figure out if it was related to the previous deploy. If it was, you start the rollback (after notifying everyone, in case there was something that the rollback would revert to, for example if the last deploy was a hotfix). If it wasn’t, you start the investigation, checking if flags changed in the database, checking access/error logs, checking pod restarts, etc. In some cases it will be out of your control and you’ll have to ping infra/devops, maybe they have an on-call system of their own, in some cases it won’t be backend but frontend and you might have to reach out to the on-callee there, or attempt to revert their own pipeline, but in most cases the issue is at least controllable.
The primary purpose is not fixing the underlying issue, it is getting the system under control so that normal operation can resume, so that users aren’t blocked and can use the application. Mitigation as a first line of response, fixing can take place afterwards, as long as the issue will definitely not resurface. It is an exercise of estimating the severity and likelihood of recurrance, and making the best decision with the information available at the moment.
How often will I be needed?
In practice, I don’t think I was paged more than 20 times in the years I’ve been on call, the majority of them being in the earlier years.
The size of the company and the stage that it is in often inversely correlates with the amount one gets paged. What I mean is, with time and growth, services will become more stable, certain areas of the codebase will change less, and more teams will become owners of their own domains; in some cases each team might have a separate cloud account hosting their own services, thus potentially moving the on-call responsibility away from a central group of people are more towards separate teams having their own schedules.
Depending on the size of the company and when this happens, it could either be a good thing or a bad thing, in some cases one person has been the sole person on call for month after month, due to the specificity of that domain and the lack of more people to share the responsibility with. I’d argue in those cases it might be worth it to bring it up to management, and see how to mitigate it, either by introducing more people to that codebase (people from other teams helping to distribute the responsibility of being on-call), or hiring more people / transferring internally.
When the company grows, you will likely adopt different pillars (either by building products or acquiring other companies to grow your portfolio), this means the knowledge of domains (and even access to accounts and resources) may start to split, only giving access to those who need it. This also means multiple on-call teams may start to spring up. Simultaneously, helpdesk support people must know which team (and in some cases which domain) to assign tickets to, which might trigger a page depending on the severity of the issue.
More importantly, by the time you’ve reached this size you’ll probably have a dedicated cloudops/devops team (or person?), and given the prevalence of “the cloud”, likely they will become the first line of defence when issues happen. Since we started containerising everything, multiple failures on a container or pod might trigger it to become unavailable, and new containers might spin up. This has the downside of potentially hiding issues, but the upside of it “fixing itself”. Thus, developers are not AS incentivised (as in the 2000s and 2010s) to produce error-proof code. This also means that the infra team might be notified first when a spike in container creation happens due to bad code; ultimately the fix might be to roll-back to a previous image, thus not even needing to wake up the backend engineers.
You might think I’m exaggerating, but eventually you will come across kubernetes.containers.restarts over environment:production,kube_namespace:project was > 20.0 on average during the last 5m and it will sink in. These are weird times indeed.
In any case, if you are considering being an on-call engineer and wanted to know more about what it requires, and how it will evolve over time, hopefully this gave you a few insights.