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.

That looks like an interesting way to share data between applications. Reminds a bit of the semantic web movement back in early 2000s (talking entities and aggregates), maybe less heavy on the schema side though. I'd need to look at the specification more.

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 example of using a strong type system to avoid mistakes in code using a parsing and serialization library. The fact that it's about IMAP and I'm still traumatized by it has nothing to do with my interest in that article, really.

Good guidelines to improve end to end tests. I especially relate to the first one, the test API is very important for those, otherwise they become a chore to maintain and understand.

Interesting tips for potential bottlenecks in your queries.

Nice way to learn systemd uses.

Interesting caveat on how lru_cache is used in Python.

Also a good reminder of why the fact that it's proprietary makes things harder security wise.

A bit on the fence with this still... but that sounds like an interesting path to explore in dealing with service APIs. A DSL with a code generator allows to neatly separate concerns if done properly. I wonder where the catches are (apart from the obvious strong coupling to Golang in that particular case).

Very interesting story (even though it feels a bit like advertisements at times) about the quest to get color into e-ink displays. Goes on to explain a bit of the technology behind those.

Looks like an interesting project for managing your own infrastructure, I should keep an eye on it.

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.

Good reminder of why "tech debt" is not a so bright metaphor. I find it useful sometimes but clearly it became overused in the industry (often a sign of something loosing its meaning whatever it was). That's why lately I'm talking about complexity, some of it being legitimate so you need to keep the illegitimate one at bay. I like the focus on maintenance in that post. Also there are a couple of good ideas on how to schedule the maintenance tasks in your project.

Or why I'm actually glad I'm not certified even though I could be. This is a good way to stay balanced about all this. At least I'm trying to do my part trying to help people also on the technical areas which are mostly ignored by the "Scrum Industrial Complex" (as Ron Jeffries puts it). Clearly the scrum organizations are not interested in taking up that mantle so it falls onto us.

Not necessarily unknown paths to squeeze more performance out of Python. Still it's nice to have those options measured and listed in the same post.

Excellent deep dive in how GPS works. It goes all the way down to the signal processing. It's really nice to see how many layers of complexity this technology carries.

Interesting piece on why focusing on clarity, conditions and constraints can help figure out why a team can be dysfunctional.

Interesting analysis about the likely path ahead for Intel.