An old series of posts which highlights quite well why GitFlow can be a problem and that you likely want something simpler. Since I still find GitFlow often recommended as a knee-jerk reaction, this is a good article to have in hand.

Yes an external cache is definitely faster. That said does your application need the extra complexity? Is the caching in database really the bottleneck? If not, the question of the external cache is still open.

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.

And a bunch of tool to use with it... But you can indeed do a lot with just SSH. This post gives a few good ideas.

Sometimes, it's indeed better to not pull an extra dependency.

Good reminder of this important but imperfect guide to software design. There is some ambiguity on what "simplest" actually means. Still it helps keeping in mind that simple is rarely easy to find.

Ever wondered about how Windows 3 was architectured? This is an interesting read. It was really complex though, you can really tell it's in the middle of several transitions.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

Indeed, let's not fall for the marketing. It's better to write less code if it's enough to solve actual problems.

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

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.

Or why the microservice cargo cult which has been going on for a while now infuriates me. It totally ignores the complexity it brings.

Interesting article about expert generalists (also called "paint drip people" by Kent Beck). This is definitely a skill to foster in teams. The article is long enough that I'm not in agreement with everything in it. That being said there's a lot of food for thought here.

Interesting comparison of different definitions for software complexity (which is an ambiguous term to say the least). It leads to nice consequences when team dynamics are considered.

Nice simple fix in Git but with a large impact on backups. A good proof that profiling and keeping an eye on algorithmic complexity can go a long way in improving software.

A good reminder that the complexity of tests should be as low as possible.

Nice illustration on how you can hunt down complexity in your codebases. It is obviously a slow process but comes with nice benefits.

An honest attempt at "vibe coding"... but once again the conclusion is "when it grows to non-trivial size, I'm glad my experience allowed me to finish the thing myself".

Interesting new proof on the relationships between P and PSPACE. Let's see where this leads.

Or why it's hard to truly evaluate performance in complex systems. We often test things in the optimistic case.