The other aspect is you could share the media storage over NFS and have multiple jellyfin instances running for different houeshold groups.

With 2 or 3 nodes like that I think you could make it work.

I would argue they are. Those traditional methods aim at keeping complexity low so that reading code is easier and requires less effort, which accelerates code review.

I have come to the realization that most people in the industry don't know this body of knowledge, or even that it exists.

I'm now seeing the same people trying to solve their ineffectiveness with AI.

I don't know what to think about this situation. My intuition hints at it not being good.

If boilerplate was such a big issue, we should have worked on improving code generation. In fact, many tools and frameworks exist that did this already:

- rails has fantastic code generation for CRUD use cases

- intelliJ IDEs have been able to do many types of refactors and class generation that included some of the boilerplate

I haven't reached a conclusion on this train of thought yet, though.

It also has one for squash-merged branches: gbds

Very useful I've been using them for years

My take is that there are two layers of friction:

a) people that care about chat encryption and would be willing to change, already did, to Telegram and/or Signal. "I'm not going to install yet another chat app" is a real answer by a friend of mine

b) no one wants to either host their own server, nor pay someone to host it for them. If it wasn't for me and a one of my friends, none of the people I chat with daily would be on Matrix.

And yes, there is the matrix.org server. Out of the ~13 people I chat frequently with, 1 is on matrix.org. "What's the point of changing apps if I'm still going to be using the centralized server" is another answer I've gotten.

I don't know what the solution to this dynamic is other than us, the power users, setting it up and paying for the group of people around us.

Then, there are companies that ran a bunch of them, which lowered the ratio even further.

IMO, it's more effective, cheaper and easier to mod smaller forums (be it web communities or game server communities) than to do for huge ones.

The process that I outlined above explicitly creates the space for SWEs to consider the wider implications of the required changes in the architecture and make robust.

Part of that is understanding what the roadmap is and what is the product vision in the mid term, so that the tech layer can be built, step by step, towards what fits that vision.

Internally, the team splits Epics into "Spikes" (figure out what to do) and "Tasks" (executing on the things we need to do).

- Spikes are scoped to up to 3 days and their outcome is usually a doc and either a follow-up Spike or Tasks to execute.

- Tasks must be as small and unambiguous as possible (within reason).

This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.

No issues whatsoever and it is so easy to manage. It just works!

To be honest I'm more annoyed by having to repeat three times parameters in class constructors (args, member declaration and assignment), and I have a macro for it.

The thing is, most of the time I know what I want to write before I start writing. At that point, writing the code is usually the fastest way to the result I want.

Using LLMs usually requires more writing and iterations; plus waiting for whatever it generates, reading it, understanding it and deciding if that's what I wanted; and then it suddenly goes crazy half way through a session and I have to start over...

And you'd be wrong. I, for one, enjoy the process of handcrafting the individual mechanisms of the systems I create.