The advice is sound. Having more written records of such things definitely help teams. It can have a benefit in other forms (notes or todo's) if you do it just for you.
Indeed, in some type of projects people tend to turn to Dependency Injection Frameworks a bit blindly (especially true in the Java world). Still there are other patterns which give similar benefits without less headaches. That's worth investigating if this fits your context before picking up a framework.
I tend to agree with this quite a lot. Git submodules tend to create lots of strange issues and rather bad developer experience. Even worse it's not necessarily spotted straight away, you notice the real pains only after having invested in it quite a bit. There are alternatives worth exploring though.
A bit of a rant so brace yourselves. Still, it's very much aligned with the current backslash against "everything must be an SPA" trend and makes very good points on how it happened. This indeed turned into a popularity contest based on false premises. Meanwhile... complexity increased dramatically on the web frontend side and the performances are bad for most users.
When they changed their statutes it was the first sign... now it's clear all ethics went through the window. It's about fueling the hype to drive money home.
This newer standard brings up interesting features again. I'm especially interested in std:expected myself.
This is a huge release. Lots of very strong and needed feature to be a competitive engine. Congrats!
Definitely this. I think this could have turned into a good term until it was used for everything under the sun. It's about maintainability first, not just about what you like or not.
Interesting new compression format around the corner. Might turn out useful in some cases. I could definitely have used it last year for a test harness with very large reference data (so no, not gaming).
Development is and has to be a team sport indeed.
That's a good set of questions to ask ourselves when in contact with a product claiming the use of "AI".
Very nice set of rules. They are very simple to apply individually. The art is in respecting it all of course.
This really looks like a nice library for symbolic maths. Keep in mind it's python based but it goes all the way to generating solutions to the given problem in various languages.
A bit too much written in superlatives for my taste. Still, this is an interesting set of qualities indeed. Definitely things to aim for.
They're definitely a powerful tool. I see them used in a few places but definitely not enough.
Good musing about simple code and complexity. We definitely should avoid unwarranted complexity in our code, or at least try to prevent it's spreading.
Having taught quite a bit at the university, having interviewed quite a few junior developers... I have to agree what's proposed here is missing from most curricula. I wish this would be taught more systematically. If not at least students everywhere should know this online course exists.
Coming from Zombie Nokia, still I think we need more options like this. It is the number one solution to reduce ecological footprints of computing.
OK, definitely a gutsy move... Still this is an interesting approach for a complex system. Better have a controlled early failure if you can get it, than a complete collapse later on. This might be just the incentive you need for real organizational change.
Not earth shattering benchmark, kind of confirms what we can expect on the concurrency and REST side of things: Rust, Go > .NET > JVM