I don't quite subscribe to some of the terms used (even though I see the point of not calling this API). Still I think this is a very good way to approach design, it's also why I like TDD, the tests force you to see how the code is used. If it ain't pretty there's a problem.

Good set of advices around dicts. This is Python centric but some of it applies to other languages as well. Mind the lack of anti-corruption layer.

And this is why you likely need to optimize your data pipelines at some point. There are plenty of levers available.

Excellent collection of surprising behaviors in Python. If stuck or wondering why something works in a surprising way to you, it's a good place to look.

Interesting interview which explores quite a bit mob programming, where it's coming from, why Woody Zuill pushed for it, how it is done, etc. I didn't expect his opinion on why he thinks the name being controversial actually helped spark the conversation around the practice... Very inspiring how he practiced for years to feel comfortable being on stage. I also love at how humble this person is through and through.

Good exercise of prospective for our field. I don't subscribe to all the analyses in there but the value is in at least starting the conversation about it.

Interesting balanced view about Rust. Looks like it highlights strengths and weaknesses properly.

Interesting way to see where to spend time in reviews.

Bunch of good advice. In a way it boils down to: name things properly and use static analysis tools extensively. Still, couple of nice operational guidelines which work in most languages.

Interesting and fair list of pain points around Rust. This is a change from the pure fan boy articles we see most times.

Good primer on refactoring, I especially appreciate the big fat warning about language erosion... the number of times I hear "refactoring" for something which is not a refactoring at all...

Excellent article about best practices for logging errors, most of it applies for other type of logs though.

You thought averaging two unsigned was trivial? Think again, here what needs to happen in all its glory.

If you didn't try Kate for a while... the next release in the spring will be a good time to try it again.

Good reminder that the words we use matter. Fuzzy terms like "clean" indeed hide various dimensions to look at the code and the tradeoffs we make.

Lots of food for thought in that article. Shows very well some of the trade offs in complexity languages have to deal with when they bring a strong type system to the table. Hence some limitations being in place... and that's why it can get into nasty metaprogramming territory quickly. This show a couple of interesting examples on how this can be mitigated although we don't have any perfect solution yet.

Type annotations become quickly complex with Python. This is in part because it's rolled out incrementally on top or existing practices. Here it collides a bit with decorators. Nice to see this hole is getting plugged though. Also nice to discover an alternative to mypy which seems a bit more precise (at least for the time being).

Interesting caveat on how lru_cache is used in Python.

Good explanation of the Python object model and how parameters are passed to functions. This can look rather surprising or confusing if you come from another language. Always keep in mind: mutability and the fact that variable name are just labels play a big role in this. That means you might need to copy explicitly in the case of mutable objects... which makes the performance burden explicit as well (and this means you need to pick between shallow or deep copying).

PS: I really mean "label" here (like in the post), it's a bit different from "pointer" since you don't get the pointer geometry (you can only reassign). From the C++ perspective I'd say it behaves as if all variables were "reassignable non-const references" only, something like that.

Not very profound but definitely useful tips on how to handle reviews.