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.
I definitely agree with this. Managing complexity is our trade.
This is in part a rant but lots of points in there are very valid. This is in part why I don't find Go a very compelling option so far. Modern tooling indeed, nice runtime in some areas but leaves way too much of the complexity in imperative code.
This is a good example in my opinion: stick with simple choices as long as possible, invest the complexity where it matters.