A bit more nuance in the "how to use the lines of code metric?" debate. Indeed it's not the same if you look at complexity or productivity.
A brief history of word processor formats and how Markdown came to prevail...
Most JS projects end up incredibly bloated indeed. Luckily there are ways to improve the situation.
These are good rules. Take inspiration from them.
Let's not forget where we're coming from and why window managers tend to be merged with display server. It removes some complexity and some latency.
Yes, we have lots of layers nowadays. But you can read them to figure out when something doesn't work like you expect. This is one of the most important skills of the trade.
Probably somewhat self serving so the numbers would need to be confirmed with other experiments. That said that case gives a good idea of the price in terms of complexity and resources when choosing to go for an SPA.
Rampant complexity in software is also a management issue. Are we sure we're rewarding the right things?
No, modularity doesn't imply micro services... You don't need a process and network barrier between your modules. This long post does a good job going through the various architecture options we have.
There are lessons and inspirations to find in how the Vulkan API is managed. The extension system can be unwieldy, but with the right approach it can help consolidate as well.
Interesting essay looking at how systems evolve their schemas over time. We're generally ill-equipped to deal with it and this presents options and ideas to that effect. Of course, the more precise you want to be the more complexity you'll have to deal with.
The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.
Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.
This is a very nice satire website about the problems in our industry. Want to work in a resume driven context? Here is how!
OK maybe a longer piece than it should be. Still the idea is interesting. Clearly you want to mind the O(n) coupling in this context.
This looks like an interesting way to frame problems. It can give an idea of how likely they can be tackled with LLMs. It also shows that the architecture and the complexity greatly matter.
Interesting tool and I like the underlying approach. I wish we'd have good equivalent tools for other ecosystems.
A nice little primer on what systems thinking is about.
Finding the right level of abstraction for the tests is important indeed. It helps keep them useful longer. Scope and complexity are linked and can help find the right balance of tests.
Error handling is not easy. Having simple rules to apply for complex systems is a good thing. Of course the difficulty is to apply them consistently.