Interesting take. Indeed risks shouldn't be considered in isolation. They actually compound and that can add up fairly quickly.

Another nice one about the power of RSS and why it's an important technology.

Interesting post which gives plenty of insights on how async Rust is designed and behaves.

Interesting breakdown of a possible organisation for accessing self-hosted hardware at home through wireguard.

Excellent profile of Tim Berners-Lee.

Go and read it! It'll give a lively impression of the Web early history. It's amazing how, back then, he managed to fend of the greed of corporate interests in order to make sure his original vision would survive. Of course not everything materialized, most notably the Semantic Web (sadly).

Nowadays, the real question is the fragmentation due to the big closed platforms power grab and the political context. Can we still save the Web? For sure there's no clear path yet.

Or on the importance of being able to say "no". If you see something fishy, at least refuse to participate in it.

Good opinion piece, I wholeheartedly agree with the author on the topic. Like it or not, politics happen in organizations. Ignoring this fact is an enabler for bad decision making.

Indeed, most complaints against "Don't Repeat Yourself" (DRY) are really arguments against a strawman. Of course you can go wrong, it's like everything else it's about balance... reducing the DRY guideline to a caricature to get rid of it won't help.

Maybe a bit extreme as an example, but highlights quite well why you want to limit logic in tests as much as possible.

Your digital life is secure? Good... now is it really safe? Can you recover in case of a catastrophic event?

Early days but it looks like an interesting use of the t-strings introduced in Python 3.14.

With the latest rulings Google feel like the ecosystem might escape its grip... So they plan to tighten it.

I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.

An old series of posts which highlights quite well why GitFlow can be a problem and that you likely want something simpler. Since I still find GitFlow often recommended as a knee-jerk reaction, this is a good article to have in hand.

Nice list of templates to use for better handling of engineering management in your organisation. Pick, choose and adapt what makes sense to the context.

There are indeed way to deal with important but lower priority tasks. You want to tackle those to avoid your teams to slow down too dramatically.

Maybe it's time to stop obsessing about scale and distributed architectures? The hardware has been improved quite a bit at the right places, especially storage.

Yes an external cache is definitely faster. That said does your application need the extra complexity? Is the caching in database really the bottleneck? If not, the question of the external cache is still open.

Nice musing about leadership in a technical context. It's indeed not completely about having all the answers, it's about facilitating the conversations and framing them properly.

Interesting use of make to manage your dotfiles. I have a tiny Python script for that, but this looks even more portable.