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.

This article is spot on in my opinion. This resonates so much with my own experience and ethos... I guess I could have written that if my prose was any good.

Interesting list of criteria about why you might not use some piece of tech. Also delves into why this is often not public knowledge.

Interesting set of tips. Indeed that's a good way to reduce quite a bit the complexity of your application web frontend. Might not be always applicable though.

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.

Also a good reminder of the fact that people are not just resources you can swap easily.

And that's why I find hard to swallow that "microservices" is the go to answer from lots of people nowadays when you discuss architecture. There are interesting promises on paper but that requires you to ignore several layers of complexity. It's likely fine to get there at some point, but bake in all that complexity from the start? I don't think so.

Or why we should keep an eye on transfer learning. This is one of the promising way to get a more efficient machine learning process. Might come with its own challenges in methodology complexity though, it'll likely be easy to do it wrong and to notice that too late.

Good summary on why overengineering is bad, why it happens and how to try to prevent it. We deal with complexity we better make sure there's no undue complexity in our systems.

The wording and bias of the article is a bit startup-y but most things in there apply more widely.

The paper is very "cloud focused" but most of the arguments make sense overall. Managing complexity is really the core issue of what we do as engineers... or at least it should be.

Second time I bump into this book being mentioned somewhere. This good summary really makes me want to read it. At least it gives a clear overview of complexity and how it's tied to other softer topics. I especially like the distinction between tactical and strategic, it's one I do often. I think I'm particularly willing to read the chapters about comments and TDD... from the summary it seems it's where I'm the most at odd with the ideas in there.

Funny way to recall some of the odd complexity classes. :-)