Definitely this, mind the complexity you introduce in your code. Looking smart is not the goal here...

As always from Kent Beck, an excellent set of advices to improve you programming skills.

Faster with less effort doesn't seem to lead to quality code overall.

This is a good set of advices for beginners. I especially like the ones about best practices, trying different things and why it makes sense to be conservative tech wise.

Nice state of the art view on how dynamic dispatch is implemented in several languages. Does a good way showing the trade-offs involved.

An interesting interpretation of what was behind the "move fast and break things" motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.

Interesting move, I'm wondering how far this will go. Reuse of those functions in other Wikimedia project will be critical to its success.

Somehow unsurprising, this is often the case: less validation code, but also less automated tests. With types you can write unwanted states out of existence.

This is a good set of properties to strive for. Since the SOLID principles start to show their age this might be a worthwhile alternative.

Interesting dive on the limits of destructors and when they're called. This can have implications on how programs are stopped.

Nice little article with simulations demonstrating why you want exponential backoff and how jitter is an extra layer of protection for the server.

Interesting heuristic to improve code structure. I definitely recommend. As every heuristic it's not a law though, don't overdo it either.

The right nuanced way to see the DRY principle. As usual don't overdo it that's where problems will arise.

Good list of advices for someone who just got started programming. Who knows, it might come in handy later.

Definitely a good advice. We're just better at understanding positive boolean expressions.

Play is definitely needed for growth. It's true for kids, it's still true for so called grown ups.

Definitely a good principle to follow when designing APIs. Otherwise you make them less obvious and more dangerous to use.

Yes, definitely this. Plenty of reasons why it's important.

It's one of the two hardest problems of programming after all. Needs to be thought through.

A few good things went unnoticed. The performances are still not there.