Illustrated with Java, still this highlight fairly well the caveats of mutable collections in multithreaded code.

This is a clever and important use of =delete which I sometimes miss in other languages.

Interesting food for thought. Not necessarily easy to see it used in as many fields as the article claims. Maybe a bit too much on the techno solutionist side at times. Still, that sounds like an interesting guideline and path to explore.

OK, that looks like shell history on steroids. Definitely something I will try out.

OK, this is funny. Clear over-engineering non sense for the sake of it.

A good reminder of what's truly at the root of the container idea.

Interesting story on how power plays can sometimes completely hide the fate of a project until it's too late. Definitely a cautionary tale.

Very early days for research on this topic and the sample is rather small still. That said the results are interesting, there seems to have a few biases inherent to the use of such an assistant, there's also clearly a link between the AI agency and the quality of what gets produced. We'll see if those result holds to larger studies.

Indeed, I encounter that same idea in some people. I'm unsure where it comes from, it feels like reading and extrapolating from something more reasonable (it's like the "one test per line" I sometimes hear about). Bad idea indeed, it's fine to have several assertions, it's probably often required to avoid complexity explosion in your tests. This of course doesn't mean your test should become unfocused.

Very important topic. Nice to see more such teams appearing and thinking now focusing on how to structure them.

What the title said, there's nothing fancy about optimizations. It's mostly well known knowledge, doesn't change much over time or on different stacks... still it's very satisfying.

Definitely this! It's important to model properly your domain and leverage smart value types everywhere it makes sense. This can prevent quite a few different types of bugs.

Finally out of Google Docs it seems. Better version for sharing around. Still an interesting list of case studies and opinions around SAFe. I learned a few things, I didn't realize it's creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it's better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.

If you like remote work, then you need to make sure your written communication is good. There's a handful of proper guidelines in this paper. Good reminders.

Good reminder that "premature" doesn't mean "early". Poor Knuth is so often badly quoted in the context of optimization that it's really sad. The number of times I see "early pessimisation" on the pretense of avoiding "premature optimization". Such a waste...

OK, that looks like cool challenges to train your troubleshooting skills.

This feels odd to be hosted on a Google Doc, but this is an interesting list of case studies and opinions around SAFe. I learned a few things, I didn't realize it's creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it's better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.

Interesting bug in SQLite. In particular look for the conclusion regarding tests and coverage. It's something I often have to remind people of.

OK, the writing is sometimes a bit biased in my opinion (didn't you know Python is superior to any other language?). That being said, this is an interesting resource to get ideas on how the GoF proposed set of design patterns apply in the Python world. I like this kind of "how do things relate" resources.

Very interesting article. The medieval pig is totally not like we imagined, both on how it looked or how it behaved.