Here is another point of view on the XSLT situation in the WHATWG. Clearly the process needs to be made clearer. I'm not necessarily convinced by everything which is brought forth in this piece, still nice to have different point of views on it.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

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

Or why competitive multiplayer games which anti-cheat probably will never make it to Linux. I'm not into this kind of games but this is an interesting piece on comparing the differences between the Linux and Windows kernels. It also show that with some care from the game developers, those anti-cheats might not be necessary in the first place.

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

Interesting, it looks like index scans in your databases can have surprising performance results with SSDs.

The idea is interesting, I wouldn't throw away level based logging but this could complete it nicely.

Long but interesting chapter which shows how GPUs architecture works and the differences with TPUs. This is unsurprisingly written in the context of large models training.

Easy to misunderstand as an elitist stance... But it's not the way I read it. Churning more code faster isn't going to help us, you need to take the time for people to grow and improve. It's not possible to achieve if you're drowning in eager beginners.

Interesting parable, it's indeed a good way to illustrate different leadership styles. Being more strategic is clearly what one should try to do.

A good way to frame the possible models for your organization regarding remote work. The GitLab Handbook stays a very good resource regarding remote work, they really thought about it and documented their findings.

I think this is still one of the best distilled explanation of product ownership. It's also interesting for the other parties on an agile project.

A good reminder that long hours are not a sign of success with your project... on the contrary.

No good tricks to optimize your code, but knowing the tooling knobs sometimes help.

Let's see if this gets merged. This could be interesting convenience.

OK, this is completely useless but definitely a fun project.

Or why the XML roots of the web are important to keep in shape. I'm not necessarily in love with how verbose XML is, but it's been a great enabler for interoperability. That's indeed the latter reason which pushed Google to try to get rid of it as much as possible.

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

A good list of things to consider when designing systems. And indeed in case of success the result looks probably boring.

There's a need for clearer vocabulary about testing indeed. The write up is a bit dry here but that's a start.