Another illustration of how to use a new type to declare intent for display of values.

Deceptive title! It's far from simple and the article confirms it. It's fascinating to see all the dimensions you have to deal with to design a game though.

Indeed it feels like the Rust community has a cultural problem around abstractions. In a way it feels similar to the one Java developed years ago. This can bring lots of complexity and obfuscation you don't want in your project.

What's behind the notion? Some historical musing about self-organizing teams and the design they produce.

This is an interesting pattern that I still seldomly meet in C++ codebases. Of course don't go overboard with it, but don't be scared of using it for wrong reasons.

Good reminder that it's better to design your APIs to avoid putting people in the situation of inadvertently creating a divide by zero.

It's kind of an unusual design choice... This is subtle, I think I'm still a bit on the fence regarding this one.

An explanation about where the SRP comes from and what it really means. It's very often misunderstood or overlooked.

Apparently in the age of people using LLMs for their tests, there is a bias toward mockist tests being produced. It's a good time to remind why you likely don't want them in most cases and limit the use of mocks to consider fakes and checking system state instead.

Of course I agree with this. We should fight undue complexity at every step. This beast tends to creep up very quickly and we're all guilty of it at times. This is indeed particularly obvious in otherwise rich languages like C++ or Rust. Those tend to push people to try to be clever and show off, often for "performance reasons". This is rarely a good idea, think twice.

I would have titled the "defer refactoring" section differently though. Probably "defer abstracting" would have fit the bill better.

It's indeed a nice little pattern to use when the type system allows for exhaustiveness checks of destructure operations. Allows to gracefully handle extension of structs in the future.

Lots of good points in there. Very much focused on web services APIs, that being said the first part also applies to libraries APIs in my opinion.

A good list of things to consider when designing systems. And indeed in case of success the result looks probably boring.

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.

The example is maybe a bit on the simplistic side. Still it helps understand why you need to pay attention to the SRP.

When you realize TDD is about units of behavior... then you can see what can be iterative and what can't in your process. In other word, what is dictated by the problem domain is iterative, what is dictated by system architecture is not. Luckily, the latter is often related to the user experience you're aiming for.

It's likely the best explanation of the YAGNI acronym I know. Explains quite well when it applies or not.

This is still a valid approach. I regularly encounter cases where the type tag pattern would have been welcome.

The Adaptive Model is a lesser known design pattern. Like any other pattern make sure you are in the right context to introduce it. Especially this one as it can get really verbose. This article shows a refactoring path for moving from imperative logic to adaptive model.

This is indeed a metaphor which should be more common in enterprise software.