Too often people mistake the algorithmic complexity theory for the real performances you would get. This can't be further from the truth. The memory layout trumps all. As usual you need to measure.

A good piece showing some of the problems with how the term technical debt is widely misused. There's a problem with the metaphor itself, you rarely have the information level needed to call it debt.

Nice little post with simulations about the algorithms behind elevators. It's quickly more complex than it sounds.

There is truth here that our profession reinvents the wheel way to often. Some problem are solved, they don't need reinventing. Be careful on your dependencies though, this is where lies the tradeoff.

Interesting piece which shows very well the complexity of the hardware supply chain. The parts which matter the most are largely ignored by everyone.

Little reminder that a got forge doesn't and shouldn't need much. Sprinkle gitolite if you need to manage rights, maybe gitweb and then you're all set.

I wish more teams would have this kind of thinking an really carry it to its logical conclusion. In most case you don't need an SPA framework.

There are ways to have a lighter web. It leads to interesting techniques too.

I like this kind of questions as well. It's more interesting to aim for something simple to start with than a puzzle. Even topics considered simple have several layers of complexity.

This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.

Indeed, we try to limit the amount of code we need to maintain. But configuration can bring its own complexity and maintenance burden as well.

Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.

Interesting piece which gives some perspective on the path which led to async/await. It seems to omit some pieces of the history to me but that's a minor issue. I like how it points that it indeed led to gradual improvements locally for developers writing their functions, but is overall leading to larger issues in the involved ecosystems.

There's a whole swat of solutions for very lean services. You can go a long way reducing complexity as much as possible. Less infrastructure bills are definitely welcome.

Shows the problem with layer cakes in applications or how you might want to go toward onion architectures.

A bit more nuance in the "how to use the lines of code metric?" debate. Indeed it's not the same if you look at complexity or productivity.

A brief history of word processor formats and how Markdown came to prevail...

Most JS projects end up incredibly bloated indeed. Luckily there are ways to improve the situation.

These are good rules. Take inspiration from them.

Let's not forget where we're coming from and why window managers tend to be merged with display server. It removes some complexity and some latency.