Stuff I Found Interesting in 2024

Programmers should stop celebrating incompetence

This article caught my attention a bit late, but it remains highly relevant today. It drives the point home and aligns perfectly with my view of programming as a profession. It thoroughly demonstrates the qualities I value in (senior) developers: the ability to understand the code, comprehend what's happening under the hood, and make the computer do what they want it to do. Additionally, the skill to communicate ideas about code is crucial.

Cloudflare took down our website after trying to force us to pay 120k$ within 24h

This is concerning and serves as a reminder that excessive reliance on vendors can lead to significant complications in the long run. Vendor lock-in is a double-edged sword. While avoiding all vendor solutions can result in reinventing the wheel and unnecessary overhead, overusing vendor services can also be problematic, as highlighted in this blog post. It's not the first time I've encountered issues like this, but never to such an extreme.

It's also up to specific cases when unpleasant stuff happens. The last time I approached this topic was earlier this year when Amazon started applying some unpopular measures on AWS, like charging people for public IPv4s. That in itself isn't that egregious, given that we've been running out of IPv4s for quite some time. The problem is that for some, migration to IPv6 might be problematic, as AWS support for IPv6 on certain services is non-existent. Here's a good compilation of these implications inside AWS.

Naturally, that made some people angry, and talks of migration from AWS became a topic again. In the midst of all those changes, people were also upset because of the egress fees that AWS had in place. For some, migrating would not only be painful if they were too reliant on specific AWS offerings, but it might also have been very expensive. Luckily, Amazon has announced that they are removing egress costs when moving data outside.

It all basically boils down to trust in a given platform and its value. My recommendation here is to do thorough research and be cautious when considering vendor lock-in. It depends on the situation. Are you locking in the whole solution, or are you using a single service within a larger system? Think about worst-case scenarios—if the service suddenly stopped working, what would it take for you to get your system up and running? Also, consider open-source solutions. In some cases, it makes perfect sense to choose an open-source variant that you can self-host or easily deploy elsewhere. Of course, these solutions might have their own cascade of quirks, but again, it depends! Is it more important for you to stay less reliant on a provider, or do you prioritize better performance, pricing, or whatever the selling point of the proprietary solution is?

Software Architecture with C# 12 and .NET 8 by Gabriel Baptista and Francesco Abbruzzese

Although C# and .NET are outside of my usual tech stack, it has still been an interesting read—it gave me a bit of insight into technologies I don't primarily use. This book is a good bundle; it's not only about the framework and programming language itself but also offers an opinion on how to run it—particularly on Microsoft Azure. Besides that, there are chapters on DevOps, CI/CD, Domain-Driven Design, and Design Patterns. If C# is your tool of choice, this book might be a good read, as it offers a comprehensive package on different topics of modern software development.

I also recommend this book to seasoned developers. The overview is quite comprehensive, covering everything from how to utilize the language to how to run it. It might serve as a good anchor for transitioning from development to architecture or DevOps. On the other hand, professionals from the DevOps and automation world might find this book useful for its programming content. I can see and appreciate its appeal to a broader audience.