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. :-)

Interesting take on optimisation and complexity... Indeed it's probably best to not use the latter to achieve the former otherwise that complexity can never be removed anymore.