One of my favorite of the traditional design patterns in object oriented languages. Now obviously when you get pattern matching in your language... you don't need the visitor pattern anymore.

We're still struggling about how to modularize our code. Sometimes we should go back to the basics, this paper by Parnas from 1972 basically gave us the code insights needs to modularize programs properly.

Another rebuttal of Clean Code. Most of it makes sense if not overdone. There's the usual confusion around the "unit tests" term though, so take that section with a pinch of salt.

This is a good point. Idiosyncrasies are not necessarily a bad thing for naming things. Natural languages are fickle friends, you might need to rely to specific metaphors in order to disambiguate.

Good musing about complexity. Very often we need to move it around, the important question is where should it appear. For sure you don't want it scattered everywhere.

Avoiding boolean parameters in library APIs should be a well known advice by now. Still they should probably be avoided when modeling domain types as well.

Since everything has design choices which imply trade offs. Here is the main issue with PostgreSQL right now. Hopefully it'll get modernized at some point.

Definitely this. Our cognitive capacity is limited, we'd better not deplete it due to complexity before we even reach the core of the problem at hand.

I'm not sure I'm sold on this one. Interesting food for thought but I'll have to mull it over for a while I think. I'm concerned about the performance implications of querying like this.

Nice short post about cohesion in software design. Also gives clue about what proxy we can use to gauge this cohesion.

Interesting exploration of the NT design compared to Unix. There was less legacy to carry around which explains some of the choices which could be made. In practice similarities abound.

Very good article. I wish I'd see more organisations writing such design documents. They help a lot, and that allows to have a way to track changes in the design. To me it's part of the minimal set of documentation you'd want on any non trivial project.

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.