Evidence: a friend of mine this month decided that he can't justify dropping $1.6k on a gaming computer.

As a PC gamer since I have memory, this whole situation makes me sad.

My understanding of the argument is that it doesn't deny that unions and strikes weren't instrumental but that it was only economically sustainable because of the increased productivity.

Knowing algorithms, data structures and their memory and time complexities is very relevant for SWE. I've had teammates that didn't understand them and everything was fine until when it wasn't (scaling and performance issues).

Or, as I put it to a teammate: "Would you rather review the PR of someone that understands the difference between a set and a list or the PR of someone who doesn't?". This was after we interviewed a candidate with ~15 YoE, on paper, that didn't know the difference.

- Understanding the problem at hand

- Putting all the pieces together so that they solve the right problem the right way

- Making sure that the solution facilitate future extension and doesn't lead to a ball of mud two months from now... Unless stakeholders want it to be quick and dirty, then making sure they understand the costs/risks

- Planning execution a way that is incremental and testable so that we can build confidence that the system is doing what we expect of it

- if you are in a team, figuring out common dependencies so that those can be done first and unblock parallelism on execution.

Once all that is done and documented, writing the code was easy and fast.

What would sometimes happen is that some unexpected detail or dependency would be discovered as part of the writing of the code and then you are back at the beginning, figuring out how to make everything fit together.

I find that the main confusion comes from people not realizing that those are two different activities and instead calling it all "writing code".

This is a very costly way of developing software.

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