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.
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.
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.
Indeed we're clearly in a transition period on the Linux ecosystem. If it all comes out to fruition it'll be better for everyone... in the meantime this throws quite some complexity at everyone (in particular for portability and deployment).
A bit heavy handed in the way it tries to paint Root Cause Analysis as evil. Still it has good points about its shortcomings. In particular I appreciate the emphasis on complexity which indeed points to have contributing factors and unexpected outcomes. Definitely things to keep in mind for any postmortem efforts.
A simplified mental model of complexity in software projects. It's not completely accurate but is valuable in the way it is easy to reason about it and probably use it for decision making.
Very important points. This can easily turn a project into a death march with rampant undue complexity. Also the proposed guidelines are simple and seem efficient.
Interesting points about complexity. Indeed it's everywhere the problem is when you start to silently (and unwillingly) worship it... coupled with fear of changes this can only lead to piling more and more complexity in your systems.
Now this is very interesting. An excellent teaser for Herb Sutter's CppCon 2022 talk. Let's see where that goes.
Interesting set of challenges indeed. I think Rust is a bit at a crossroad now. The next few years will be crucial, either they will lead to further adoption or it will stagnate and slowly disappear.
Discusions around a fascinating and very important class of errors in distributed systems.
It feels a bit like cumulating aphorisms and "laws" to prove the point. Still it's nice to know them at least for the general culture.
Interesting view on the state of our industry regarding complexity. Don't despair!
An excellent piece about the links between collapse and complexity. Obviously focuses more on socio-economics systems. Still some of it applies to other fields.
The current microservices obsession not only invite undue complexity in systems, it also bring unprepared developers into network related traps. This is a nice summary of the common misconceptions around this.
Interesting conversation around complexity in code bases. I especially like the point about imagination getting out of control and getting us into speculation. This is indeed often a reason for unwarranted complexity. That's why you need to always keep the context in mind to make your choices. Also indeed fascinating to me is our ability to forget and reinvent something which was already there years ago. We really need more frameworks where we understand what's going on all the way through...
An excellent reminder that usability wise, high-tech is not always the best path. It's good to also evaluate low-tech options at every turn. This is important to know the pros and cons of all the options you can pick.
There's also an interesting point in there about how those more constrained technologies in fact force and help designers to focus on the most important user features.
Debatable "feature", bad implementation, dubious community handling... Clearly not a good example to follow from the Go space.
Interesting opinion. Indeed, as the browsers are packing more features they can deal with more frontend complexity themselves. This is an opportunity to reduce the amount of code in the frontend code at least for some use cases.
Indeed, we loath wires... but going wireless has its own set of issues. It never completely breaks but it can easily degrade for no apparent reason which could be anywhere in the stack.