Good guidelines for Rust code indeed.

These are good rules. Take inspiration from them.

Yes, we have lots of layers nowadays. But you can read them to figure out when something doesn't work like you expect. This is one of the most important skills of the trade.

There's always an interesting lesson in this kind of failures. Here clearly it is in part a story of unchecked trust, and not planning for a bigger system. It came with real consequences too.

Obviously the essay from Peter Naur keeps popping up lately. It feels like an important piece, especially in the current atmosphere of vibe coding. This article lays out quite well why vibe coding is the opposite of what we should be doing.

Very good essay on why the developer profession is not going away. On the contrary we need to double down on essential skills and put in the work. This is long overdue anyway.

This fantasy regularly comes back. Yet, the tools evolve, might improve some things but the core difficulties of programming don't change. At each hype cycle our industry over promises and under delivers, this is unnecessary.

Looks like a good tool when you need to search for stuff in codebases.

Interesting experiment even though some of the results baffle me (I'd have expected C# higher in the ranking for example). Still this gives some food for thought.

There is some truth to this. Moving some things to data brings interesting properties but it's a two edged sword. Things are simpler to use when kept as code. Maybe code emitting structured data.

Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.

There's a lot of this. Learning different languages to get out of your habits definitely brings compound benefits.

OK maybe a longer piece than it should be. Still the idea is interesting. Clearly you want to mind the O(n) coupling in this context.

Functional programming is made scary due to its jargon. But it doesn't have to be this way.

Long but interesting piece. There's indeed a lot to say about our relationships to tools in general and generative AI in particular. It's disheartening how it made obvious that collaborative initiatives are diminishing. In any case, ambivalence abounds in this text... for sure we can't trust the self-appointed stewards of the latest wave of such tools. The parallel with Spirited Away at the end of the article is very well chosen in my opinion. The context in which technologies are born and applied matters so much.

Indeed, we might want to use dev containers more widely in the profession. If you're developing something for the desktop you're out of luck though.

Definitely the right rule to follow to designing classes in C++ in my opinion.

The trend keep being the same... And when the newer models will be trained on FOSS code which degraded in quality due to the use of the previous generation of models, things are going to get "interesting".

OK, this is old so I wish it'd go beyond 2003. Still, that's quite a funny read.

Gives an idea of what pair programming looks like when practiced properly.