Word of caution on how we tend to reason about complex systems. They don't form a chain but a web, and that changes everything to understand how they can break.

Good reminder that the raw UNIX timestamps have interesting properties and often are enough not necessarily needing to rely on something more complex. Also gives nice criteria for picking between said timestamps and higher level types.

Interesting statistics, this show how important it is to have well structured and focused change sets as much as possible.

Things could indeed be more convenient... if this was the case we'd probably have less security breaches. Making super complex tools and then complaining that people are holding them wrong isn't gonna help.

Another testament to the fact that it's probably better to have minimal dependencies on your webpages. This is especially true for documents if you're aiming for longevity. If you're making an actual application the trade-off will be different.

Mind how you pick your dependencies and how they fare over time. You might need to reevaluate and let go some of them.

Maybe you don't need to pull even more dependencies. Think of the operational costs and the complexity.

Good reasoning, multi-page applications should be the default choice for web frontends architecture. The single page applications come at a cost.

Looks like the morbid fascination for microservices is fading. This is very welcome. This piece is a good criticism of this particular fad and gives an interesting theory of why it came to be.

It's clearly not clear cut, it's a whole spectrum. I wish more web developers would at least ask themselves the question before having knee-jerk reactions reaching for their favorite framework of the day.

Nice reasoning. It very well highlights the tradeoffs coming the choice they made. And of course the decision might change if the situation changes.

To take with a pinch of salt, it conflates a few things in my opinion. Still it's a good reminder that eliminating complexity shouldn't be a goal. Managing said complexity and avoiding the undue one, this is what matters.

Excellent points. Don't be fooled by alluring architecture changes. Always keep the complexity in check and favor tuning what's already here or changing your use patterns to meet the performance you need.

Hosting applications can be cheap and simple. You need to cater to complexity and mind your dependencies.

A bit sarcastic, but makes its point efficiently. It's important to realize that more code to maintain is definitely not what we need.

Good piece about the hype cycles our industry constantly fall into. So much undue complexity for nothing in some projects... and then we'll complain about technical debt. It would have been much easier to pick the right tool instead of wanting to use whatever new got released by some big tech company.

Neat little resource. We indeed should pay more attention to complexity across our industry.

Interesting parallel taken with IKEA. Some of their principles translate to nice traits for software as well.

Very interesting case full of lessons. Of course, increasing the complexity of the system overall can lead to such hard to find issues. It's also a tale into how seemingly innocuous settings can interact in unexpected ways. I also like the lessons learn pointing to the fact that you can and should debug even the systems you use through abstractions, diving into the code is almost always a good thing (even if in this particular case it wasn't strictly necessary in the end). And last but not least it shows the tension between mastery and automation... the more you automate the least you master the system, and at the same time this automation is necessary for building resilience in the system.

Definitely this. This is an interesting talk, most thing shouldn't be shiny. It's not about stagnating of course, but you should think more than twice before adding a new technology to your stack. Mastery is when you know everything that's wrong with a piece of tech, before that keep in mind the amount of unknown unknowns and the cost of exploiting something new.