Sometimes procrastination does solve problems: When I started thinking about the very first entry to the Monthly Pulse series in early November, treating the pilot like any other episode felt wrong. But looking back at an entire year in November didn’t feel right, either. Both problems were skilfully “addressed” by not acting on them for over a month and writing a “year in review” entry in December and then publishing it on New Year’s Eve feels entirely fine.

2024 In Review – Professional Edition

Different tech stack, different paradigms

One of the main reasons for me to join Solaris after I’d been laid off at Shopify – besides an opportunity to work with my good mate Florian Nitschmann again – was the diverse tech stack. It would allow me to find out how well I’d be able to transfer whatever I know about software engineering to a programming language I’d never worked with before; and how quickly I’d be able to pick up new things, of course. I’ve practically been a Ruby-only developer for my entire professional life, after all.

My biggest concern picking up Go was its static typing. After ~25 years of Ruby and only a relatively short period of Java in university, my hands-on experience with statically typed languages was quite limited. Sorbet gave me a glimpse of what it might be like – and I’ll admit that I liked Sorbet for understanding already written code at Shopify –, but two entirely different things turned out to be a lot more difficult for me to wrap my head around:

1. Even though Go technically supports (some) object-oriented programming concepts, most of its code is procedural instead of object-oriented.
2. Idiomatic Go prefers shorter, sometimes borderline cryptic, names for variables and functions, especially in non-public scopes.

These two differences made my code, which of course was still heavily influenced by Ruby, stick out like a sore thumb, especially with all its readable but way too long names.

Naming aside, I think I’ve picked up Go pretty well so far. It took me a few days to write decent enough Go code and another few weeks to adjust my object-oriented mental model to a more procedural one, and then another few months to be well-versed enough in Go to be able to provide useful Go-specific feedback.

When I joined Solaris, I also had my eyes set on picking up Elixir. I’ve always wanted to do so since José Valim had created it over 10 years ago and I thought that I’d finally jump in head first, now that it made sense for my full-time job. But I haven’t really got past the basics yet, mostly due to my involvement with Go so far. Elixir remains something for me to tackle in 2025, I suppose.

The Solaris news cycle

This year has mostly been about migrating the ADAC credit cards that were issued by the Landesbank Berlin (LBB) to Solaris. We (my team and I) had almost an entire year to prepare our part of the migration: transferring millions of balances and transactions past and present. Even with all of its edge cases, that’s a relatively straightforward task, and we were good to go with some time to spare. Having “time to spare” however kept inflating our scope towards the end and things got more hectic for us than I would’ve preferred them to be. Eventually everything turned out to go well, though, and we were able to meet, if not even exceed, expectations set by all parties involved.

That would’ve been a reason for celebration, but news about the restructuring of Solaris and the layoffs that came with it ruined any mood for celebrating. Neither my team nor I personally were affected by the layoffs, but those news still left a sour taste in my mouth, especially after a stressful and exhausting hard work for everyone including those who were affected. And as if those news weren’t bad enough, rumours about the necessity for urgent funding started circulating soon after…

Don’t get me wrong, I like my job at Solaris. It’s met my expectations for my professional development so far by giving me a shot at “proving” that I can work with a different tech stack with reasonable effort and success. From a work-life balance perspective, I can’t complain, either. Employers who embrace fully remote work unfortunately are rare these days and working from home is something I wouldn’t want to give up easily.

If I could, I’d skip the ride on the emotional roller coaster at the end of each year in an instant though. At the end of the day, it’s a really nice job; but having to worry whether I might have to look for a new job at the end of each year is absolutely not enjoyable, at all.

Freelancing

Unfortunately, going full-time freelancer isn’t going to solve the lack of job security, either. It might be something I’ll look at more closely in the future, but for now part-time freelancing does what I want it to do for me almost two decades after my last freelancing gigs: It allows me to have a few (hopefully) happy clients who are just as happy to refer me to other potential clients; and it lets me explore new technologies – and their limitations – in a way that is a lot closer to self-realisation whilst being paid for doing so.

For example, I’m one of those “AI sceptics”: I’ll probably elaborate on it in a post in the near future, but the gist of it is that while I believe artificial intelligence is something worth researching and that it can be beneficial, I don’t think large language models (LLMs) are “it” the way they currently are. Using anthropomorphising words for LLMs like “understanding” or “reasoning” is difficult for many reasons, but the major one is that they don’t “understand” anything and thus can’t “reason” much. They are excellent at predicting the next token for a given sequence of tokens, but that’s practically it. Which can be a useful tool for certain tasks, but it’s not the game changer some people think it is.

However, freelancing took me to a place where I got to explore first-hand which tasks are reasonable for LLMs, which ones are not, and how to use LLMs more effectively than just as a chatbot. It also took me back to one of my happy places, albeit just by accident: Ruby.

2024 In Review – Personal Edition

I’ve been missing Ruby (and Rails) more than I thought

Ever since I’d joined Solaris last year, I haven’t had many opportunities to use Ruby for anything larger than whatever reasonably fits into one single file. Except for looking at code for Ruby-based services at Solaris to investigate and debug issues, there’s been this website, which is backed by Bridgetown and a bunch of AWS Lambda functions for a small subset of functionality like a WebFinger endpoint. My biggest Ruby “achievement” during the last 1.5 years outside my freelancing very likely has been familiarising myself with Sequel. As such I’m very happy to have found a way to return to Ruby, albeit only in my non-main hustle.

The backend of my freelancing project was written in PHP, more specifically Laravel. Coming from Rails, many things in Laravel are not very far from what I’m familiar with, and some things are actually “better” in Laravel, e. g. the existence of Bus::batch and Bus::chain out of the box. I have to admit: It’s the most fun I’ve had coding in quite a while. In fact, I enjoyed it so much that I moved a lot of my prototyping and proof-of-concept-ing to a small Rails application. The cost of having to write code twice – first in the proof-of-concept Rails application and eventually in the Laravel application – actually is smaller for me and thus my client, at least for now. I can move much faster in Rails, which leads to much shorter feedback cycles with my client, and once we’re both happy with the direction, implementing it in Laravel is pretty straightforward. This workflow may change once I’ve good enough in Laravel to make the detour to Rails more expensive than just staying in Laravel.

POSSE

I’ve also thought long and hard about what I want to do with this website and everything around “content creation” (written content, not streaming or video content). There are still a lot more questions than answers, but one of the more definitive answers is that I want to self-host as much as possible and syndicate on other platforms, also known as POSSE.

In the early 2010s I’d given up on hosting my own website, because content – and interacting with it – moved into walled gardens, which I did not want to join for the sake of my time and mental health. About a decade later though, the web appears to be taking a turn towards less centralisation, especially as a result of the more popular platforms like Twitter (now X) and Reddit becoming less and less user-friendly over time, albeit not necessarily for the same reasons. Some probably would argue that newsletter emails with actually good content and active personal websites with RSS feeds had never gone away, but I’m very happy that those are common now, regardless of whether they have been a thing before.

As far as how I want people to interact with my content… I’m not really certain yet. Syndicating on different platforms more or less also means that I should be expecting some form of interaction on those platforms. The days of just having one single point of interaction where I’m expected to respond – like the comment section right under a blog post – may be gone, which means I’ll have to pick my syndication platforms (and thus battles) carefully.

The X-odus and subsequent influx to Bluesky

Fortunately, X won’t have to be one of those. I never really used Twitter much to post anything except for sending complaints support requests to companies, because customer service was way better on Twitter than on any other channel. With fewer and fewer companies staying on X these days, X has become a less and less attractive place for me to be on, especially with its shift to a much more toxic right-wing cesspool.

The latter likely is something a lot of other people were feeling, as well. They also left X, leading up to and especially in the wake of the US election, and practically all of them have ended up on Bluesky. As much as I’ve been wanting ActivityPub (the “Fediverse”) to be the future of microblogging since Elon Musk bought Twitter, I’m cautiously optimistic that Bluesky can be part of a more open social media environment in which there are no real walls and users on different platforms can interact with each other well enough. Whether other users want that is an entirely different question though, given that Bridgy, which can act as a bridge between different platforms and protocols, incited a controversial debate about whether there should be interoperability and under which conditions, if at all. (Side note: Meta’s Threads wanting to be yet another Fediverse instance shows that it doesn’t even have to be interoperability between different platforms that starts heated arguments…)

The AT Protocol, which Bluesky is based on and a client for, allows for self-hosting your data, i. e. you could take your Bluesky data and host it somewhere else if having it at Bluesky becomes undesirable. That by itself is great, but I remain doubtful whether the AT Protocol really will allow you to take your posts, followers etc. somewhere else without losing any basic functionality until someone has proven that hosting your own AT Protocol relay is viable. All we have so far is the promise that it will work like that.

As of right now, I don’t have any reason to believe the Bluesky team would not finish what they’ve set out to do with the AT Protocol. My biggest concern is the Series A round that was led by Blockchain Capital. If I’ve learnt anything from VC funding, it’s that even promises like

This does not change the fact that the Bluesky app and the AT Protocol do not use blockchains or cryptocurrency, and we will not hyperfinancialize the social experience (through tokens, crypto trading, NFTs, etc.).

can be broken if that’s what your investors want and you’re desperately in need of their money. The federation capabilities of the AT Protocol are a safety net for Bluesky users, but only if it turns out that people can use something close enough to Bluesky without the actual Bluesky behind it. X has shown that people are willing to accept a lot of BS before they actually pack their bags and leave due to the consequences of – as well as the effort required for – doing so. Unless moving to some other AT Protocol platform is sufficiently frictionless, I have a hard time believing the promises of the AT Protocol.

2025 In Preview

To hold myself slightly more accountable than having nothing written down at all, I will…

• …be more active on this website and post at least once per month. (This is the “Monthly Pulse” pilot episode, remember?)
• …add more syndication and automate post to the Fediverse in addition to (already) having RSS feeds. I might also include adding automated posts to Bluesky.
• …move more things from AWS to my cloud server. I already have it and it’s idling most of the time, so I might as well make better use of it by letting it idle slightly less.
• …spend more time doing some woodworking. I made a few simple pieces of furniture in the last few years and it was a lot of fun, but I haven’t done anything since spring 2024.

I think I have a good chance at following up with those things by the end of 2025, and with that out of the way:

Happy New Year 2025!