Feeling blocked? Maybe try a few of those things on your project.

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

A bit of a long read, but does a good job explaining the use of assertions and how to introduce them in your organization.

That's an interesting trick to make sure people reevaluate comments when they remove some code. Doesn't work for every language of course.

Those principles are old now, but they really captured the zeitgeist of the time.

The example is maybe a bit on the simplistic side. Still it helps understand why you need to pay attention to the SRP.

This is still a valid approach. I regularly encounter cases where the type tag pattern would have been welcome.

This is still a good framework to think about what motivate developers in a team. Not everyone is the same.

A talk from Casey Muratori who is pushing his ideas on software architecture. This one is very interesting on the long history detour it does. Shows well how we keep rediscovering stuff which sometimes go back to the early times of computer science.

If it's too complicated to find a good name, use a comment indeed. As simple as that.

This is a difference which needs to be reminded. Using precise language obviously helps.

A bit old perhaps, but shows quite well the various options to pass a function around in C++.

They both have their niches and it's welcome in my opinion. Now there are questions about the long term viability of Zig's ecosystem... the niche being smaller it's more at risk.

Wondering how to implement your own inference engine? Here is a nice simple blueprint to get started.

A nice followup which acts as a TL;DR for the previous piece which was fairly long indeed.

Interesting selection of options to model data structure with some variability in Rust.

A long essay but contains a lot of interesting insights. There's definitely more to do design wise to produce software people can really bend to their needs.

An excellent piece which explains well why the current "debate" is rotten to the core. There's no good way to engage with those tools without reinforcing some biases. Once the hype cycle is over we have a chance at proper research on the impacts... unfortunately it's not happening now when it's badly needed.

Or how the workflows are badly designed and we're forcing ourselves to adapt to them.

This is an important piece of advice. You need to try things for yourself and fail to really learn. I'm not talking about failing in production of course. But trying to break something locally to see how it behaves, reading the errors, etc. is part of learning. This is how you will troubleshoot things faster the next time.