Interesting essay even though I don't like the whole part about singularity. I found this section was a distraction to the more interesting arguments. Indeed, I liked a lot the concept of decoherence and its ties to complexity.

The essay also makes a good job of showing how it's something we have to deal with and likely the worst kind of technical debt. I also shows how it impact productivity obviously. It's all valuable and things I encounter on a regular basis.

And of course, since everything has to talk about LLM these days, it build an interesting case on how and why using those tools especially with harnesses to pump out more code is actually increasing decoherence. Exactly what we don't want.

The article equates effort with lines of code a bit too much for my taste. That said I think this model can be useful to describe how maintenance works in a given project.

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.

Designing APIs for the Web platform is hard and error-prone. This is why it carries baggage, here is a good example.

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.

Good advice on naming booleans. It's worth repeating.

As usual with this author it feels a bit too much like advertising toward the end. Still this is an important post, it shows quite well why you can't limit yourself at only the language used when picking a stack. You definitely need to look at the standard library and the wider ecosystem as well. Rust is no different there and has its own issues.

This is a good praise for the work of maintainers. They're fighting off entropy and this should be well regarded.

This is something I've definitely seen indeed. There are clearly a threshold effect in the amount of code you have to manage. Solutions working at smaller amounts don't work anymore a couple of order of magnitudes higher, and vice versa.

Want to start a new project? Here is what you're signing for.

Indeed, if you benefit from Free Software you'd better engage with it. Maintainers should stop bending backwards to please free loaders.

Indeed, if we weaken the learning loop by using coding assistants then we might feel we go faster while we're building up the maintenance cliff. We need to have an understanding of the system.

Indeed, most complaints against "Don't Repeat Yourself" (DRY) are really arguments against a strawman. Of course you can go wrong, it's like everything else it's about balance... reducing the DRY guideline to a caricature to get rid of it won't help.

Nice automation for such updates. I'm discovering endoflife.date this looks very handy.

Interesting take on building software that lasts. I'm not sure I'm fully aligned with this but its good food for thought.

This stays true, most projects are maintained by a single person and that's a problem. Where is the support from all the businesses benefiting from FOSS?

The situation is still complicated for maintainers... And companies benefiting from their free labor don't get it. This leads to really stupid situations.

Nice little comparison of raw loops and ranges in C++. As always, measure before making assumptions... Unsurprisingly it ends up on the usual readability vs performance debate.

The whole field is unfortunately a bit fuzzy. That said, this article gives interesting ideas about what to pay attention to when writing code to ease the readability.

I like this. Sometimes a simple word can make all the difference in the way we behave. Code stewardship is indeed a better word.