A weird detour via baseball obscure rules to justify why we should pay attention to the "Highlander problem". This should be kept in mind especially for designing databases.

This is a good point. The DRY principle has value but the trick is finding the right time to apply it.

Or why anticipating too much is merely a gamble. You can be lucky, but how often will you be? Also I agree that in such cases the performance will be impacted longer term leading to a death by thousands of paper cuts.

A nice pattern to separate decision from actions in complex algorithms.

Good advice on designing your database tables. The comments are good too, they allow to complete the picture.

This is indeed too often overlooked. Producing a test list and picking the tests in the right order is definitely a crucial skill to practice TDD. It goes hand in hand with software design skills.

Turns out to be an interesting discussion about modularity. It's probably a good approach even for a one liner in a script.

Nice advices for API design. First time I see the term "inert" used in this context. Definitely one I should keep in mind and use when appropriate.

Very interesting exploration of the design choices behind the creation of a key value storage engine.

Good food for thought regarding shared presence on the web. A few good ideas in the design space. Obviously very web centric, I wonder what we could do on the desktop with shared documents for instance.

Fascinating article explaining how some Lego sets are designed.

This is apparently a much needed clarification. Let's get back to basics.

Definitely this. Again TDD helps to work on the design, but it's not a silver bullet which will give you the right design on a platter.

This is a good set of properties to strive for. Since the SOLID principles start to show their age this might be a worthwhile alternative.

Good summary that TDD is many things... it helps for quite a few dimensions of writing code, still, it's not a magic bullet in term of design. Your software design abilities are crucial to practice it well.

A balanced view, that's refreshing. Indeed we see too many "let's call the OpenAI APIs and magic will happen". This is very short sighted, much better can be done.

Interesting set of advices. There are a couple I tend to disagree or doubt they really matter though. Other than that probably worth keeping in mind.

It's nice that we get more content usable on mobiles... but this shouldn't come at the expense of bad usability when on desktops.

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

Definitely a good principle to follow when designing APIs. Otherwise you make them less obvious and more dangerous to use.