This is an old one but still a funny way to approach the question of test coverage. Unsurprisingly, the context matters.

A good debunk of that claim we sometime see. Of course the tests need to be designed and you need to have good architecture blueprints to follow, otherwise you'll be in trouble... TDD or not.

Indeed, is it that the language itself has a steep learning curve? Or that the emphasis is on the wrong things in the public discourse? I like the emphasis on the Aliasing Xor Mutability, it looks like a good way to approach the language.

OK, the concept if really mind bending. The tech behind it is really interesting.

A good explanation of why the concept is important, also comes with a nice list to get started.

Those principles are old now, but they really captured the zeitgeist of the time.

This is a nice summary of the Send and Sync traits semantic in Rust.

Honestly, it took much longer than I expected. Now you know that GitHub has really become a conduit for Microsoft's AI initiatives.

Interesting tips and caveats when using Tailscale.

Looked like a very bad idea in theory... now everyone can see how bad it is in practice. It's disappointing that the UK government decided to go that path.

Hiring and designing interviews is still not an easy task in our field. This post gives a couple of interesting things to try.

SIMD instructions are indeed a must to get decent performance on current hardware.

Interesting point, fairly logical but didn't sit to think it through before. Indeed, using arenas to get back features of manual memory management won't lead to the same security issues than outside of a memory safe language.

The contrary is indeed claimed too often. This is far from a simple protocol, and that's probably to be expected seeing its history and success.

Definitely over engineered but a good way to play with many interesting tools.

Interesting approach for a project to collect such traps in there dependencies like this.

Observability is indeed not necessarily easy to fit into a code base. Here is a potential approach to make it easier. I wouldn't use it on a project where we're only logging, but once you add metrics to the mix, this kind of probes can be worthwhile.

This is a good list of guidelines to produce a service which is less of a pain to test locally, deploy and operate. Of course, don't take everything at face value (not all of it aged well) but it's a good source for inspiration.

There's often confusion as to where the management responsibilities are in agile teams. This little rambling does a good job pointing it out and giving an idea of how management happens inside and around teams.

Looks like we'll be able to leave Dijkstra's algorithm behind at some point.